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

You can add your own variables through your settings.json or the Galaxy dashboard.

The PORT Variable

Galaxy sets PORT to 3000 when you do not configure a value. 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), Kubernetes begins the pod termination process. It runs the container's pre-stop hook, then sends SIGTERM to your app. Any process still running when the configured termination period ends is force-stopped with SIGKILL.

The default termination period is 5 seconds. You can increase it up to 600 seconds in your app's Settings > General tab, using Container Stop Grace Period (seconds). Changes apply on the next deployment.

The setting controls the total Kubernetes termination period. Galaxy exposes its configured value in your container through two aliases: SIGTERM_GRACE_PERIOD_SECONDS and METEOR_SIGTERM_GRACE_PERIOD_SECONDS. Both aliases have the same value.

Environment variables are strings. Parse either alias as an integer number of seconds in your shutdown handler when you need to budget application work for the configured shutdown window.

Here's a minimal Node.js handler:

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

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

Health Checking

Galaxy configures Kubernetes probes to verify that your container is healthy. Your app must:

• Listen on $PORT
• Respond to the configured health check path (the default is GET /) within the configured probe timeout
• Return a response considered healthy by the container image: 200 through 499 for standard images, or 200 through 399 for the Elixir/Phoenix image

The default probe timeout is 15 seconds. You can set it from 1 to 30 seconds in your app's Settings page.

What happens when a container fails health checks:

• New containers have approximately 7.5 minutes to pass the default startup probe
• A container that fails its readiness probe stops receiving traffic
• A container that fails its liveness probe is restarted
• A failed deployment is handled by the deployment workflow before traffic is switched to the new deployment

The current platform does not expose a setting to disable automatic replacement.

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 traffic to healthy containers through its load balancer and Kubernetes Service. For Meteor apps, Galaxy uses cookie persistence so reconnecting clients can be routed to the same pod.

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

For troubleshooting, you can open your app on a specific container. Galaxy uses a browser cookie to keep page reloads, navigation, and new WebSocket connections on that instance, with fallback to another available container if the selected one becomes unavailable.

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 NODE_OPTIONS to tune it. Meteor apps set it in the galaxy.meteor.com.env section of settings.json; Web Apps set it in the dashboard. 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?