Core concepts

Mesh runs the application you describe as isolated services. A few ideas explain everything else in the guide.

#The resource model

Workspace
└── Project
    └── Environment          (production, staging, pr-42, …)
        ├── Service          (web, api, worker, postgres, …)
        │   ├── Deployment   (one attempt to run a revision)
        │   └── Domain       (a public hostname on a port)
        └── Volume           (persistent disk for one service)

Workspace. People and the projects they share. Roles (admin, member, viewer) apply to every project in the workspace, and usage is billed per workspace. See Workspaces and members.

Project. The environments of one application. A project can move to another workspace.

Environment. An isolated copy of the application with its own services, variables, volumes, and private network. New projects start with production; add staging or one environment per pull request. See Environments.

Service. One workload: its source (a GitHub repository or a Docker image), how to build it, its variables, resources, replicas, ports, health check, and volume. See Services.

Volume. A persistent disk mounted into one service. See Volumes.

Domain. A public hostname routed to one port of a service. See Domains.

#Staged changes and releases

You edit a service's draft. Changing the draft does not touch what is running: the change waits, staged, until you release the environment. A release applies every staged change in the environment at once and starts one deployment per changed service.

This lets you change an API and its worker together, add a variable to three services, or attach a volume and its mount path, and ship it as one step. The console shows staged work in the release bar; the API reports it as pending_changes on each service. See Deployments and releases.

Some events deploy without a release: a push to a tracked branch when auto-deploy is on, and actions such as restart, redeploy, and rollback.

#Deployments and replicas

A deployment is one attempt to run a service revision: build the image if needed, start replicas, wait for health checks, and drain the previous deployment. Deployments are kept as history, so you can roll back to any earlier one.

#Isolation

• Builds are isolated from each other and from other workspaces.
• Services run sandboxed, with CPU and memory ceilings.
• Networks are per environment: services in one environment cannot reach another.

#Deletion is reversible

Deleting a project, environment, service, or domain stops it at once, but you can restore it for a grace period, seven days by default. Volumes are the exception: their data cannot be restored. See Deleting and restoring.