Discloud's discloud.config: Declaring Runtime, Memory, and Restarts

What discloud.config actually decides

Discloud is a hosting platform aimed at Discord bots and small long-running apps. Rather than selecting a runtime through a dashboard wizard, you describe the deployment in a plain-text key=value file named discloud.config, placed at the root of the project. The platform reads it at deploy time and uses it to configure what runs. Because it is part of your source, it must be committed and included in the zip you upload.

Four decisions matter most:

• What kind of thing this is — a bot, a site, or another supported type.
• Which file starts it — the entry point the platform executes.
• How much memory it gets — declared in megabytes.
• What happens when it dies — whether the platform restarts it automatically.

Everything else in the file is secondary to those four. Get them wrong and the symptom is usually "the app deployed but is not running", which is harder to debug than a build error.

A worked configuration

The example below is a Node.js Discord bot. It illustrates the shape of a config rather than an authoritative field list — key names, accepted values and minimum RAM have changed over time, so check the current Discloud documentation before relying on any specific line.

NAME=my-discord-bot
TYPE=bot
MAIN=index.js
RAM=256
VERSION=latest
AUTORESTART=true

Read line by line:

• NAME identifies the app in the dashboard and CLI. It is not the bot's Discord username.
• TYPE tells the platform which runtime family and lifecycle to apply. A bot is expected to stay connected; a site is expected to answer requests.
• MAIN is the file the platform runs. For Node that is typically index.js; for Python, main.py or bot.py. It must be the file that starts the long-running process, not a wrapper that imports something and exits.
• RAM is the memory ceiling in MB. 256 is a reasonable starting point for a small bot; the allowed minimum is lower, but a value near the floor leaves little headroom for a library such as discord.js plus its cache.
• VERSION (sometimes expressed as a language or runtime field) selects the runtime version. Pin it to something you have actually run locally rather than chasing "latest" blindly.
• AUTORESTART asks the platform to bring the process back after it exits.

For Python the same structure applies with MAIN=main.py, and you additionally need a requirements.txt so the platform can install dependencies. For Node, ship a package.json whose entry point agrees with MAIN; a mismatch between the two is a silent source of "started then stopped".

How the file reaches the platform

The config only takes effect through a deploy. The common paths are:

1. Zip the project so that discloud.config sits at the zip root, next to your source folder or entry file — not nested one level down inside a wrapper directory.
2. Upload the zip through the dashboard, the CLI, or the platform's Discord bot.
3. For scripted or CI deploys, authenticate with an API token. Keep the token in the CI secret store or an environment variable; never commit it, and never put it in discloud.config.

If you use the CLI, run it from the project root so it picks up the config without extra path arguments. The account you authenticate with needs permission to manage the target app; on a shared account that usually means the app owner or an account with deploy rights.

Choosing RAM deliberately

The single most useful engineering decision here is to set RAM on purpose. Discloud allocates according to the declared value, and plan limits are commonly expressed in terms of it, so an accidental default has two costs: you may reserve headroom you never use, or you may hit an out-of-memory kill that presents as a random crash.

An OOM kill is easy to misread. The process stops with no application-level stack trace, often minutes or hours after a successful start, frequently while handling a burst of events. A startup bug looks different: the process dies immediately, every time, and the logs show your own exception.

Rough starting points, to be adjusted from observed usage rather than treated as rules: a small command-only bot with one or two libraries fits comfortably in 256 MB; a bot with a database client, image processing or a large cache may need 512 MB or more. Raise the value and redeploy rather than guessing downward.

Autorestart: useful, and easy to abuse

Automatic restart suits long-lived gateway connections, where a transient network failure or an unhandled promise rejection would otherwise leave the bot offline until you notice. The trade-off is that it also hides crash loops. A bot that throws on every startup will be restarted repeatedly, and depending on your plan that can consume restart allowances while producing nothing but noise in the logs.

Treat autorestart as a safety net, not a fix. If you see repeated restarts, the correct response is to read the logs and fix the cause, not to assume the platform is flaky.

Diagnosing the common failures

Symptom	Likely cause	What to check
Deploy fails, or the app never appears as running	Missing or misnamed config, or a MAIN that does not exist	Confirm the file is at the zip root and that MAIN matches the real entry filename exactly, including case
Process starts, then dies later under load	Declared RAM too low	Compare declared RAM with observed usage; raise it and redeploy
Process dies immediately, every time	Startup exception or missing dependency	Run the entry file locally with the same runtime; check package.json or requirements.txt
Bot shows online but ignores commands	Wrong entry file, or a wrapper that exits after registering	Make sure MAIN is the file that keeps the client running

Limits and how to check your result

Two limits are worth stating plainly. First, the config does not guarantee uptime: free-tier apps are commonly stopped after inactivity or require periodic renewal, so a correct discloud.config is necessary but not sufficient for 24/7 operation. Second, secrets do not belong in the file — bot tokens and API keys go in environment variables or the platform's environment mechanism, because the config is committed to your repository.

A short verification sequence, run against a throwaway app rather than production:

1. Create a minimal project with a config containing only the fields you need, zip it with the config at the root, and deploy.
2. Confirm the app appears in the status panel and that logs show your own startup message.
3. Deliberately throw an exception at startup and observe whether the restart behavior matches what you configured, and whether the logs show a repeating loop.
4. Check the current official Discloud documentation for the authoritative key list and minimum RAM before finalizing anything you intend to keep.

If a deploy goes wrong, the practical rollback is to stop the app and redeploy the previous zip, which restores the earlier config and code together. Because the config travels with the source, keeping the last known-good zip is the simplest recovery path.