Versions and Deployments
Understand the difference between versions (your code snapshots) and deployments (your code running). Master rollbacks, configuration changes, and how Galaxy keeps your app live.
Versions and deployments sound similar, but they're different things in Galaxy. Once you understand the difference, managing your app becomes much easier.
Here's the short version: a version is your code. A deployment is that code running.
What's a Version?
Every time you push code, Galaxy creates a version. Think of it as a snapshot. Version 1, version 2, version 3. Each one captures your code at that exact moment.
Versions never change. Once created, they're locked. This makes rollbacks safe, you can always go back to exactly what was running before.
Example: Pushing Code
You push a commit to main
Galaxy detects the change
Galaxy creates Version v5
Galaxy deploys v5 automatically
Your app is now running v5One push, one version. Simple.
What's a Deployment?
A deployment is your code actually running. When Galaxy takes a version and spins up containers, that's a deployment.
Here's the key insight: the same version can have multiple deployments. Why? Because you might deploy the same code with different configuration.
Example: Fixed Environment Variable
Version v5 is running
You notice an error related to a missing environment variable
You update the variable in Galaxy
You click Deploy
Galaxy creates a new deployment of v5 (with the fixed variable)
Your app restarts and works nowYou're still running v5. But now v5 has two deployments: one that failed, one that succeeded.
Configuration changes create new deployments. Code changes create new versions.
Versions vs Deployments
Here's the simple comparison:
Version
A snapshot of your code. Never changes. One per push. Shows your actual code.
Deployment
Running that code. Changes every time. Many per version. Shows status and logs.
Full Comparison
| Version | Deployment | |
|---|---|---|
| Created when | You push code | Code runs (automatic or manual) |
| Can change | Never | Every time you deploy |
| How many | One per push | Many for the same version |
| Shows | Your code | Status, logs, timing |
What Triggers a Deployment?
Deployments can be triggered in different ways. Galaxy tracks these in the Deployments page:
| Trigger | What Happened |
|---|---|
| Webhook | Push to GitHub triggered automatic deployment |
| Manual | Someone clicked "Deploy Now" in the dashboard |
| API | CLI command or programmatic API call |
| Rollback | Someone rolled back to a previous version |
| Env Var Update | Environment variable change triggered hot-swap |
For full details on triggers and deployment history, see the Deployments dashboard guide.
What You Actually See
In Galaxy, you see two pages:
Versions Page: Shows all your code snapshots. v1, v2, v3, etc. Click on one to see its history and redeploy it anytime.
Deployments Page: Shows every time code ran. Success, fail, in progress. Click on one to see detailed logs explaining what happened, plus what triggered each deployment.
How Galaxy Achieves Zero Downtime
Galaxy uses different strategies depending on what you're changing. The goal is always the same: keep your app running while updates happen in the background.
| Operation | Strategy | What Happens | Result |
|---|---|---|---|
| New deploy | Blue-Green | Creates deployment in inactive slot, then switches traffic | Zero downtime via service selector patch |
| Environment variable change | Hot-swap | Updates configuration, triggers rolling restart | Same slot, containers replaced gracefully |
| Plan: Free to Paid | Blue-Green (cross-cluster) | Migrates to new cluster | Domain changes from Free to Paid URL |
| Plan: Paid to Paid | Database update | Same cluster, no container migration | No disruption |
| Plan: Paid to Free | Blue-Green (cross-cluster) | Migrates to Free cluster | Domain changes from Paid to Free URL |
| Container spec change | Rolling Update | Strategic merge patch on deployment | Same slot, pods replaced with zero downtime |
| Rollback | Blue-Green | Switches traffic to previous slot | Instant (about 1-2 seconds) |
| Scale up/down | Direct patch | Replica count change | No pod replacement needed |
| Restart | Rolling Update | Triggers via annotation | Same slot, pods replaced gracefully |
Blue-Green Deployments
Galaxy maintains two deployment "slots" for your app. When you deploy new code, Galaxy builds it in the inactive slot. Once healthy, traffic switches instantly. If anything fails, your old code is still running.
The rolling update strategy uses maxSurge: 1, maxUnavailable: 0, meaning Galaxy always keeps your current containers running while spinning up new ones. Your app never goes offline during updates.
Three Common Scenarios
Scenario 1: You Push New Code
Push Code to GitHub
You commit and push your changes to your deploy branch.
Version Created Automatically
Galaxy detects the new commit and creates Version v5.
Deployment Starts
Galaxy automatically begins deploying v5 to your servers.
Build Succeeds
Your app compiles and dependencies install without issues.
Deploy Succeeds
Containers start, health checks pass, and your app goes live.
Done
Simple. One push, one version, one deployment.
Scenario 2: Something's Wrong, You Fix the Configuration
You Spot an Error
Your app is running v5 but there's a problem.
Fix the Configuration
Go to Variables and update the environment variable.
Trigger Deploy
Click the Deploy button to apply the new configuration.
Deployment 2 of v5 Starts
Galaxy begins a new deployment of the same version with new config.
Build Skips
No code changed, so Galaxy skips the build step.
Deploy Succeeds
Your app restarts with the fixed variable and works now.
Same Version, New Deployment
Still running v5, but now with two deployments: one failed, one successful.
Scenario 3: Deployment Failed, You Need to Rollback
Version v5 is Broken
Your latest deployment isn't working as expected.
Navigate to Versions
Go to the Versions page and find your previous stable version.
Find Working Version
Locate Version v4, which you know was working before.
Click Redeploy
Select v4 and click the Redeploy button to restore it.
Deployment 2 of v4 Starts
Galaxy begins deploying the old version with a new deployment.
Build and Deploy Succeed
Your app compiles, deploys, and comes back online with v4.
Back to v4
Old code, new deployment. Zero downtime. Your users never noticed.