Deployments
What a Deployment represents, how it relates to Services and Environments, and where operations apply.
Written By Zoro
Last updated 3 days ago
Deployment
A Deployment is a concrete instance of a Service configuration at a point in time. It ties together build output (for built services), runtime settings you have saved, and rollout state (in progress, live, failed, and similar labels shown in the product).
How deployments relate to Services
- A Service is the long-lived definition: source, image, env vars, scaling intent, routing, and volumes.
- Deployments are the history of releases for that service. When you deploy or redeploy, you create or advance deployment records the UI uses for status and logs, and to compare what shipped when.
Operations you think of as “ship this version” or “return to a known-good release” apply at the Deployment layer (and to the Service that owns them). See Redeploy and rollback under Deployments and Operations in the sidebar for practical recovery patterns.
Environment context
Every deployment belongs to a Service, and that service lives in an Environment inside an Application. The same service definition in staging and production is two different runtime contexts, each with its own deployment history.
See also
- Services: the unit deployments release.
- Logs: build, deploy, and runtime output.
- Volumes and persistent storage: data that survives redeploys.
- Redeploy and rollback: ship and recover releases.
- Deployments overview: section orientation for day-2 operations.