Settings
Manage Git and build settings, domains, scaling, logging, security, and notifications for your app.
Your app's Settings page is where you control how it builds, where it lives, how it scales, and who can reach it. It's split into six tabs: General (Git, build commands, health checks, app deletion), Networking (domains, IP whitelisting), Scaling (autoscaling), Logging (external log destinations), Security (IP access and rate limiting), and Notifications (event alerts).
Most changes save when you click the confirm button on that tab. A few apply on your next deployment, and the page tells you when that's the case.
General
The General tab sets the defaults Galaxy uses every time it builds and deploys your app.
Git Configuration
Git Account: The provider account Galaxy uses to access your repositories. Disconnect and reconnect here to switch accounts.
Repository: The repo Galaxy deploys from. Pushing to your deploy branch triggers an automatic deployment.
Branch: The branch Galaxy watches, usually main or master. Every push triggers a deploy.
To stop automatic deployments, click Disconnect push-to-deploy. Your build settings are preserved and CLI deployments still work. Reconnect anytime without reconfiguring.
Build Commands
These control how Galaxy turns your source into a running app. Meteor apps use a fixed build step, so you'll see fewer fields.
Install Command: Runs before meteor build. Defaults to meteor npm install. Use meteor npm ci for reproducible builds.
Root Directory: Path to your app if it lives in a subdirectory. Leave empty if it's at the repo root.
Pre-Deploy Command: Runs after build, before containers go live. Use it for migrations. Fails the deployment if it errors. Paid plans only.
Health Check Path: The HTTP path Galaxy pings to verify your app is healthy. Must start with /. Defaults to /.
Container Stop Grace Period: Seconds Galaxy waits after SIGTERM before force-stopping. Defaults to 5, max 600. Paid plans only.
Root Directory: Path to your app if it lives in a subdirectory. Leave empty if it's at the repo root.
Install Command: How Galaxy installs dependencies, for example npm install or pip install -r requirements.txt.
Build Command: How Galaxy builds your app, for example npm run build. Optional if no build step is needed.
Start Command: How Galaxy starts your app, for example npm start or python app.py.
Pre-Deploy Command: Runs after build, before containers go live. Use it for migrations. Fails the deployment if it errors. Paid plans only.
Health Check Path: The HTTP path Galaxy pings to verify your app is healthy. Must start with /. Defaults to /.
Container Stop Grace Period: Seconds Galaxy waits after SIGTERM before force-stopping. Defaults to 5, max 600. Paid plans only.
Danger Zone
Delete App: Permanently removes your app. All containers stop, all data is lost, and your domain is released. This can't be undone.
Networking
The Networking tab manages the addresses your app answers on and the outbound IPs it connects from.
Domains
Your primary domain is set at deploy time and follows the pattern myapp.<region>.galaxycloud.app (paid) or myapp.sandbox.galaxycloud.app (free). It's permanent and can't be deleted, but you can toggle it on or off.
You can also add one custom Galaxy subdomain or connect your own domain (app.yourcompany.com) on paid plans. Custom domains need a DNS record at your registrar (a CNAME for subdomains, an A record for root domains). Galaxy provisions and renews SSL automatically, or you can upload your own certificate. See the Custom Domains guide for DNS setup, and the Custom Certificates section for bringing your own.
The tab shows a table of every configured domain with its status, encryption state, and per-domain actions. From the actions column you can set a domain as primary, upload a custom TLS certificate, or delete it. Checking Use custom certificate when you add a domain does the same thing at creation time.
IP Whitelisting
Shows the outbound IPs your containers use for external connections. Add these to your database or external service allow lists. Available on the Professional plan for Meteor apps only.
Scaling
Autoscaling adjusts how many container replicas your app runs based on demand. Pick one of three modes.
Paid Plans Only
Autoscaling requires a paid plan. Free plans will see an upgrade prompt with all options disabled.
None
Autoscaling off. Manage replica count manually from the Containers page.
Basic
Set a minimum and maximum replica count (1 to 10). Galaxy scales automatically targeting 70% CPU utilization.
Drag the slider handles to set your range, then click Save Configuration when the unsaved changes bar appears. Click Discard to revert.
Advanced
Advanced mode replaces a single range with a list of named rules you control. Galaxy evaluates them on a schedule and adjusts your replica count to match. Reach for it when one CPU target isn't enough: different metrics, time-based scaling, or several conditions at once. Professional plan only.
App-wide settings
These apply to every rule:
Replicas: The floor and ceiling for your app. Drag the two slider handles to set your minimum and maximum, up to your plan's container limit. No rule scales you below the floor or above the ceiling.
Polling interval: How often Galaxy evaluates your metrics, in seconds. Defaults to 300. Lower it for faster reactions; raise it to smooth out noisy traffic. Accepts 10 to 3600.
Replicas per step: How many replicas Galaxy adds or removes at a time. Defaults to 1. Raise it to scale in larger jumps.
Scaling rules
A rule describes one scaling intent. Add up to 20, give each a clear name, and switch them on or off individually. Advanced mode needs at least one rule; if you don't want any, switch back to None.
Two ways to create one:
- Templates: Click Templates for a menu of ready-made rules (High CPU defense, Business hours boost, Off-hours baseline, Traffic surge, Memory pressure). Picking one fills the editor so you can adjust before saving. It doesn't save on its own.
- Add rule: Click Add rule to start from a blank editor.
Every rule is one of two types:
Scales when a metric crosses a threshold. Example: scale up when CPU goes above 70%.
Metric: Choose cpu, memory, requests, or connections. CPU and memory are percentages; requests and connections are counts.
Comparator and threshold: Set whether the metric should be above or below your number. A "below" condition only works as a gate alongside at least one "above" condition, so it can't drive scaling on its own.
Match all or any: Add more than one condition, then choose whether they all must be true (all) or just one (any).
Schedule (optional): Restrict the rule to specific days and hours. Leave it off to run around the clock.
Holds a minimum replica count during a time window, with no metric involved. Example: keep at least 3 replicas running on weekdays from 8:00 to 18:00.
Schedule: Pick the days and hours the baseline applies. Use the presets (Weekdays, Weekends, All) or set them by hand.
Baseline replicas: The floor to hold during the window. Outside the window the rule does nothing; inside it, Galaxy keeps at least this many replicas running.
Schedules display in your local time and are stored in UTC, so they fire at the right moment for everyone on your team.
As you edit a rule, Galaxy shows a plain-language summary of what it does, like "Scale up to 8 replicas when CPU is above 70% on weekdays 8:00 to 18:00." If two rules could conflict (same metric and overlapping schedule), you'll see a warning so you can review or remove the duplicate.
When everything looks right, click Save Configuration.
Logging
Ship logs to an external endpoint alongside Galaxy's built-in log viewer. Supported providers: Elasticsearch and HTTP (Datadog, Logstash, or any HTTP receiver). Paid plans only.
Configure in Settings > Logging: enable the toggle, pick a provider, enter the host and port, add credentials if needed, then click Save Configuration. Changes apply on your next deployment.
Set an Index Name (like app-logs) where Galaxy writes your logs.
Set a URI Path (like /v1/logs) appended to the host for log delivery.
To remove a destination, click Delete Configuration. Logs return to the built-in viewer only on the next deployment.
Meteor: Migrate from USER_LOG_DESTINATION
The settings.json method is legacy and will be deprecated. Switch to the dashboard configuration: no code changes required, and it works for both Meteor and Web Apps.
Security
Control which IPs can reach your app and how many requests they can make. Rules apply at the edge, before traffic reaches your containers, and take effect within a few moments.
Plan Requirements
The Deny List works on any paid plan. The Allow List and Custom DDoS require the Professional plan or higher. Custom DDoS is available for Meteor apps only.
Allow List
Restricts access to a set of approved IPs. Leave it empty and anyone can reach your app, except addresses on your Deny List. Add one entry and only those addresses get through.
Click +, then enter a single IP or a CIDR range (IPv4 or IPv6). Add an optional description to track what each entry is for. Use it for staging environments, internal tools, and admin panels that shouldn't be public.
Add Your Own IP First
The list takes effect the moment you add an entry. Every other IP is blocked immediately. Add your own address first and confirm you can still reach the app.
Deny List
Blocks specific IPs while everyone else connects normally. Click +, enter an IP or CIDR range, and add an optional reason. The block stays until you remove it.
An IP can live on one list at a time, never both. If a conflict would occur, the Deny List wins. Galaxy prevents you from adding the same address to both.
Custom DDoS
Caps how many requests a single source IP can make in a rolling 30-second window. Enable rate limiting, then set your threshold. The default is 500 requests per IP per 30 seconds. IPs that exceed it receive a 429 Too Many Requests response until their rate drops back down.
Currently Blocked IPs: A live table of every IP currently over the limit, with its request count and how long Galaxy has tracked it. Promote any row to your Allow List (to exempt it) or Deny List (to block it permanently).
Throttle, Not Ban
Rate limiting is temporary. An IP that slows down is served again as soon as its rate recovers. For a permanent block, use the Deny List.
Notifications
Get alerted when something happens to your app, through email, Slack, or webhooks. Each app supports up to 10 channels, and each channel routes the events you choose to one destination. Two channels can watch the same event, so a crash can page both your team Slack and an on-call webhook.
Channel Types
Enter the email address that receives alerts. The full address shows on the channel card.
Paste a Slack incoming webhook URL (starts with https://hooks.slack.com/services/). Optionally set a channel override like #deploys to route messages to a specific channel.
Enter an HTTPS endpoint. Galaxy signs each delivery with an HMAC secret so your receiver can verify it. The secret is generated when you create the channel.
Events
Pick which events trigger each channel. They're organized into seven groups: Deployments, Push-to-deploy, App lifecycle, Health and uptime, Scaling, Certificates, and Configuration changes. Sensible defaults are pre-selected, so you can leave them as-is.
Built-In Audit Trail
Every event in the Configuration changes group records who made the change. If a teammate edits your plan, resizes a container, or updates your allow list, you'll know exactly who did it.
Managing Channels
Add a channel: Click Add channel, pick a type, name it, set the destination, choose your events, then send a test to confirm delivery before saving.
Toggle active: Flip a channel off to pause it without losing its config. Flip it back on anytime.
Test, edit, or delete: Use the channel menu to send a test event, change events or destination, or remove it. Slack and webhook URLs are masked on the card since they're secrets; email addresses show in full.
Failing Channels Pause Automatically
If a channel fails to deliver repeatedly, Galaxy disables it and emails you once. Fix the destination, then turn it back on. Migrated apps keep their alerts through a backfilled default channel, no setup required.
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.