Install on a VM

Honest limits

What openrail v0.1 does not do, said plainly, with what to do about each one.

Beta

These work in 0.1.0 but are not yet covered by the end-to-end tests that run on fresh VMs for every release. Use them, and keep backups and a way back.

One control host

With one host, a host failure stops everything until it is rebuilt. With more hosts, apps on other hosts keep serving (with a second ingress host), but deploys, cron and the console stop until the control host is back or rebuilt.

What to do: copy state snapshots off the host (Control plane backup), keep database backups on, join a second host with the ingress role, and read Rebuild the control host: a one-command rebuild on a new VM is not supported in 0.1.0.

Cron pauses with the control plane

Cron runs are scheduled by the control plane. While it is down they do not run; missed runs are listed, not replayed.

Databases run on one host each

No high availability and no automatic failover. If the database's host dies, restore a backup to a copy on another host and promote it. Keep backups on.

Volumes mean a short gap on deploys

A volume can be mounted by one container, so the old container stops before the new one starts.

One public entry point by default

Without a second ingress host, all public traffic enters through one machine. There is no global edge, CDN or DDoS protection; put Cloudflare or a similar service in front if you need them.

No autoscaling, no volume caps

Replicas and processes are set by you. Volumes have no size cap and share the host disk; alerts fire at 80% of the filesystem.

Recovery point for the control plane

The control plane snapshots its state every hour to the host's own disk, keeping 24 hourly and 7 daily snapshots. Streaming to the bucket is later work. Until then the recovery point is one hour, plus however often you copy the snapshots off the host.

Retention

Metrics are kept 30 days. Logs are kept 7 days on each host.

IPv4 and Ubuntu

IPv4 only; containers have no IPv6. Ubuntu 24.04 is the tested OS.

Private mode is not a guarantee

Private mode leaves no inbound port open, which removes one way in and only that one. A bug in an app you deploy, a stolen Cloudflare, GitHub or cloud account, or a compromised dependency can still get in. It also makes Cloudflare a hard dependency: if the tunnel is down, your apps and console are too.

Sign-in has a limit per account as well as per address, so someone sending enough wrong passwords from many addresses can keep the real owner out for 15 minutes at a time. Cloudflare Access on the console hostname stops them before they reach it.

What to do: follow the account protections in the guide, keep backups off the machine, and keep treating the host as something that can be broken into.

You own the machines

You own the hardware and the OS. Security updates are automated; reboots are yours. See Upgrading and host maintenance.

Not yet

The one list of what this release does not do yet. Other pages link here instead of naming a release.

  • The Railway project importer. Use the manual move.
  • Master key rotation. See Rotate the master key.
  • Enforcing Require two-factor authentication for everyone at login. The setting is stored and shown.
  • Console screens for adopt mode after a restore. See Restore.

View as Markdown Edit this page