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. Deploying was easy; undoing a bad deploy was the problem. 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 your code. A deployment is that code running.
This distinction changes how you think about shipping. Every push creates a new version. 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.
Every app gets 2 deployment slots
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.
Rollback is the same trick in reverse
Because the previous slot is still warm, a rollback is just a traffic switch. Open Versions, find the last stable one, and click Redeploy. It takes about 1 to 2 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: 3 weeks of changes shipped in a single push, where any of 50 commits could be the culprit. When shipping is cheap and reverting takes 2 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 rolls back your code in seconds. Your data is a different story. 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 2 seconds from where you started.
Not on Galaxy yet? Create an account and your first deploy takes minutes.