runlot
Reference

Glossary

The runlot terms used across the documentation and error messages.

Generation

One backup of a database. Generations are created hourly and identified in epoch/seq form (for example 3/17). The free plan keeps 24 generations (one day); the pro plan keeps 168 (seven days). See Backups and restores for details.

epoch

The lineage number of a project database. It increases by one whenever the database is restored or moved to another node. Even within the same project, a different epoch means a different data lineage, so requests from an earlier epoch are rejected.

You can read the current value from a worker.

const { project, epoch } = await env.db.identity();

It is also available in the Runlot-Epoch request header.

Slot

The unit of execution a node assigns to a single project. Each slot holds one process, one port, and one data directory. Deciding which node and which slot a project goes into is called placement.

Automatic stop (park)

Shutting down the worker process after a period with no requests (5 minutes by default). Data is preserved, and the project restarts automatically when a new request arrives. See Stop and resume for details.

This is different from the suspended state an administrator sets. An automatic stop is lifted by the next request, but a project an administrator suspended has to be un-suspended manually.

Cold

Unlike stopping only the process on the node, this is the state where the database has been moved to external storage. When a node runs low on disk space, the database is encrypted and kept off-site. Bringing it back takes about 6–7 seconds. See Reactivation for details.

wire

Connecting to the database directly over the PostgreSQL protocol. The address is <project>--<org>.wire.runlot.app:5433, and psql and PostgreSQL drivers use this connection. It reaches the same database as a worker's env.db, but behaves differently: a wire connection keeps its session, while env.db uses a fresh session per call.

front

The layer that determines the target project for an incoming request, checks access control, and restarts the project if needed. Runlot-* headers are added at this layer too. Both HTTP and wire requests go through the front.

org

The unit that owns projects and holds billing and permission settings. The second name in a deploy address is the organization slug (for example, me in my-app.me.runlot.app). See Team and roles.

Deploys and versions

Each runlot deploy run creates one version. Deploy history is preserved, and runlot rollback re-activates one of the earlier versions.

Access control and authentication

  • Access control — decides who can reach the deploy itself (public, org, password).
  • Authentication — manages the users who signed up for your application (env.auth).

The two work at different layers. See Access control.

On this page