Container Environment

Galaxy runs your app inside Docker containers on 64-bit Linux machines in the UTC timezone. Most apps deploy without any special configuration. This page covers what Galaxy injects automatically and how the runtime environment behaves.

Environment Variables

Galaxy sets several environment variables before your container starts. Some you'll use directly; others work behind the scenes.

Variables You'll Use

Variables Galaxy Manages

What You Can Override

You can add your own variables or override most Galaxy-set variables through your settings.json or the Galaxy dashboard.

Cannot override: GALAXY_CONTAINER_ID, KADIRA_OPTIONS_HOSTNAME, and GALAXY_LOGGER. These are container-specific and locked.

The PORT Variable

Galaxy assigns ports dynamically and tells your app which one to use via PORT. Your app must read this variable and listen on it. Don't hardcode port 3000, 5000, or any other number.

If your app doesn't listen on $PORT, Galaxy can't route traffic to it. Health checks fail and the container gets marked unhealthy.

Graceful Shutdown

When Galaxy stops your container (new deploy, scale-down, maintenance), it sends SIGTERM first. Your app gets a grace period to finish open requests and close connections before Galaxy sends SIGKILL.

The default grace period is 5 seconds. You can increase it up to 600 seconds in your app's Settings > General tab. Galaxy also exposes the configured value as METEOR_SIGTERM_GRACE_PERIOD_SECONDS so your code can read it at runtime.

Here's a minimal Node.js handler:

process.on('SIGTERM', () => {
  server.close(() => {
    process.exit(0);
  });

  // Force exit before SIGKILL arrives
  setTimeout(() => process.exit(1), 25000);
});

Close your database connections and stop accepting new requests during this window. Any work you can't finish should be queued for the next container to pick up.

Health Checking

Galaxy makes HTTP requests to verify your container is alive. Your app must:

• Listen on $PORT
• Respond to GET / within 5 seconds
• Return valid HTTP (not a 5xx)

Health check requests include a User-Agent header containing Galaxybot/.

What happens when a container fails health checks:

• New containers get 10 minutes to become healthy before Galaxy replaces them
• Previously healthy containers get 5 minutes to recover
• Unhealthy containers stop receiving new connections
• If new containers never become healthy, Galaxy rolls back to the previous version automatically

You can disable automatic replacement in your app's Settings page. That's useful if your app runs heavy startup processes that temporarily block responses.

Network Environment

Incoming Connections

Galaxy exposes exactly one port per container: the one assigned via $PORT. HTTP (port 80) and HTTPS (port 443) both route through Galaxy's load balancer to your container. You can't serve on any other ports.

Client IP Addresses

All traffic arrives through Galaxy's load balancer, so your app sees the proxy's address (something like 10.42.x.x) instead of the real client IP. To get the real address, set HTTP_FORWARDED_COUNT in the galaxy.meteor.com.env section of your settings.json.

Use HTTP_FORWARDED_COUNT=1 for Galaxy alone. Add one for each additional proxy in front (Cloudflare, Fastly, etc.).

Galaxy also forwards the X-Forwarded-For header. The leftmost value is the original client; the rightmost is the proxy closest to your app.

Outgoing Connections and IP Whitelisting

When your app connects to external services, those requests come from Galaxy's fixed outgoing proxy IPs. If you're using MongoDB Atlas, AWS RDS, or any service that requires IP whitelisting, you'll need these addresses.

Find them in your app's Settings page under outgoing connections. If your service requires CIDR format, append /32 to each IP (for example, 203.0.113.42/32).

Load Balancing

Galaxy routes new connections to the container with the fewest existing connections. Existing connections stay on their current container. If a container becomes unhealthy, its users are routed to healthy ones.

High CPU or memory alone doesn't trigger rebalancing. Only an unhealthy status (failing health checks) moves users off a container.

Memory Management

Node.js (v12+) is container-aware and automatically caps the heap at about 50% of your container's memory limit, up to 2 GB. For most apps this requires no configuration.

If you're hitting out-of-memory crashes or need a different heap size, use GALAXY_NODE_OPTIONS (Meteor) or NODE_OPTIONS (Web Apps) to tune it. See the Memory Management guide for per-container-size recommendations.

IPv6

IPv6 is automatically enabled for all paid plans. Free plans have IPv4 only. To activate IPv6, upgrade your plan and configure DNS at your domain registrar.

Troubleshooting

What's Next?