Versions
Every time you push code to your deploy branch, Galaxy creates a new version. This section shows all your code snapshots so you can see your deployment history and rollback to any past version if needed.
Understanding Versions
A version is a snapshot of your code at a specific moment in time. Every push creates a new version. Versions are immutable, meaning they never change after creation. This makes rollbacks possible and safe.
Think of versions like Git commits, but captured for Galaxy deployment. Each version is a complete, unchangeable record of your code.
Version History
The version history table shows all your versions. Each row displays:
| Column | Description |
|---|---|
| Version | The version number. The currently active version shows an Active badge next to it |
| Source | The Git branch and short commit hash together |
| Created | When this version was created |
| Created By | The username of the person who pushed the code |
| Runtime | The runtime and version used for this build |
| Deployments | Total deployment count with a breakdown of outcomes (e.g., 1 total (1 successful), 2 total (2 failed)) |
Click any version to see full details about it.
Version Details
Click any version in the list to open its detail page. The page header shows the version number with an Active badge if this is the currently running version. The Rollback to This Version button sits in the top right corner, grayed out if you're already on this version.
The page is split into two sections: Overview and Deployment History.
Overview
The Overview card shows everything about the code snapshot itself:
- Branch and commit: Displayed at the top as branch name and short commit hash
- Commit message: The message from the Git commit, shown below the branch and hash
- Commit author: The full name and email of the person who authored the commit
- Created by: The Galaxy username of the person who triggered the deployment
- Created: When this version was created
- Runtime: The runtime and version used to build this version
- Build Commands: A grid showing the Install, Build, Start, and Root commands Galaxy used for this version
- Deployments: A quick summary at the bottom of the card (e.g.,
1 total · 1 successful)
Deployment History
Below the Overview card, the Deployment History section lists every time this version has been deployed. Each entry shows:
- Status badge: Success, Failed, In Progress, or Cancelled
- Deployment ID: A short identifier for this specific deployment run
- Username: Who triggered it
- Date: When this deployment ran
- Duration: How long the deployment took to complete
- View Details: A button to open the full deployment log and timeline
Rollback to This Version
The Rollback to This Version button creates a new deployment of this version's code. If this is already the active version, the button is disabled. Your app switches instantly with zero downtime.
Rollback to a Previous Version
Current version has issues? Your latest deployment broke something? Rollback to any past version in seconds.
Find the version you want to go back to and click "Rollback to This Version". Galaxy instantly switches your app to run that version.
Rollback is safe because versions are immutable. You're switching to code that was already tested and working before. No surprises.
How Rollback Works
- Find the working version you want to use
- Click "Rollback to This Version"
- Galaxy creates a new deployment of that old version
- Your app switches to the old version instantly
- Zero downtime. Users don't notice the switch.
It's that simple. The old version becomes your current version. New deployments will be of this version going forward until you push new code.
Your Safety Net
If something breaks in production, you can revert to a working version in seconds while you figure out what went wrong.
Version vs Deployment
Confused about the difference? Here's the simple explanation:
Version: A code snapshot. Created every time you push. Immutable. One per push. Shows your code.
Deployment: Running that code. Changes every time you deploy. Many per version. Shows what happened when code ran.
One version can have multiple deployments. You might deploy the same code several times if you change configuration (environment variables, container size, etc.) but not the code itself.
Want to understand this better? Check Versions and Deployments for the full detailed guide.
Immutability Is What Makes Rollbacks Safe
You can rollback to any version. But you can't change a version after it's created. That immutability is what makes rollbacks reliable.
Rollback Scenarios
Here are common situations where rollback saves the day:
New Code Has a Bug
You pushed new code that broke something. Rollback to the previous version while you fix the bug. Your app works again instantly. Fix the code, push it, deploy again.
Performance Regressed
Last deployment made your app slower. Rollback to the previous version. Performance is back. Investigate the code change to see what caused the slowdown.
Database Compatibility Issue
New code requires a database schema change you haven't done yet. Rollback to the old version, run the migration, then redeploy new code with the migration complete.
Accidental Bad Merge
Bad code got merged to main. Rollback to before the merge. Delete the bad commit from your Git repository. When you fix it, push new code and deploy.
Hotfix Needed Fast
Production is down. You need a quick fix. Rollback to the last known working version. Your app is working again. Now take time to fix the bug properly.
Recovery Considerations
When you rollback, keep these in mind:
Your code goes backward: You're running old code. Any bugs that version had are back too.
Database changes don't rollback: If the old version expects a different database schema, you might have issues. Be careful if you've made database migrations.
New features disappear: Users won't have access to features from the broken version. They'll only have what the old version provided.
Configuration persists: Environment variables, settings, and configuration from your new version stay. Make sure they're compatible with the old code version.
Usually rollback works fine. But if you've made database migrations, you might need to handle that carefully.
Version Cleanup
Versions are kept forever by default. They don't cost you anything, so Galaxy keeps them all. You can always rollback to any version, no matter how old.
But if you want to clean up your version list, check with support about archival or deletion policies. Some versions might be removable if they're very old.
Working With Many Versions
As your app matures, you'll accumulate many versions. Use filters and search to find the one you need:
Filter by branch: Show versions from a specific branch.
Filter by creator: Show versions created by a specific team member.
Search by commit: Paste a commit hash to find that specific version.
These tools help you navigate your version history when you have dozens or hundreds of versions.
Deployment Recording
Each version shows all its deployments. This gives you a complete record of every time code has run.
Successful deployments: Working versions, code that compiled and ran correctly.
Failed deployments: Code that broke things. Useful for comparing what went wrong.
Configuration changes: Same code deployed with different settings.
This history is valuable for understanding your app's behavior over time.