Right‑sizing a Discord bot on Discloud: RAM, heap flags, and version pins

Why RAM matters on Discloud

Discloud treats the discloud.config file as a declarative contract for each uploaded app. One of the fields, RAM, is a hard quota enforced by the platform: if the process tries to allocate more memory than the value you set, Discloud kills the container and, when AUTORESTART is true, immediately relaunches it. For a long‑running Node.js Discord bot this can turn into a restart loop that looks like normal operation until you check the restart count.

Setting a realistic RAM quota

Start by measuring your bot’s baseline memory usage. Deploy a minimal version that logs process.memoryUsage() every minute and watch the Discloud dashboard’s memory graph. Suppose the graph shows a steady 120 MiB with occasional spikes to 180 MiB during voice‑state updates. Choose a quota that comfortably covers the peak but leaves headroom for the OS and the Discloud agent – e.g., 256 MiB.

{
  "MAIN": "index.js",
  "RAM": 256,
  "VERSION": "node-18",
  "AUTORESTART": true,
  "NAME": "my-discord-bot",
  "DESCRIPTION": "A small utility bot",
  "env": {
    "TOKEN": "{{DISCORD_TOKEN}}"
  }
}

Note: the env block shown here uses a placeholder. In practice you would replace the value with a reference to a secret stored in the Discloud dashboard, not a literal token, to avoid committing credentials.

Preventing silent OOM kills with Node heap flags

Node’s V8 engine bases its default heap size on the total memory it sees, not on the container’s quota. On a 256 MiB limit, V8 may keep allocating until Discloud’s OOM killer intervenes, resulting in a hard kill that gives you no chance to log or clean up. By explicitly limiting the heap you make Node throw a catchable RangeError when it approaches the limit.

Add the flag through the NODE_OPTIONS environment variable. Because discloud.config is part of the deployed artifact, you can set it alongside other vars:

{
  "MAIN": "index.js",
  "RAM": 256,
  "VERSION": "node-18",
  "AUTORESTART": true,
  "NAME": "my-discord-bot",
  "DESCRIPTION": "A small utility bot",
  "env": {
    "TOKEN": "{{DISCORD_TOKEN}}",
    "NODE_OPTIONS": "--max-old-space-size=180"
  }
}

Here the heap is capped at ~180 MiB, leaving ~70 MiB for the OS, the Discloud agent, and any native modules. When the heap limit is reached Node will emit a RangeError that you can handle (e.g., shut down gracefully or alert an operator).

Pinning the runtime version

The VERSION field selects the Docker image Discloud uses to run your app. Leaving it as "latest" (or omitting it) means the platform may switch you to a newer Node release without notice, which can break native dependencies or change default flags. Pinning a specific major version, such as "node-18", gives you predictable behavior. The trade‑off is that you must manually update the pin when you want to move to a newer LTS release.

Managing secrets safely

Because discloud.config travels with your code, any plaintext values placed in the env block become part of the repository history if you deploy via Git. Treat the file as source code: store only non‑secret configuration there, and keep tokens, API keys, or database passwords in Discloud’s dashboard‑managed environment variables. If you ever accidentally commit a secret, rotate it immediately and consider using a tool like git filter-repo to rewrite history.

Using commit history for rollback

Every upload – whether a ZIP file or a Git push – creates a versioned commit in the app’s history. You can view the list in the dashboard and restore any previous commit, which rolls back both code and discloud.config. This gives you a quick way to revert a mis‑sized RAM value or a broken version pin without rebuilding your own release pipeline. Remember that rollback does not affect external state such as a PostgreSQL database or Discord application settings; those must be managed separately.

Actionable checklist

1. Deploy a baseline bot that reports memory usage and observe the dashboard graph.
2. Set RAM to a value that covers the observed peak plus a safety margin (e.g., 256 MiB).
3. Add NODE_OPTIONS=--max-old-space-size=<heap‑limit> with a heap limit comfortably below the RAM quota.
4. Pin VERSION to a specific Node major (e.g., "node-18") to avoid surprise updates.
5. Keep secrets out of discloud.config; manage them via the dashboard’s env‑var UI.
6. Monitor restart frequency; a high count indicates the quota is still too low or a leak exists.
7. Use the commit history to roll back if a change causes instability.

Limitations to keep in mind

The RAM quota is a hard limit; if your bot legitimately needs more memory during a burst (e.g., large file uploads), you must increase the quota and possibly upgrade your plan. The heap flag only affects Node processes; any native add‑ons or child processes you spawn will still draw from the overall container limit. Finally, Discloud’s documentation and dashboard are primarily in Brazilian Portuguese, so allow extra time to verify field names and limits when working from the English‑language UI.