Runtime

Every Web Service on Runsite runs as an isolated container. This page explains the platform model that sits underneath the dashboard: how your app is built, what happens during a deploy, what each status means, and how storage works.

If you only need to ship code, the Quickstart is enough. Read this page when you want to know exactly what Runsite is doing on your behalf.

Container model

Each Web Service runs as an isolated Docker container with its own CPU and memory limits. Isolation means:

Process isolation — your app cannot see or interact with other tenants’ processes.
Filesystem isolation — your container has its own root filesystem, separate from every other service.
Network isolation — services in the same project reach each other over private internal networking; everything else goes through the public ingress.

The image that runs in production comes from one of two sources:

Your Dockerfile — committed to your repo. We build it as-is.
Auto-detected stack — if there’s no Dockerfile, we detect the stack (Node, Python, Go, Java today) and build an image for you. Bring your own Dockerfile if your stack isn’t supported, or if you want full control over the build.

Deployment lifecycle

A deploy is triggered by a push to your connected branch, a manual Redeploy click, or an API call. The lifecycle is the same in all three cases:

push to main / redeploy
       │
       ▼
clone repository
       │
       ▼
build container image
       │
       ▼
start new container (status: DEPLOYING)
       │
       ▼
health check passes
       │
       ▼
traffic switches to new container
       │
       ▼
old container shuts down (status: RUNNING)

The new container only receives traffic after it passes the health check. If the build fails or the new container never becomes healthy, the previous version keeps serving traffic and the deploy is marked FAILED. Zero downtime is the default — you don’t need to opt in.

Deploy states

The status badge on every Web Service maps to one of these states:

State	Meaning	What you can do
`DEPLOYING`	Image is building or the new container is starting and waiting for its health check.	Watch the build log on the Overview tab.
`RUNNING`	Container passed health check and is serving traffic.	This is the steady state.
`STARTING`	Service is coming up after Start or a restart, no rebuild.	Wait — usually a few seconds.
`RESTARTING`	Container is restarting (manual restart or env-var change at runtime).	Wait. The previous container stays up until the new one is ready.
`STOPPING`	A Stop action is in progress.	Wait.
`STOPPED`	You stopped the service. Compute is released; env vars and disk are kept.	Click Start to bring it back.
`SLEEPING`	Service idled out and was paused. Next request wakes it.	Send a request, or disable sleep in Settings → Scaling.
`FAILED`	Build failed, or the container repeatedly failed its health check.	Check build/runtime logs; fix and Redeploy. The previous version keeps serving.

Builds are durable: a FAILED deploy never replaces a RUNNING one. You can keep iterating on a fix while production traffic stays on the last good build.

Filesystem & persistent data

Container filesystems on Runsite are ephemeral: everything your container writes to disk is lost when it restarts, redeploys, or scales. This is normal container behaviour and matches how every PaaS works under the hood.

Anything that needs to outlive a single container should live in a managed service:

PostgreSQL — relational data, transactions.
Redis — caches, queues, sessions, pub/sub.
Object Storage — user uploads, media, backups, static assets.

If your app genuinely needs a local writable disk (e.g. SQLite, file caches, custom data dirs), attach a persistent disk to the service. The disk is mounted at a path you choose and survives restarts, redeploys and scaling events. See Scaling & resources for limits.

Common pitfall

A SQLite file inside the container directory will appear to work, then vanish on your next deploy. Either move to PostgreSQL or attach a persistent disk and store the database file there.

Health checks & automatic restarts

Runsite checks that your container is alive in two ways:

Startup health check — runs during DEPLOYING and STARTING. The new container only takes traffic after this passes. If it never passes, the deploy is marked FAILED and the previous version keeps serving.
Liveness probe — runs continuously while RUNNING. If your process crashes or hangs, the container is automatically restarted. You don’t have to do anything; the service flips back to RUNNING once it recovers.

By default the health check is a TCP probe to your service’s port. Set an HTTP health check path in Settings → Health checks if you want Runsite to call a specific endpoint (e.g. /health).

Repeated crash loops eventually move the service to FAILED. Open the Logs tab to see why.

Where to next

Deploying — auto-deploy from Git and manual actions.
Scaling & resources — CPU, memory, disk, autoscaling, sleep.
Dashboard — every tab in the UI.