Prevent OOM Kills by Setting RAM in discloud.config Before Deploying a Bot

Why a bot starts and then disappears

You push a Node.js bot to Discloud. The CLI reports success, the process starts, and then—under a modest load—the instance vanishes. Logs show no graceful shutdown. What usually happened is that the bot exceeded the memory allowance tied to its plan, and the platform’s out-of-memory (OOM) killer terminated the process. An OOM killer is a Linux mechanism that stops a process when the system runs out of available RAM.

The useful takeaway is to treat discloud.config as a resource contract, not just a metadata file. Set the entry point, RAM ceiling, and version deliberately, then confirm actual usage in the dashboard before assuming the deployment is stable.

What discloud.config controls

discloud.config is a plain-text file in your project root that tells Discloud which file to run, how much memory to allow, and which version to deploy. The platform reads it during container initialization, the process of preparing a lightweight isolated environment for your app.

Field	Purpose	Example
MAIN	The entry point file executed by the runtime	index.js
RAM	Memory ceiling in megabytes for the instance	128
VERSION	Deployed release identifier	1.0.0

Incorrect MAIN paths cause immediate deployment failure. Setting RAM above your plan tier’s allowance does not grant more memory; it can still trigger an OOM kill once usage exceeds the actual limit.

Worked example: configure and deploy a Node.js bot

1. Create discloud.config in the project root:

MAIN=index.js
RAM=128
VERSION=1.0.0

1. Run the deploy command from the same directory where the config file lives. You need a Discloud account and the CLI installed.

discloud login
discloud deploy

Where to run: your local terminal. Required permissions: a Discloud account with deployment access. Placeholders: replace index.js with your actual entry file, and adjust 128 to match your plan’s RAM tier.

1. Check logs to confirm the main file executed:

discloud logs

Expected check: the log stream shows the bot starting without a stack trace or immediate exit. If you see a "file not found" or "module not found" error, the MAIN path is likely wrong.

1. Open the Discloud dashboard resource monitor and watch RAM usage during normal operation.

Practical check: steady usage should remain comfortably below the configured ceiling. If it approaches the limit, reduce memory load or confirm your plan tier supports a higher ceiling before increasing the RAM value.

Limitation: this is not a general-purpose VPS

Discloud is specialized for bots and small applications. You do not get full root access, and you cannot install arbitrary system packages or run long-lived non-bot workloads the way you could on a virtual private server. Automatic restarts help maintain uptime after crashes or maintenance, but they do not fix a memory leak or a misconfigured entry point.

Before you deploy

Set discloud.config fields to match your bot’s actual needs, deploy with the CLI, inspect logs for startup errors, and verify RAM usage in the dashboard. If the instance keeps dying, check whether memory—not code logic—is the constraint.

Note: field names and plan limits reflect the platform model in available research; confirm exact syntax and current allowances in Discloud’s documentation before deploying, as this draft has not been independently verified against the live platform.