How a service runs
A web service on Kuppit is a container image that Kuppit runs as a revision, behind a hostname, with instances started as traffic arrives. You never touch the infrastructure underneath; this page says what it does so that the behaviour you observe makes sense.
Revisions
Every deployment produces a revision: the image plus the variables and settings it was prepared with. A revision is immutable. Traffic moves to a new revision only once it has passed its health check, and the revision that was serving keeps serving until then, which is why a failed deployment never takes a service down and why a rollback is a previous revision brought back rather than a rebuild.
Instances and scaling
A revision runs as instances, started on demand.
- Zero when idle. A service with no traffic runs no instance. The first request after idleness starts one, which takes as long as your application takes to start; keeping start-up fast is the lever you have.
- More under load. Kuppit adds instances as requests arrive, up to the size's ceiling (sizes), and removes them as traffic falls.
- Each instance is the same. Instances share nothing with each other but the database. State kept in memory or on the instance's disk is that instance's alone and is gone when it stops; anything that must persist belongs in the database.
A service does not keep an instance up between requests, so background work that needs a running process, a queue consumer or a scheduler, has no home yet. A database, by contrast, runs continuously.
Region
Kuppit Cloud places every service and database in one region and does not offer a choice. Services in an environment are therefore beside their database, and a service reaching another service does so over its public hostname through the edge.
What Kuppit manages
| Kuppit's | Yours |
|---|---|
| Building the image, keeping every image that went live | The repository, the Dockerfile or the framework |
| Starting, checking and promoting revisions; moving traffic | Listening on PORT, on all interfaces |
| Instances, scaling, the region | The size, when the default is not enough |
| Hostnames, certificates, the edge | Custom domain DNS records |
| Database provisioning, credentials, the connection into it | Schema, migrations, data |
| Encrypting variables, resolving references, snapshotting them per deployment | The values, and redeploying when they change |
| Logs, read live from the infrastructure | Writing something useful to them |
There is no cloud console to open. What Kuppit manages is not exposed for you to change by hand, and what is yours is reachable from the dashboard.
The application graph
Components, the node each environment has for them, and references as the edges between them. The one picture the rest of Kuppit is drawn from.
Deployments
How one commit becomes a running revision of a web service, what each status means, and what happens to the deployment before it.