There’s an unwritten rule in our profession: never deploy on a Friday. I followed it for years when I was writing code for a living. Not because deploying was hard, but because undoing a bad deploy was. If something broke at 6pm, your weekend was gone.
I’ve said before that on Galaxy you can deploy on a Friday afternoon. Today I want to actually earn that claim by walking you through what happens under the hood when you push code. Because “trust me” never worked on me either.
A version is not a deployment
First, a distinction that changes how you think about shipping. On Galaxy, a version is your code, and a deployment is that code running. Every push creates a new version. But changing configuration (an environment variable, a container size) creates a new deployment of the same version. This is the foundation of everything else: your rollback target is always precise, and versions are kept indefinitely. Any version you’ve ever shipped is still there, one click away.
Two slots, not one
Galaxy keeps two deployment slots for every app. When you push, your new version builds in the inactive slot while the current one keeps serving traffic, completely undisturbed. Galaxy then runs health checks against the new build. Only when it’s confirmed healthy does traffic switch over instantly. If the build fails, or your app won’t start, nothing happens to production and your users never knew you tried.
A failed deploy on Galaxy is a private event, not a public one.
Rollback is the same trick in reverse
Because the previous slot is still warm, rolling back isn’t a rebuild, it’s a traffic switch. Just open Versions, find the last stable one, and click Redeploy. It takes about one to two seconds. That’s the entire disaster recovery procedure.
Config fixes don’t rebuild anything
Broke an environment variable? Fix the value and deploy. Galaxy does a hot-swap: a rolling restart of your current version with the new config. Same code, new environment, zero downtime.
And when containers do get replaced (resizes, restarts), Galaxy rolls them with a strict rule: the new container comes up before the old one shuts down, and at no point is any container unavailable. Your app never dips below full capacity during an update.
Change one habit: deploy smaller, more often
So what should you do with all this? The riskiest deploy has always been the big one: three weeks of changes shipped in a single push, where any of fifty commits could be the culprit. When shipping is cheap and reverting takes two seconds, the batch size that made sense in the scary world stops making sense. Ship the small thing today.
One honest caveat: your data
Because I promised you the real picture: Galaxy can roll back your code in seconds, but it can’t roll back your data. If a deploy runs a database migration, make it backwards-compatible: add columns before you rely on them, and don’t drop anything the previous version still reads.
On paid plans you can run migrations as a pre-deploy command: it executes after the build, before traffic switches, and if it fails, the deployment stops and your current version keeps running. That’s the last piece of the Friday-deploy puzzle.
Try it this Friday
The full mechanics — deployment triggers, strategies per operation type, and what each one means for uptime — are documented in Versions & Deployments.
This Friday, ship something small in the afternoon.
Worst case, you’re two seconds from where you started.
Not on Galaxy yet? Create an account and your first deploy takes minutes.