Running runlot on your own machines
The same product on your servers or your Kubernetes cluster, with your PostgreSQL, your object store, and a licence file. Your data never leaves.
Self-hosted runlot is the product you use at runlot.io, installed where you decide. The control plane, the data nodes, the Git hosting and the dashboard run on machines you own. The metadata lives in a PostgreSQL you run, backups and files go to an S3-compatible store you run, and the only thing we give you is a signed licence file.
Three things are true of every installation and are worth reading before anything else.
You hold the master key, and we have no copy
openssl rand -hex 32Every backup is encrypted under a key derived from this value. The installer reads it from your configuration and refuses to generate one. If the value is lost, every backup is unreadable, and there is nothing we can do about it. Keep it where you keep your other root secrets, somewhere that survives the machine.
That refusal is deliberate. A key we could regenerate would be a key we could hold, and then "your data never leaves" would not be true of us either.
The licence is a file, checked offline
The licence is one line of text signed with a key we keep offline. The control plane re-reads it every minute. There is no licence server, no activation call, and no telemetry: nothing in the product makes a network request to us.
| State | What changes |
|---|---|
| valid | Nothing. |
| grace | The dashboard shows a banner. Everything still works for 30 days after the expiry date. |
| restricted | New deploys, new projects and new sign-ups are refused with license_* errors. Everything already running keeps serving. Replacing the file lifts the restriction within a minute, with no restart. |
An expired licence never stops a running app. That is the rule the state table is built around.
Three shapes
| Tier | Machines | What runs where |
|---|---|---|
eval | 1 | Everything on one host, with PostgreSQL and MinIO from the metapackage. For trying it out, not for production. |
single | 2 | A control plane and one data node. Your PostgreSQL and S3. The data node holds up to 64 projects. |
ha | 4 or more | A control plane and N+1 data nodes, so the projects of a lost node have somewhere to go. |
The control plane can also run in Kubernetes with the Helm chart while the data nodes stay on VMs. The data node is a plain machine on purpose: it runs one process per project under its own cgroup, and the privileges that needs are easier to grant to a VM than to a pod.
Where to go next
Requirements
Machines, PostgreSQL, object store, DNS, and the two DNS facts that bite.
Install with packages
apt and dnf on Ubuntu, Debian, RHEL and Rocky — the control plane, then each node.
Install with Helm
The control plane in your cluster, the nodes as packages.
Operate
Upgrades, the licence, air-gap bundles, GitOps, and what we need when you ask for help.