Deployment
How deployment works
The model behind every deploy: what a product, an environment and a service are, and what happens between a push and a live address.
Deployment runs your containers for you. You hand it a git repository, a prebuilt container image, or the files of a static site — and you get back a running service on a public HTTPS address, with variables, persistent storage, managed databases, and separate environments for production, staging and pull-request previews.
You work in your own concepts: environments, services, deploys, volumes, domains. You do not get access to the machines underneath, and you do not need it — building images, routing traffic, serving it over HTTPS and keeping containers alive are Lessly’s job.
Three levels, from the outside in
| Level | What it is | What it holds |
|---|---|---|
| Product | What you created on the platform, and the boundary of everything deployment does for you. Managed on the platform, not here. | Every environment, service, variable and database belongs to exactly one product. Nothing you create in one product is visible from another. |
| Environment | The top-level thing you create here: an isolated slice of a product. | Its own services, variables, volumes, managed databases and domains. Nothing is shared across the boundary. |
| Service | One unit you deploy inside an environment, of one of two types: a runtime service, which runs a container, or a static site, which serves files with nothing running between requests. | A source, the settings it runs with, its own variables, its own domains and its own release history. |
The type decides which sources a service accepts and which settings it has. A runtime service takes either a repository and a branch — Lessly builds an image from your code and rebuilds it on every push to that branch, with one exception, a service sitting at zero replicas, where what a push does depends on its sleep setting — or a container image you already publish to a registry. A static site is either built from a repository or uploaded already built, and it has no port, no replicas and no health checks. See Set up a service.
A production environment is created for you when deployment is connected to a product, and it is the one environment you cannot delete. You add staging, development and anything else you need, and preview environments can be created automatically for a pull request.
Under a service sit its deployments — one per release, each a fixed snapshot of one image plus the configuration it was launched with. A service has at most one active deployment; starting a new one replaces the previous.
What a deploy is
A deploy takes a service from its current release to a new one.
- For a repository or a static site, Lessly builds first: it fetches your code and produces an image or a set of files, streaming the build log as it goes. For a prebuilt image there is nothing to build.
- It starts the new release and waits for it to report healthy.
- Only then does it send traffic over. The previous release keeps serving until that moment, so a release that never comes up does not take the service down.
Every past deployment is kept, so rolling back means choosing an earlier one — no rebuild involved.
The words this section uses
- Environment — an isolated slice of a product, with its own services, variables, volumes, managed databases and domains. See Work with environments.
- Service — one thing you deploy inside an environment: a source, the settings it runs with, its own variables, its own domains and its own release history. Its slug is the name other services use to reach it over the private network. See Set up a service.
- Service type — what a service is: a runtime service, which runs a container, or a static site, which serves files with nothing running between requests. The type decides which sources and which settings a service has. See Set up a service.
- Runtime service — a service that runs a container Lessly keeps running for you. It takes a repository or a prebuilt image as its source. See Set up a service.
- Static site — a service that is HTML, CSS and JavaScript with no server of its own, either built from a repository or uploaded prebuilt. It has no port, no replicas, no health checks and no runtime logs, and publishing it is atomic. See Set up a service.
- Service source — where a service’s code, image or files come from. Which sources are available depends on the service type: a runtime service takes a repository or a prebuilt image, a static site takes a repository or an uploaded prebuilt archive. See Set up a service.
- Deployment (also release) — one release of one service: a fixed snapshot of the image that runs and the configuration it was launched with. See Deploy, redeploy and roll back.
- Build — the step of a deploy that turns a source into something runnable. A prebuilt image and a rollback have nothing to build and skip it. See Deploy, redeploy and roll back.
- Snapshot — what a deploy captures at the moment it starts: the source and the fully resolved set of variables. The release is fixed to it, which is why an edit afterwards waits for the next deploy. See Deploy, redeploy and roll back.
- Rollback — deploying an earlier release again. It restores the image and not the configuration: the release runs with today’s variables. See Deploy, redeploy and roll back.
- Fork — creating an environment as a deep copy of the shape of an existing one. It carries no secrets, no custom domains, no data and no history. See Work with environments.
- Preview environment — a fork with an automatic lifecycle, tied to one pull request. See Work with environments.
- Generated domain — the
lessly.runhostname a service is given when it is created. It is created and removed with the service. See Connect a domain. - Route — the mapping of a path prefix on a custom domain to a service in the same environment. See Connect a domain.
- Variable — a named value passed into your container, and the only channel through which configuration reaches it. See Set variables and secrets.
- Secret — a variable whose value is encrypted and write-only from that point on: shown masked, never returned by a listing, and left behind entirely when an environment is forked. See Set variables and secrets.
- Replica — one running copy of the current release. Requests are spread across all of them, and nothing is pinned to a particular one. See Scale a service.
- Scale to zero — the opt-in per-service setting that lets an idle service stand down and come back on the next request. See Scale a service.
- Volume — a persistent disk attached to one service, whose contents survive restarts, deployments and rollbacks. See Add a database or a volume.
- Managed database — a database Lessly runs for you instead of a container of your own. See Add a database or a volume.
- Runtime log — the lines your own container prints to stdout and stderr. A static site has none. See Read logs, events and metrics.
- Event — Lessly’s own record of something it did to your resources, distinct from a log, which is what your code printed. See Read logs, events and metrics.
- Terminal — an interactive shell opened in the browser inside one running replica of a service. See Open a terminal.
Next steps
- Set up a service: choose a runtime service or a static site, and set what that type actually has.
- Work with environments: add a
staging, fork one, or let a pull request open its own preview. - Deploy, redeploy and roll back: what starts a deploy, how to cancel one, and how to go back a release.
- Connect a domain: serve a service on a domain you own, and split one domain across several services by path.