The KamalCloud app is down for maintenance. Sign-ups and sign-ins are paused.App down for maintenance. Sign-ups paused. Details
Template
Agency project management with a client portal, on SQLite. It installs as an ordinary app that deploys, backs up and rolls back like yours.
Installing does not deploy. Point an A record for the domain at the server, then press Deploy.
A registered server and a ready runner.
A hostname. APP_HOST is set from it at install, and it is where links in mail point.
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.
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.
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.
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.
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.
No. It runs on SQLite, and all four databases, their journals and every upload live in the one storage volume.
Connect a server, install Runwell, and deploy when the domain points at it.
Sign-ups are paused while the app is in maintenance.