Platform · App servers
Every service the agent finds in your repository — web, API, worker, scheduled job — gets its own managed application servers with a hosted endpoint, TLS and private networking. You never choose an instance type; the agent derives one from the runtime and traffic it observes.
Each detected service runs on its own set of servers, so a busy worker can never starve the web tier.
Public services receive a hosted URL with managed TLS. Add a custom domain with a single CNAME.
Public-facing services run on at least two servers from the first deploy, behind platform-managed routing.
Servers run release artifacts built from a specific commit. Rollback swaps artifacts — nothing is patched in place.
App servers reach managed PostgreSQL and Redis over a private network. Nothing else on the internet can.
The agent watches CPU, memory and latency and adjusts server size or count within the limits you set.
During repository analysis the agent records the runtime, dependencies and the kind of work each service does. A Next.js frontend, a FastAPI service and a Celery worker have very different profiles, so they start on different server sizes. After launch the agent keeps measuring: if p95 latency climbs under sustained load it adds servers; if memory sits idle for days it recommends stepping down. You set upper and lower bounds; the agent works inside them.
Ports, process managers, reverse-proxy rules, TLS certificates, health-check paths, restart policies, log shipping. These are inferred or managed. If the agent guesses wrong — an unusual entry point, for instance — a one-line hint in SHIPSANELY.md corrects it for every future deploy.
Early access is open for a limited number of teams. Tell us about your stack and we will reply with next steps.