Updates & versions

There are two things that get updated: Envoryx itself, and the runtime images your projects run on. They’re independent of each other, and both can be rolled back.

Updating Envoryx

Once a day Envoryx asks GitHub whether there’s a newer release and tells you on the dashboard and in Settings → General (ENVORYX_UPDATE_CHECK=false switches that off). Updating is quick:

# Docker Compose, in the folder of compose.yml
docker compose pull && docker compose up -d

# docker run: new image, then the same docker run command as before
docker pull ghcr.io/envoryx/envoryx:latest && docker rm -f envoryx

On Unraid it’s Check for updates / Apply update on the Docker page.

You don’t need to be nervous about it. Everything Envoryx knows lives in /config, /projects and /backups, so swapping the image never touches your projects - their containers even keep running while Envoryx updates. If a new version changes its database, that happens automatically and only forward, and right before the first change Envoryx writes an instance backup (pre-migrate-…). What’s new is in the changelog.

Sometimes a new version sets up containers differently, for example with an extra variable or mount. Envoryx doesn’t recreate running containers on its own for that. Instead the dashboard and the project show “the php container runs with an older setup; restart the project to update it”, and a Restart brings the container up to date when it suits you. After the update to 0.17.0 you’ll see this once for every running container, because the environment now counts too. After 0.18.0 it’s the Ruby containers once more, which get two new database variables (CACHE_DATABASE_URL and CABLE_DATABASE_URL). The new instance label, on the other hand, doesn’t make any container count as outdated. 0.18.1 and 0.19.0 change the PostgreSQL URL of every runtime but PHP, the web server configuration and the php.ini of PHP projects and the environment of the Node.js container, so restart your running projects once after updating to them.

If a hoster manages your instance, their fleet manager can also update it for you; how that works and what happens when a new version doesn’t come up is under Managed instances.

Image tags

Tag	What
`:latest`	the newest release
`:<version>`, e.g. `:0.12.0`	a fixed release
`:main`	the development branch - every push, may break

Going back

Didn’t like the new version? If it didn’t change the database schema, just start the old image again. If it did, the old image refuses to start, and its error message names the pre-migrate backup from right before the migration. Restore that one by hand with the container stopped, then start the old image. Restoring it from the new version’s interface doesn’t work, because the next start would migrate it again.

Runtime images

Your projects don’t run on the upstream images directly but on Envoryx’s own runtime images - envoryx-php, envoryx-node, envoryx-python, envoryx-go, envoryx-ruby, envoryx-java and envoryx-dotnet - which are built from the official ones.

Patch releases (8.5.3 → 8.5.4, say) arrive through weekly rebuilds of those images. Nothing changes behind your back, though: a project only picks up a rebuilt image when you Restart it. The restart pulls the tag again and recreates the container only if the image actually changed; until then the project keeps running on the build it has. A Start applies a newer build that’s already on the host, but it doesn’t ask the registry, and other changes (a worker, a variable) never swap images, so they don’t restart your database along the way.

A new project, a new runtime version or a newly added service is the exception: those pull the current image right away, so you never start something new on a stale build. Offline, the local image does.

If a rebuilt image causes trouble, you can go back. After a restart that swapped an image, the project’s Overview shows image updated with a Roll back button, which recreates the containers from the image they ran before. That works the same for MariaDB, Caddy and every other image. A rolled-back project stays on that image until you choose Use current image.

New versions (PHP 8.6, Ruby 4.1 …) are found by a weekly check against endoflife.date and Docker Hub, and the next Envoryx release offers them in the wizard. Pre-releases are marked preview, versions past their end of life EOL. You change a project’s runtime version in its Runtime section.