Deploy Web Apps Using Push to Deploy
Deploy Node.js, Python, and AdonisJS applications directly from your GitHub repository with zero downtime.
Before You Start
Here's what you'll need:
- A Galaxy account (create one free if you haven't already)
- A GitHub repository with your application code
- Access to your GitHub account to authorize Galaxy
That's it. Seriously.
Payment Method Required
To deploy any application on Galaxy, you must add a valid payment method for identity verification. We'll place a small temporary hold on your card to verify it, then automatically refund it. You'll only be charged if you deploy a paid app.
Start a New Deployment
Head to your Galaxy dashboard and look for the Create New button in the top right corner. Click it and select Deploy New App to get started.
First Time?
If you're brand new to Galaxy, the Apps page will be empty. That's normal. You're about to change that.
Choose Your App Type
Galaxy supports four app types. Select the one that matches your application:
- Node.js: For JavaScript and TypeScript applications (versions 18, 20, and 22 supported)
- Python: For Python web frameworks like Flask, Django, FastAPI (versions 3.13, 3.12, 3.11, and 2.7 supported)
- AdonisJS: TypeScript-first Node.js framework with batteries included (supports AdonisJS 6)
- Meteor.js: For Meteor applications (covered in a separate guide)
AdonisJS Gets First-Class Support
AdonisJS has its own dedicated app type with pre-configured settings optimized for the framework. You don't need to select Node.js and configure it manually.
Connect Your Git Provider
Next up is authorizing GitHub. Select Continue with GitHub to connect your repository.
Currently, GitHub is the only supported Git provider for Push to Deploy. Bitbucket support is coming soon, so stay tuned if you're using that platform!
GitHub will prompt you to authorize the Galaxy application. This gives Galaxy permission to access your repositories and set up automatic deployments when you push code.
Check Your Account
Make sure you're authorizing the correct account. If you recently granted permissions, try refreshing the page if you don't see your repositories.
Select Your Repository
Browse through your repositories and pick the one containing your web application. You can filter by name if you have a lot of them.
Once you find it, hit Import to proceed.
Choose Your Plan and Container Size
Now you're picking the resources for your app.
Which Account?
If you're working with an organization, select it here. Otherwise, your personal account is already selected.
Pick Your Plan
Galaxy offers flexible plans: Sandbox (free, for testing), Production (for live apps), and Business (enterprise, coming soon). Each supports different container sizes and features.
Not sure which one is right for you? Start with Production for live apps, or Sandbox for testing and development. You can upgrade or downgrade anytime based on what you actually need.
For detailed pricing and feature comparisons, check out the Web Apps Billing documentation.
Plans Are Flexible
You can change plans anytime after deployment. Don't overthink this choice.
Select Your Container Size
Container size determines how much RAM and CPU your app gets. Bigger containers handle more traffic and heavier workloads, but cost more to run.
Start with a smaller container and scale up if you hit performance limits. Most apps do just fine starting smaller and growing as needed.
For the complete breakdown of container sizes, CPU allocations, and pricing, see the Web Apps Billing documentation.
Configure and Deploy
You're almost there. This final step is where you customize the deployment itself.
App Configuration
App Display Name: Give your application a friendly name. This is just for your reference in the Galaxy dashboard (it's not used in the URL).
Branch: Which branch should Galaxy watch and deploy from? Most teams deploy from main or master, but choose whatever branch makes sense for your workflow. Every push to this branch triggers an automatic deployment.
Custom Subdomain: Choose a memorable subdomain for your app (3-63 characters). This becomes your default URL (like myapp.sandbox.galaxycloud.app). Don't worry too much about it, though. You can always add a custom domain later.
Region: Galaxy runs your application across multiple regions to reduce latency:
- us-east-1 (Virginia, United States): East Coast and general US traffic
- eu-west-1 (Ireland, Europe): European users
Region Selection by Plan
Sandbox (free) apps are deployed to us-east-1 by default and don't include region selection. Production plans can choose any region during deployment. Want to change regions later? Upgrade to Production from your app's dashboard.
Build Configuration
This section varies depending on which app type you selected in Step 1.
Docker Preset: Select the Node.js version for your app. Options include:
- AdonisJS (Node.js 22)
- Next.js (Node.js 22)
- Node.js 18 LTS
- Node.js 20 LTS
- Node.js 22
Pick the version that matches what you're running locally. If you're not sure, use Node.js 20 LTS for stability or Node.js 22 for the latest features.
Install Command: Usually npm install. This runs before your build step.
Build Command: Optional. Use npm run build if your app needs compilation (TypeScript, bundling, etc.).
Start Command: How Galaxy starts your app. Usually npm start. Make sure this matches your package.json scripts.
Health Check Path: Optional. Set this to an endpoint your app responds to (like / or /health). Galaxy uses this to verify your app is running.
Docker Preset: Select the Python version for your app. Options include:
- Python 3.13
- Python 3.12
- Python 3.11
- Python 2.7 (Legacy)
Pick the version that matches what you're running locally. We recommend Python 3.12 or 3.13 for new projects.
Install Command: Usually pip install -r requirements.txt. This installs your dependencies.
Build Command: Optional. Most Python apps don't need a build step.
Start Command: How Galaxy starts your app. For example, python main.py or gunicorn app:app.
Health Check Path: Optional. Set this to an endpoint your app responds to (like / or /health). Galaxy uses this to verify your app is running.
AdonisJS apps get pre-configured settings optimized for the framework. You don't need to select a Docker Preset since Galaxy handles the runtime configuration automatically.
Install Command: Pre-filled with npm install.
Build Command: Pre-filled with npm run build for TypeScript compilation.
Start Command: Pre-filled with npm start to run your AdonisJS app.
Health Check Path: Optional. Set this to an endpoint your app responds to (like /health).
AdonisJS uses Node.js 22 under the hood. The framework-specific optimizations are already configured for you.
Use the PORT Variable
Your app must listen on the PORT environment variable that Galaxy provides. Don't hardcode port 3000 or 5000. Read from the PORT variable instead.
Environment Variables
Add any environment variables your app needs to run. Galaxy pre-adds PORT with a default value, but you can add more for database URLs, API keys and secrets, feature flags, and service credentials.
Click Add Environment Variable to add them one at a time, or use Add Multiple Environment Variables to paste several at once in KEY=VALUE format.
Never Commit Secrets
Never commit secrets to Git. Use environment variables for all sensitive data (API keys, database passwords, etc.).
Deploy!
Review everything one more time. Does the app name look good? Docker preset correct? Then hit the Deploy button and watch Galaxy work its magic.
You'll see the deployment in progress. Galaxy will clone your repository, install dependencies, run your build command (if you have one), start your application, run health checks, and make your app live.
Within a few minutes, your app is running and accessible at your default Galaxy URL.
You Did It!
That's it. You just deployed a web application to production. Not bad, right?
How Push to Deploy Works
After initial setup, the workflow is beautifully simple.
Every time you push code to your deploy branch, Galaxy automatically detects the change and starts a new deployment. Your app updates with zero downtime. If you push while a deployment is running, Galaxy cancels the old one and starts fresh with your latest code.
It's like your deployment workflow doesn't exist. You just keep coding and pushing, and your app stays up to date.
Understanding Sandbox vs Production Plans
Sandbox Plan (Free): Perfect for learning, testing, and early development. You get a free Nano container for experimenting without risk. Great for staging environments too.
Production Plan: For apps handling real traffic. You get multiple container sizes, auto-scaling, and the reliability your users expect. This is where you run production applications.
Start Small, Scale Later
Start with Sandbox to test deployment. Move to Production when you're ready for real users.
Troubleshooting Common Issues
Environment Variables and Secrets
Environment variables are your friend for storing secrets and configuration. Galaxy keeps them secure and doesn't expose them in logs or error messages.
Some common environment variables you might need:
Database Connections: DATABASE_URL or MONGO_URL for database connections
Third-Party Services: STRIPE_SECRET_KEY, STRIPE_PUBLIC_KEY for payments, TWILIO_AUTH_TOKEN for SMS, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for AWS services
App Configuration: NODE_ENV=production or equivalent for production mode, LOG_LEVEL=info to control logging verbosity
Add them one at a time using the form, or paste multiple at once in KEY=VALUE format (one per line).
For framework-specific environment variables, check your platform guide: Node.js, AdonisJS, or Python.
Common Questions
What's Next?
Monitor Performance
Track your app's health and resource usage
Scale Your App
Add more containers or upgrade container size as traffic grows
Push a new commit to your branch, and Galaxy will automatically redeploy. That's the beauty of Push to Deploy. Your workflow doesn't change. Your app just keeps getting updated.
From here, you might want to connect a custom domain instead of using the default Galaxy URL, scale your app to multiple containers for better performance and redundancy, set up automated backups for your databases, configure security measures like IP whitelisting, or monitor your app's performance and resource usage.
Your app is live. The hard part's done. Now comes the fun part: building features your users will love.