Skip to content

Template

Self-host Runwell on a server you own.

Agency project management with a client portal, on SQLite. It installs as an ordinary app that deploys, backs up and rolls back like yours.

At a glance

Image
ghcr.io/martin-business-consultants/runwell:2.1.2
Port
80, behind kamal-proxy
Health check
/up
Volumes
storage
Singleton
yes

What the install does

  • Generates SECRET_KEY_BASE and the three Active Record encryption keys that stand in for the credentials file
  • Sets APP_HOST from the domain, so links in mail point back at the install
  • Runs one container at a time, since SQLite takes one writer and a rollover of two is worse than a short blip
  • Registers the storage volume for backup, stopping the container so each backup is consistent
  • Asks for SMTP details if you have them, as ordinary variables you can change later

Installing does not deploy. Point an A record for the domain at the server, then press Deploy.

Before you start

  • 01

    A registered server and a ready runner.

  • 02

    A hostname. APP_HOST is set from it at install, and it is where links in mail point.

  • 03

    Somewhere off the machine for backups, and a copy of the three encryption keys kept somewhere else: a restored database cannot read the API keys stored in it without them, and no backup contains them.

FAQ

Questions about Runwell.

Read the Runwell guide
Why is there a few seconds of downtime on every deploy?

Runwell writes to SQLite, so it runs as a singleton: KamalCloud sets Kamal's drain_timeout to 0 and the old container goes before the new one boots. Two writers during a rollover would be worse than the blip.

There is no RAILS_MASTER_KEY. What replaces it?

SECRET_KEY_BASE and three ACTIVE_RECORD_ENCRYPTION_* secrets, generated once at install. The image's credentials.yml.enc is encrypted with a key no install has, so these stand in for it.

What do I need to keep a copy of?

The three ACTIVE_RECORD_ENCRYPTION_* values. They are not in a volume backup, and without them a restored database cannot read the API keys and tokens stored in it.

How do I upgrade?

Either change the image tag and deploy, or use Settings > Updates inside Runwell to update in place. The container runs whichever is newer, so neither route undoes the other.

Does it need a database accessory?

No. It runs on SQLite, and all four databases, their journals and every upload live in the one storage volume.

Run your own Runwell.

Connect a server, install Runwell, and deploy when the domain points at it.

Sign-ups are paused while the app is in maintenance.