Automated releases on your own server with Coolify
How we keep small and medium projects tidy on a single server, and what we watch out for.
Health checks, backward-compatible migrations and a rollback plan for releasing a new version without users noticing.
A site going down for a few minutes during a release looks minor, but becomes unacceptable for a team that ships often.
While the old version runs, the new one starts; once verified healthy it takes the traffic, then the old one is stopped. Docker and a reverse proxy make this flow easy to build.
It should confirm database connectivity as well as the process being up. Otherwise a broken release starts receiving traffic.
This is the hardest part. Two versions run side by side for a short time, so the schema has to be backward compatible. Instead of renaming a column, add a new one, write to both, move the data, and drop the old one in a later release.
You should be able to run the previous image with one command, so keep images tagged by version. If a migration cannot be undone, make sure the code also works with the old schema.
How we keep small and medium projects tidy on a single server, and what we watch out for.
Good code review does more than catch bugs. Speed it up with small changes, clear expectations and automation.
An MVP is not a half-finished product. A practical method for finding the smallest scope that solves one problem.