Choosing the Right RAM Limit for Your Discord Bot on Discloud

Why your Discord bot keeps crashing on Discloud

When a Discord bot deployed on Discloud exceeds its memory allocation, the platform’s OOM killer terminates the process. The dashboard then shows a rapid restart loop that looks like a crash, even though the code is healthy. This behavior wastes quota, creates noisy logs, and can hide real bugs.

Understanding the RAM contract

Discloud runs each app in an isolated container with a hard RAM ceiling defined in discloud.config. The limit is not a reservation; if the process tries to use more memory, the kernel OOM killer steps in and the container is restarted automatically. For Node.js bots the default V8 heap can grow beyond the container limit, so you must cap the heap explicitly.

Configuring discloud.config and Node heap

The deployment contract is a JSON file at the repository root. Key fields relevant to memory are:

• MAIN – the start command (e.g., node --max-old-space-size=512 bot.js)
• RAM – megabytes allocated to the container (e.g., 1024 for 1 GB)
• ENV – secret variables such as BOT_TOKEN or database URLs

Choose a RAM value that gives your bot headroom above its observed peak usage, then set --max-old-space-size to a value slightly below that limit (e.g., 80 % of the RAM). This prevents the V8 heap from triggering the OOM killer.

Worked example: setting limits and checking persistence

1. Fork or clone your bot repository.
2. Create discloud.config:

   {
     "MAIN": "node --max-old-space-size=768 bot.js",
     "RAM": 1024,
     "ENV": {
       "BOT_TOKEN": "",
       "DATABASE_URL": ""
     }
   }
   
   

3. Commit the file and push to the branch linked to Discloud (or prepare a ZIP).
4. Deploy via the Discloud CLI (you need an API token with apps:write scope):

   discloud deploy --app  --token  --zip ./release.zip
   
   

5. After deployment, open the app’s dashboard and watch the RAM graph. Verify that the peak stays well below the 1024 MB line.
6. Check the logs for lines like Max Old Space size: 768 MB to confirm the V8 flag was honored.
7. To test persistence, add a startup step that writes a marker file:

   # add to your start script before launching the bot
   mkdir -p /data && echo "$(date +%s)" > /data/marker.txt
   
   Then redeploy and, after the restart, use the dashboard’s file browser or the API to confirm /data/marker.txt still exists and contains the old timestamp. If the file is missing, treat the path as non‑persistent and move state to an external store.

Trade‑offs and limitations

• No root access – you cannot install system packages or tweak kernel parameters; all dependencies must be bundled in the container image.
• Secret visibility – ENV values are readable by anyone with dashboard or API‑token access to the app, so treat the token as equivalent to production credentials.
• Provider risk – Discloud is a smaller, Brazil‑based host; review its status page and support SLAs before relying on it for critical bots.
• Plan changes – RAM sizes and pricing evolve; always verify the current values in the official documentation before fixing a number in discloud.config.

Next steps

1. Measure your bot’s peak memory usage locally (e.g., node --inspect bot.js or pm2) and add a 20‑25 % safety margin. 2. Update discloud.config with the chosen RAM and V8 heap limit. 3. Deploy via CI using the Discloud API, storing the API token in your CI secret store (never in the repo). 4. After each deploy, check the dashboard RAM graph and the marker‑file persistence test to confirm both memory safety and durability expectations. 5. If you observe frequent OOM events despite the limit, consider moving heavy workloads (e.g., media processing) to an external service or upgrading the plan.

By aligning the container’s RAM ceiling with the Node heap limit and verifying persistence explicitly, you turn Discloud’s automatic‑restart behavior from a source of noise into a reliable safety net.