Containers

Understand container status, monitor resources, and scale your app to handle growth.

Ever wonder what's actually running when your app handles traffic? Each container is a separate instance of your application working independently.

This guide shows you how to monitor containers, understand what the metrics mean, and scale when traffic grows.

You're in Control

Galaxy shows you exactly what's happening with your app in real-time. No guesswork. Just data.

Understanding Containers

A container is a running copy of your app. Small apps might have one. High-traffic apps might have several running in parallel, with Galaxy distributing traffic across them all.

Think of containers like individual servers. Each one runs your code independently. If you have three containers running, Galaxy is essentially running your app three times at once, spreading user traffic across all three.

The Containers Card

At the top of the page, the Containers card shows your current configuration and lets you adjust your replica count directly.

Three fields appear inline:

Container: The container preset name. This identifies the size tier your app is running on.

Size: The resource allocation for each container, shown as memory and CPU.

Plan: Your current plan tier.

Adjusting Replica Count

On the right side of the Containers card, you'll see a number with ∨ and ∧ controls. This is your replica count: how many container instances are running. Click the arrows to increase or decrease the number directly from this page.

Free and Sandbox Plan Limitation

Apps on the Free plan (Meteor) or Sandbox plan (Web Apps) are limited to a single container and cannot be scaled. To add more containers or change container size, upgrade your plan from the Plans page.

Container Status

Each container displays its current status. Watch these statuses change when you deploy or scale your app.

🟡 Pending: Container is queued to start but hasn't launched yet.

🔵 Creating: Container is starting up for the first time or after a scale event.

🟢 Running: Container is healthy and handling requests.

🟠 Terminating: Container is being shut down (usually during a scale-down or deployment).

⚪ Stopped: Container is stopped or suspended.

🟡 Waiting: Container is in a generic waiting state.

🔴 Failed: Container encountered an error state (CrashLoop, ImagePull, etc.).

🟣 Succeeded: Container finished its task (usually for one-time jobs).

When you deploy new code or adjust container count, you'll watch these statuses change in real-time. Creating containers take a moment to spin up. Terminating containers shut down gracefully without dropping traffic.

Performance

Below the Containers card, the Performance section shows resource usage charts. Two badges at the top display your configured limits: CPU LIMIT and MEMORY LIMIT (e.g., CPU LIMIT: 500M, MEMORY LIMIT: 512 MB).

Two filters let you narrow down the data:

Filter by Container: Select a specific container instance to view its metrics individually. Useful when you have multiple replicas and want to compare their resource usage.

Filter by Time: Change the time window for the charts. Defaults to 1 hour.

If your app hasn't received traffic recently or was just started, you'll see "No metrics data available yet" until data begins populating.

Watch container metrics when you're testing under load. You'll understand how your app behaves when traffic increases.

What Containers Tell You

The Containers page is most useful when something's not quite right. Here's what to look for.

All containers running smoothly? Everything's fine. Your app is healthy.

One container stuck in "Creating" state? Give it a moment. It takes a few seconds to spin up. If it never finishes, check Logs to see what's blocking startup.

Replica count not matching your target? You might be in the middle of a scale event or deployment. Wait a moment and check again. If it doesn't correct itself, there might be an issue preventing containers from starting.

Uneven resource usage across containers? This is normal for stateless apps. Traffic distribution depends on many factors. If usage is drastically different, it might indicate a slow container that needs investigation.

Troubleshooting

Containers Keep Restarting?

Check Logs. Repeated restarts usually mean your app is crashing, and the logs will tell you why.

High CPU or memory usage? This might indicate an inefficient query, memory leak, or a need to scale up to larger containers. Check your app code and consider upgrading container size from Plans.

One container consistently using more resources? Sometimes individual containers get into a bad state. Try restarting your app from the Overview page. This usually clears up transient issues.

Container Count: Single vs Multiple

Most apps start with one container. But you have options.

Single container: Simple, cheaper. Fine for low to moderate traffic. If that one container crashes, your app goes down until it restarts.

Multiple containers: More resilient. Galaxy distributes traffic across all containers. If one crashes, others keep handling requests. Better performance under load.

For production apps, at least two containers is recommended. For mission-critical apps, three or more is better. This gives you redundancy and better performance.

High-Availability

If you're running a Standard (1GB) container or larger with three or more containers, high-availability is automatically enabled. This distributes your containers across different availability zones.

See the Overview page for more details on high-availability.

Changing Your Plan or Container Size

The Containers page lets you adjust replica count directly. To change container size or plan tier, head to Plans.

Open your app and navigate to Plans
Select your new plan (if changing tiers)
Pick your new container size
Click Apply

Galaxy applies the change and triggers your next deployment. Your app doesn't go down. The change takes effect when your app restarts.

Scaling is Non-Disruptive

Changing container count doesn't require downtime. Galaxy adds or removes containers gracefully while your app keeps serving traffic.

Downscaling to Save Money

Running more containers than you need? Or paying for bigger containers than necessary?

Downscaling replica count is quick: use the ∧ and ∨ controls on the Containers card. To downsize container size, go to Plans.

For temporary cost savings, you can also Stop your app from the Overview page. Stopped apps don't cost anything, but users can't access them until you restart.

Different Plans for Different App Types

Different app types (Meteor, Node.js, Python, AdonisJS) have different plan names and container options. The concept is the same: pick a tier, choose a size. But specific options vary by runtime.

Check our billing documentation for details specific to what you're running.

Quick Reference

Containers are instances: Each one runs your app independently.

Adjust replicas here: Use the ∨ and ∧ controls on the Containers card.

Monitor performance: The Performance section shows CPU and memory usage per container.

Change size from Plans: Container size and plan tier changes happen in the Plans page, not here.

High-availability: Automatically enabled with 3+ Standard containers.

Scaling is non-disruptive: Your app keeps serving traffic during changes.

Free and Sandbox plans are single-container only: Upgrade to scale beyond one container.