How deployment works
Run containers, static sites and scheduled jobs in separate environments.
Lepsto builds and runs your services from a Git repository, a public container image or uploaded static files. Deployment also provides HTTPS domains, variables, persistent storage and managed databases. Use separate environments for production, staging and pull-request previews.
Product, environment and service
A product contains your deployment resources. An environment groups services, variables, volumes and environment-managed databases. A service is one application or site, with its own source, settings and release history.
The production environment is created when Deployment is connected to your product. You can add environments such as staging; you cannot delete production through the environment delete action.
Services in different environments have separate private networks. Environment and service variables are separate records, while product variables can be inherited across environments. Managed Postgres is also product-level: you can attach its databases to services in different environments.
Choose what runs
Workload | Source | What runs |
|---|---|---|
Runtime service | Git repository with a Dockerfile, or a public container image | A long-running container, with replicas and optional health checks |
Static site | Git repository or uploaded built files | Files served without a running application container |
Scheduled job | Git repository with a Dockerfile, or a public container image | A command that exits, started on a UTC schedule or manually |
Set up a service for an application or site. Schedule a job for exports, reports or other work that runs and ends.
What a release captures
A deployment is one release of a service. It records the source, image or static output, and resolved configuration used for that release. Later variable changes wait for another deploy.
For a runtime service without a volume, Lepsto starts the new release alongside the old one and moves traffic after the new release is ready. Without a configured readiness check, starting the container counts as ready. A volume changes the rollout: the old container stops before the new one starts, causing an interruption. Static publishing switches from one complete version to the next.
A service has at most one active deployment and one deploy in progress. Rollback reuses an earlier image with current variables; it does not restore old configuration or database contents.
Find your resources
In the Product App, open Deployment → Environments, then select an environment. Its canvas shows services, environment-managed databases and volumes. Select a node to open its settings panel. Metrics, Logs, Alerts and Audit belong to the selected environment. Product-level Databases manages Managed Postgres instances.
You can also use MCP, REST or the root @lepsto/sdk client. The SDK accepts a credential kind and value: publishableKey, apiKey (server-side only), accessToken or bearer. Choose a credential authorized for the operation; these names do not grant access themselves. baseUrl selects another API base URL. SDK retries are off by default and must be enabled per call or client; do not blindly repeat a mutation.
Use the MCP reference or Deployment REST reference for exact contracts. The Deployment glossary explains terms used throughout this section.