Hosting a Discord Bot on Discloud: What the Config File and CLI Actually Do

You've written a Discord bot, it runs fine on your laptop, and now you need it online when your laptop is closed. Discloud is one of the platforms built specifically for this: it hosts bots and small web apps, with a config-driven deployment model and a CLI for pushing code. This post walks through the two pieces you'll touch most — the discloud.config file and the CLI upload flow — and where the platform's limits will bite you.

The config file is the contract

Discloud doesn't guess how to run your app. Every deployment is driven by a discloud.config file in your project root, and the platform is strict about it: a malformed file fails the deployment, not with a warning but with a rejection. The core fields declare your application's identity, entry point, and type. A typical Node.js bot looks like this:

# discloud.config
NAME=my-moderation-bot
TYPE=bot
MAIN=src/index.js
RAM=100
VERSION=latest
AUTORESTART=true

A few of these deserve explanation. MAIN is the entry point Discloud executes — get the path wrong relative to the uploaded archive and the app crashes immediately. RAM requests memory in megabytes and is capped by your plan tier; asking for more than your plan allows is a common cause of failed uploads. AUTORESTART=true tells the platform to bring the process back after a crash, which matters for long-lived bot connections that occasionally drop. TYPE=bot versus TYPE=site changes how the app is treated — sites get a subdomain and HTTP exposure, bots are expected to be outbound-only processes.

One practical note: treat this file like code. Commit it, review changes to it, and don't edit it live on the dashboard without mirroring the change locally, or your next CLI upload will silently overwrite your dashboard edits.

Deploying with the CLI

The Discloud CLI is distributed as an npm package, so you'll need Node.js installed locally. Install it globally, authenticate with your API token (generated from your Discloud account settings), and upload from your project directory:

npm install -g discloud-cli
discloud login
discloud upload

Run these from a terminal in the folder containing your discloud.config. The upload command zips your project, sends it, and the platform builds and starts the app. Two things to check before uploading: first, that your .discloudignore (or equivalent ignore rules) excludes node_modules and any .env files — uploading secrets into a hosted archive is an avoidable mistake, and Discloud provides environment variable configuration in the dashboard instead. Second, that your package.json lists all dependencies, since the platform installs from it rather than from your local modules.

After upload, verify the deployment actually worked rather than assuming it did. Open the dashboard console and watch the startup logs: you want to see your dependency install complete and your bot's own "logged in as …" line (or equivalent). If the app crash-loops, the console is where the stack trace appears — usually a missing env var, a wrong MAIN path, or an out-of-memory kill.

A worked example: keeping a slash-command bot alive

Say you have a discord.js v14 bot that registers slash commands on startup and holds a WebSocket connection to the gateway. The failure mode you care about isn't the code — it's the connection dropping at 3 a.m. and the process exiting. The Discloud-side answer is AUTORESTART=true plus making your startup idempotent: command registration should be safe to run repeatedly, and any in-memory state (queues, cooldown caches) should be treated as disposable. If you need state to survive restarts, put it in an external store — a small Redis instance or a database — because local disk on a hosted bot tier is not a persistence guarantee.

To test the restart behavior deliberately, you can trigger a restart from the dashboard or CLI (discloud restart) and confirm in the console that the bot comes back and re-registers cleanly. Do this once before you rely on it.

The trade-off: convenience versus headroom

Discloud's model is genuinely convenient for small bots, but the resource tiers are hard limits, not suggestions. RAM is enforced per app, and if your process exceeds its allocation it gets killed — which looks exactly like a random crash unless you check the console. Memory-hungry workloads (large caches, image processing, many concurrent guilds in one process) will hit the ceiling fast on lower tiers. Disk space is similarly constrained, so apps that write logs or temp files to disk need rotation or they'll fill their quota.

The other limitation is persistence expectations: uptime behavior varies by plan, and free or lower tiers may not guarantee the same availability as paid ones. Check the current plan terms on Discloud's site before promising anyone that your bot is "always on" — plan details change, and this is worth verifying at the time you deploy rather than trusting any article, including this one.

Where to start

If you want to evaluate the platform, the fastest honest test is: take an existing small bot, write a minimal discloud.config, deploy via the CLI, then do three checks — the console shows a clean startup, a manual restart recovers without intervention, and memory usage in the dashboard sits comfortably below your tier's cap under normal load. If all three pass, the platform fits your workload. If memory is tight, that's your signal to either trim the app or budget for a higher tier before you're debugging 3 a.m. restarts.