How the platform works
Last updated
Everything here is built from one idea: an application is a single container. It runs continuously until you stop it or your balance runs out. Understanding what follows from that explains most of the platform's behaviour.
The lifecycle
- You provide code or an image — by pushing to git, pushing a Docker image, uploading a zip, or naming an existing public image.
- The platform builds or pulls an image, then creates a container from it with the CPU, memory, environment variables, ports and volumes you configured.
- The container runs until you stop it, something replaces it, or your balance runs out.
What replaces a container
This is the most useful thing to know, because it explains a lot of surprising behaviour:
- Deploying a new version
- Changing an environment variable, port, volume, config file, run command, or CPU/RAM preset
All of these stop the old container, remove it, and create a new one. There is no overlap between the two, so every one of them is a brief interruption — not just deploys. Batch configuration changes rather than making five of them across an afternoon.
Your process gets a stop signal and roughly one second before it is killed, so long graceful-shutdown routines will not finish.
What survives, and what doesn't
| Where it lives | Survives a restart? |
|---|---|
| A volume | Yes |
| Anywhere else in the container's filesystem | No |
| Process memory | No |
That single rule explains why an uploaded file disappears, why a SQLite database resets, and why in-memory caches, sessions and counters start empty after every deploy.
One container, no replicas
An app runs as exactly one container. There is no horizontal scaling and no rolling deploy.
The good side: no sticky sessions, no shared session store, and in-process state genuinely works while the container lives. The trade-off: you scale by increasing CPU and RAM, and deploys have a gap.
Nothing watches your app
The platform observes whether the container is running. It does not send requests to your app, check a health endpoint, or notice that your bot has gone quiet.
That is why workers with no ports are first-class here — nothing expects your process to answer HTTP — and why liveness is your responsibility. See Observability.
Where to go next
- Applications — states, restarts, and deletion
- Networking — ports, URLs, and what is public
- Configuration — environment variables and config files
- Create your first app