Build and deploy
Services
A service is one workload in an environment: a web app, an API, a worker, or a database. You describe what it should run, and Mesh keeps that many healthy replicas running.
Sources
A service runs one of two sources:
- A GitHub repository. Mesh tracks a branch, builds an image from each commit, and deploys it. See Builds.
- A Docker image, such as
postgres:17-bookwormorghcr.io/acme/api:1.4. Mesh pulls it as it is. Templates and the API create image services; the API and the MCP server accept any public image.
Change the source in the service's Settings, under Source.
Settings
Every setting except the replica count is part of the service draft: changes are staged and take effect on the next release. See Deployments and releases.
| Setting | What it does |
|---|---|
| Start command | Overrides the image's command and arguments. |
| Variables | Environment variables for the process. See Variables. |
| CPU and memory limit | Ceilings per replica, in vCPU and MiB. Usage below the limit is what you pay for. |
| Replicas | How many copies run at once. Traffic is spread across ready replicas. Applies at once, without a release. |
| Region | One catalog region for the service. All replicas stay there. See Regions. |
| Ports | The ports your app listens on. One is primary; domains route to a port. |
| Health check | How Mesh decides a replica is ready. See below. |
| Restart policy | What happens when the process exits. See below. |
| Volume | One persistent disk and its mount path. See Volumes. |
| Sleep when idle | Stops the service when nobody uses it. See Serverless. |
Limits are ceilings, not reservations: a service that idles at 50 MiB pays for 50 MiB even with a 1 GiB limit. Your plan caps the largest values. See Plans and billing.
Health checks
A new deployment takes over only after its replicas pass their health check.
- HTTP sends
GETto a path on a port and expects200 OK, for example/healthzon port3000. - TCP expects the port to accept a connection. Templates use TCP checks for databases.
The healthcheck timeout is how long a new deployment has to become healthy before Mesh gives up and keeps the previous one. The draining time is how long the previous deployment keeps serving in-flight requests after the new one takes over.
Restart policy
| Policy | Restarts when the process |
|---|---|
| Always | Exits for any reason. |
| On failure | Exits with a non-zero code. |
| Never | Is never restarted. |
Restarts back off between attempts. Max restarts within a window bounds a crash loop: by default 5 restarts in 300 seconds. After that the replica stays stopped and the deployment reports the crash, with the exit code and recent logs as evidence. Paid plans allow up to 100 restarts in up to 3,600 seconds; the trial allows the default.
Internal hostname
Every service gets a stable hostname on its environment's private network,
derived from its name: a service called API Server is
api-server.mesh.internal. See Private networking.
Rename, scale, and delete
- Rename a service from its header. Its internal hostname changes with the name, so update the services that call it.
- Scale by changing replicas in Settings → Scale. Scaling applies at once and wakes a sleeping service. A service with a volume runs one replica.
- Delete stops the service and removes its domains. You can restore it from Recently deleted during the grace period. See Deleting and restoring.