App crashed out of memory (exit code 137)

Each environment on DployHub runs with a hard memory limit equal to the RAM you chose. If your process goes over it, the process is killed immediately and you see "out of memory" or exit code 137. This guide shows how to confirm the problem and then either give the app more room or make it use less.

Symptoms

• A deploy fails with "Your app stopped right after starting (exit code 137)…".
• The app restarts or goes down under load and you receive an "App is down" alert.
• Runtime logs stop abruptly, with no stack trace, right before a restart.
• Node.js prints "JavaScript heap out of memory" before dying.

Confirm it in the Metrics tab

Open the app's Metrics tab and look at the memory chart (MB) for the last 24 hours, or widen the range up to 90 days. If memory climbs to your limit and then drops sharply, the process was killed for using too much. A steady climb over hours points to a leak; a spike during certain requests points to one heavy operation, such as loading a large file into memory.

Fix 1: give the app more memory

1. 1

   Open Settings → Resources

   Memory options for live are 256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB and 16 GB.

2. 2

   Pick the next size up

   The new monthly price is shown before you save. RAM costs ₹150 per GB per month, billed by the hour.

3. 3

   Save

   Live restarts quickly on the current version. No rebuild is needed.

See resources for all sizes and how billing works for pricing.

Fix 2: tell Node.js about the limit

Node.js does not size its heap from the container limit, so it can grow past it and get killed instead of collecting garbage earlier. Set NODE_OPTIONS in the environment variables tab to roughly 75% of your memory, leaving room for buffers and native code:

# 512 MB plan
NODE_OPTIONS=--max-old-space-size=384

# 1 GB plan
NODE_OPTIONS=--max-old-space-size=768

# 2 GB plan
NODE_OPTIONS=--max-old-space-size=1536

Environment variable changes apply on the next deploy or restart, so restart the environment after saving.

Fix 3: use less memory

• Python with gunicorn: every worker is a full copy of your app. Lower the count in your start command, for example gunicorn app:app --bind 0.0.0.0:8000 --workers 2.
• Stream large files and uploads instead of reading them fully into memory.
• Cap in-memory caches, or move them to a dedicated cache service.
• Paginate database queries that can return thousands of rows.
• Avoid running a build or bundler inside your start command; build once during the build step.

Get warned next time

Turn on the "App is down" and "Deploy failed" events in alerts so you hear about crashes by email, Telegram or WhatsApp. If memory still looks wrong after these changes, raise a ticket with the app attached.