Settings
Manage domains, Git settings, health checks, custom logging, scaling, and deployment options for your app.
The Settings page is split into four tabs: General for Git configuration, health checks, and app deletion; Networking for domain management and IP whitelisting; Scaling for autoscaling configuration; and Logging for custom log destinations.
General
Git Configuration
Manage which Git account connects to Galaxy and which repository you're deploying from. You can change these anytime.
Git Account: Which Git provider account Galaxy should use to access your repositories. If you want to switch accounts, you can disconnect and reconnect here.
Repository: Which repo contains your app code. Push to your deploy branch, Galaxy detects the change and automatically deploys.
Branch: Which branch Galaxy watches. Usually main or master, but you can use any branch. Every push to this branch triggers a deployment.
Change these settings if you need to deploy from a different repository, switch accounts, or watch a different branch.
Health Check
Galaxy monitors your app's health by checking a specific endpoint regularly. Set this to a route your app responds to quickly (like /health or /status).
If the health check fails repeatedly, Galaxy knows something's wrong. It might restart containers or alert you, depending on your plan.
Health Check Path: The HTTP path Galaxy pings to check if your app is healthy. Must start with /. Defaults to / if not specified.
Pre-Deploy Command: Runs after the build step but before deployment. Use it for tasks like database migrations or data seeding. Your command runs within your private network and has access to your environment variables. If the command fails, the deployment stops. Available on paid plans only.
Container Stop Grace Period: How many seconds Galaxy waits after sending SIGTERM before force-stopping your container. Defaults to 5 seconds. You can set this anywhere from 5 to 600 seconds. Increase it if your app needs more time to finish processing requests or close database connections during shutdown.
Default Health Check Path
If you don't specify a health check path, Galaxy defaults to /. Make sure your app responds with a 200 status code at the root path, or configure a dedicated health check endpoint.
Don't have a health check endpoint? Your app's root path (/) works as a basic check. For more robust monitoring, consider adding a dedicated /health endpoint that verifies your app's critical dependencies (database connections, external services, etc.).
Build Commands (Web Apps)
For Node.js, Python, and AdonisJS apps, you can customize the build process:
Install Command: How Galaxy installs dependencies. Usually npm install or pip install -r requirements.txt.
Build Command: How Galaxy builds your app. For example, npm run build for TypeScript compilation or asset bundling.
Start Command: How Galaxy starts your app. Something like npm start or python app.py.
These commands run in order during deployment. Customize them if your app has non-standard requirements.
Danger Zone
At the bottom of the General tab, you'll find destructive actions. These require confirmation and can't be undone.
Delete App: Permanently removes your app from Galaxy. All containers stop, all data is lost, and your domain becomes available for others to claim.
Think carefully before using these. There's no recovery option.
Networking
Domain Management
Your app gets a primary domain when you deploy. The Networking tab lets you manage all your domains in one place.
Primary Domain
When you deploy, you choose your app's primary domain during the setup process. It's permanent and works immediately with HTTPS.
For Meteor apps, your domain looks like myapp.meteorapp.com. You pick the subdomain name, and if it's available, it's yours.
For Web Apps (Node.js, Python, AdonisJS), you also choose a custom subdomain during deployment. Something like myapp.sandbox.galaxycloud.app. Pick a name that's easy to remember and relevant to your app. If the subdomain is available, you can claim it.
Your primary domain never changes once set. You can't delete it, but you can toggle it on or off. It's permanent and always available to your app.
All domains get automatic HTTPS. Your app is always secure, no matter which domain you use.
Custom Galaxy Subdomain
You can add a memorable Galaxy subdomain for your app. This gives you a cleaner URL while still using Galaxy's infrastructure.
One Custom Subdomain Per App
You can only have one custom Galaxy subdomain per app. Choose it wisely. If you need multiple URLs, consider using custom domains instead.
Custom Domain
Got your own domain? Connect it here for complete branding control. Use app.yourcompany.com or yourcompany.com directly.
Setting up a custom domain requires DNS configuration at your registrar (usually just pointing a CNAME record to Galaxy). Galaxy handles SSL certificates automatically, so your custom domain gets HTTPS automatically too.
Custom domains are only available on paid plans. Free plans are limited to your primary Galaxy-hosted subdomain.
For detailed instructions on DNS configuration, SSL certificates, and troubleshooting, see the Custom Domains guide.
Configured Domains
The Networking tab shows a table of all your configured domains with their status, encryption state, and available actions. From here you can see which domain is set as primary, check if your domains are active, and remove domains you no longer need.
IP Whitelisting
IP Whitelisting shows the outbound IP addresses your app uses for external connections. This is essential when you need to configure firewall rules or restrict database access to specific IPs.
Know your app's outbound IPs: Galaxy displays the exact IP addresses your containers use for outgoing connections.
Configure firewall rules: Add these IPs to your external service's allow list (MongoDB Atlas, AWS RDS, etc.).
Restrict database access: Lock down your database to only accept connections from your Galaxy app's IPs.
Paid Plans Only
IP Whitelisting is available on the Professional plan for Meteor Apps only. Lower plans will see an upgrade prompt instead.
For more details on outgoing connections and how Galaxy handles IP addresses, see the Container Environment guide.
Scaling
Traffic isn't constant. Some apps spike at certain times, others grow steadily over months. The Scaling tab lets you configure autoscaling so Galaxy adjusts your container count automatically based on demand.
Paid Plans Only
Autoscaling requires a paid plan. Free plans will see an upgrade prompt on this tab with all options disabled.
Autoscaling Modes
There are three modes to choose from:
None: Autoscaling is disabled. Galaxy won't add or remove containers automatically. You control replica count manually from the Containers page. This is the default.
Basic: Set a minimum and maximum replica count. Galaxy scales your containers up or down automatically based on CPU utilization, targeting 70% usage. You define the floor and ceiling; Galaxy handles everything in between.
Advanced (Professional plan): Automatically scale replicas based on custom metrics and schedules. Available on the Professional plan only.
Setting Up Basic Autoscaling
Pick Basic to get started. A slider appears showing a range from 1 to 10 replicas. Drag the two handles to set your minimum and maximum.
For example, setting a range of 1 to 5 means Galaxy will always keep at least one container running and will scale up to five when CPU usage climbs. When traffic drops, it scales back down to save costs.
Start Conservative
Not sure what range to pick? Start with a small window, like 1 to 3, and watch how your app behaves. You can always adjust the range later.
Saving Changes
When you adjust the autoscaling mode or replica range, an Unsaved configuration changes bar appears at the bottom of the page. Click Save Configuration to apply. Hit Discard to revert before saving.
Logging
Ship your application logs to an external endpoint in addition to Galaxy's built-in log viewer. This is perfect for teams that already use centralized logging tools like Elasticsearch, OpenSearch, or Datadog. Your logs keep flowing to Galaxy's viewer as usual, so you're adding a destination, not replacing one.
Paid Plan Required
Custom log destinations require a paid plan, including Web Apps. Free plans will see an upgrade prompt on this tab.
Setting Up a Custom Log Destination
Head to Settings > Logging in your app's dashboard. Here's how to configure it:
Enable Custom Logs: Flip the toggle to activate log shipping. When disabled, logs only go to the built-in viewer.
Provider: Choose between Elasticsearch and HTTP. Pick Elasticsearch if you're sending logs directly to an Elasticsearch or OpenSearch cluster. Pick HTTP for any other endpoint (Datadog, Logstash, a custom HTTP receiver, etc.).
Host: The hostname or IP address of your log endpoint (for example, elastic.example.com).
Port: The port number your endpoint listens on (1 to 65535). Defaults to 443.
Username and Password (optional): HTTP Basic auth credentials, if your endpoint requires authentication.
Index Name: The Elasticsearch index Galaxy writes logs to. Something like app-logs or my-app-production.
URI Path: The path appended to the host for log delivery. For example, /v1/logs.
TLS: Enable TLS to encrypt the connection between Galaxy and your log endpoint. Enabled by default.
Verify TLS: When enabled, Galaxy verifies the endpoint's TLS certificate. Keep this on unless you're using a self-signed certificate in a controlled environment.
Saving and Applying Changes
After filling in your configuration, click Save Configuration. Changes take effect on your next deployment. If you make a mistake, hit Discard before saving to revert.
Changes Apply on Next Deploy
Your custom log configuration is applied during deployment. After saving, trigger a new deploy (or wait for your next push) for logs to start flowing to your endpoint.
Deleting a Configuration
Need to stop shipping logs to your external endpoint? Click Delete Configuration at the bottom of the Logging tab. Galaxy asks for confirmation before removing it. Once deleted, logs will only be available in the built-in viewer. This change also takes effect on the next deployment.
Migrating from USER_LOG_DESTINATION (Meteor Apps)
If you're a Meteor user currently using USER_LOG_DESTINATION in your settings.json, migrate to the dashboard configuration instead.
USER_LOG_DESTINATION Will Be Deprecated
The settings.json method is legacy and will be deprecated in the future. Switch to the dashboard configuration: it requires no code changes, works across both Meteor and Web Apps, and is easier to manage going forward.
Common Questions
What's Next?
Plans
The Plans section is where you manage your app's resources. This is how you scale up when traffic increases, downsize when you want to save money, or adjust your hosting tier based on what your app actually needs.
Deployments
The Deployments section shows every time your app has been deployed. Each deployment is a complete cycle: Galaxy takes your code, builds it, and gets it running on containers.