Versions and Deployments
A version is your code. A deployment is that code running. Here's how Galaxy uses both to keep your app live.
A version is your code. A deployment is that code running.
Every push creates a new version. Every time Galaxy runs that code (automatically or manually), it creates a new deployment. The same version can have multiple deployments, because you might run the same code with different configuration.
What Triggers a Deployment?
| Trigger | What Happened |
|---|---|
| Webhook | A push to your Git repository triggered automatic deployment |
| Manual | Someone clicked Deploy Now in the dashboard |
| API | A CLI command or programmatic API call |
| Rollback | Someone redeployed a previous version |
| Env Var Update | An environment variable change triggered a hot-swap |
| Retry | Someone manually retried a failed deployment |
| Automatic Retry | Galaxy automatically retried a failed deployment |
Configuration changes (variables, container size) create a new deployment of your current version. They don't create a new version. Code changes create a new version.
How Galaxy Keeps Your App Live
Galaxy uses different strategies depending on what changed. The goal is always zero downtime.
| Operation | Strategy | Result |
|---|---|---|
| New deploy | Blue-Green | Builds in the inactive slot, switches traffic once healthy |
| Environment variable change | Hot-swap | Rolling restart in the same slot |
| Plan: Free to Paid | Blue-Green (cross-cluster) | Domain changes from Free to Paid URL |
| Plan: Paid to Paid | Database update | No disruption, same cluster |
| Plan: Paid to Free | Blue-Green (cross-cluster) | Domain changes from Paid to Free URL |
| Container spec change | Rolling Update | Pods replaced with zero downtime |
| Rollback | Blue-Green | Traffic switches to previous slot (about 1-2 seconds) |
| Scale up/down | Direct patch | No pod replacement needed |
| Restart | Rolling Update | Pods replaced gracefully in the same slot |
Blue-Green Deployments
Galaxy keeps two deployment slots for your app. New code builds in the inactive slot. Once healthy, traffic switches instantly. If anything fails, your previous slot is still running.
Galaxy's rolling update strategy uses maxSurge: 1, maxUnavailable: 0. New containers spin up before old ones shut down. Your app never goes offline.
Common Scenarios
You push new code. Galaxy detects the commit, creates a new version, and deploys it automatically. One push, one version, one deployment.
You fix a broken environment variable. Go to Variables, update the value, and click Deploy. Galaxy creates a new deployment of your current version (no new version, no rebuild). Your app restarts with the fixed config.
You need to roll back. Go to Versions, find the last stable version, and click Redeploy. Galaxy deploys that old version as a new deployment. Takes about 1-2 seconds. Your users won't notice.