Keeping an app up to date

Every night we check whether a newer build of your app has been published.

How we know

Most self-hosted software is published under a moving tag like latest, which never changes even when the software does. So the tag cannot tell you what version you are running.

Instead we record the exact image your container was built from, re-check the tag nightly, and compare. If it now points at a different build, an update is available. That is what the notice on your app means.

Applying one

Open the app and apply the update from its Overview tab. The container is recreated on the new image. Your data lives on a separate volume and is not touched.

Take a snapshot first. You get one free, and this is exactly what it is for.

If the new image fails to start, we roll back to the exact build you were on before — identified precisely, not by tag, because the tag now points at the version that just failed.

Automatic updates

Off by default, and switchable per app.

We leave it off because an update is whatever the upstream project published, not a patch we wrote and tested. For an app you depend on, being told and choosing when is usually better than waking up to a changed application.

Databases are never updated automatically

If your app has a database, that database is deliberately excluded from updates, automatic or otherwise.

Database software does not upgrade in place by restarting on a newer image — a major version will refuse to start against an existing data directory, and the app goes down until someone migrates it by hand. Leaving the database where it is keeps your app running. If you need a database version changed, open a ticket and we will plan it with you.