Setting Discloud RAM Limits Without Guessing

The problem: your Discloud bot keeps restarting

You deploy a Node.js Discord bot to Discloud. It runs fine on your laptop, but on the platform it crashes after a few minutes. The dashboard shows rapid restart loops, and the logs mention memory exhaustion. You set RAM=64 in discloud.config because the bot seemed lightweight, but the platform still terminates it.

The useful takeaway: size RAM from measured local usage plus headroom, verify with platform logs, and treat the Discloud filesystem as ephemeral.

What discloud.config controls

discloud.config is the platform configuration file that tells Discloud how to boot your app. The MAIN key sets the entry file, and RAM sets the memory ceiling in megabytes. Discloud enforces that ceiling at the container level; if the process exceeds it, the platform's OOM killer stops the process and may trigger an automatic restart.

Measure memory before you pick a number

Do not guess the limit. Run a small check locally under a load similar to production. For Node.js, create memory-check.js:

const usage = process.memoryUsage();
console.log(`RSS: ${Math.round(usage.rss / 1024 / 1024)} MB`);
console.log(`Heap total: ${Math.round(usage.heapTotal / 1024 / 1024)} MB`);
console.log(`Heap used: ${Math.round(usage.heapUsed / 1024 / 1024)} MB`);

Where to run: your local terminal. Permissions: none beyond normal file execution. Expected check: the script prints the resident set size (RSS) in megabytes. Risk: local RSS does not include Discloud's container overhead or runtime baseline, so add 25–50% headroom to the number you see.

If your bot reports roughly 80 MB RSS locally, a starting platform value of 128 MB is reasonable. Create discloud.config in the project root:

MAIN=index.js
RAM=128

Where to run: local shell. Example command:

cat > discloud.config <<'EOF'
MAIN=index.js
RAM=128
EOF

Permissions: write access to the project folder. Expected check: the file exists with those two lines. Risk: a typo or unsupported value can prevent boot or cause immediate termination.

Deploy and verify with logs

Upload the project using your usual Discloud deployment method (CLI or dashboard upload), then open the application logs in the Discloud dashboard. A successful boot shows the app starting and staying up. A restart loop with memory errors means RAM is too low.

A practical diagnostic decision: temporarily raise RAM to 256 MB and redeploy. If the restarts stop, the original limit was the cause. Lower it in small increments while watching logs until you find the smallest stable value.

Limitation: the filesystem is ephemeral

Discloud's instance filesystem may not survive redeploys or restarts. Do not rely on local disk for SQLite databases, user uploads, cached files, or session state. Store persistent data in an external database or object storage service instead.

Practical check: have your app write a marker file during startup, redeploy, and check whether the file persists. If it disappears, treat the disk as temporary.

Trade-off: headroom versus plan quota

Setting RAM too high avoids OOM kills but consumes more of your plan's memory quota and may increase cost. Setting it too low guarantees termination under load. The goal is the lowest stable limit with enough headroom for traffic spikes.

Closing checklist

• Profile your app's RSS locally under realistic load.
• Set RAM in discloud.config with 25–50% headroom.
• Deploy and inspect Discloud logs for OOM kills or restart loops.
• Move persistent data off the instance to an external service.
• Recheck memory limits after dependency updates or code changes.

Platform behavior can change, so verify the current Discloud dashboard and plan documentation before applying this to production.