Deploying a Bot to Discloud with discloud.config: Fields, Upload, and Verification

Discloud deployments fail most often for one boring reason: the discloud.config file is missing, malformed, or points at a main file that isn't where you said it was. The fix is understanding exactly which fields the platform reads, how it picks a runtime, and how to confirm the process actually started. This guide walks through a minimal working config, the upload flow, and the checks that tell you whether the deploy succeeded or silently crashed into a restart loop.

What discloud.config actually controls

Discloud is a hosting platform aimed at bots and small applications. Instead of a build pipeline you configure on the server, you ship a .zip archive of your project with a plain-text file named discloud.config at its root. The platform reads that file to decide what to run and how to label the app. Key fields:

• MAIN — the entry-point file, relative to the archive root (for example src/index.js or bot.py). The file extension determines the runtime: .js gets Node.js, .py gets Python, .jar gets Java.
• NAME — the display name of the application.
• VERSION — a version string for your own tracking.
• DESCRIPTION — short description shown in the dashboard.

Resource limits (RAM, CPU) are not set in this file. They come from your plan, and the platform enforces them at the process level. If your bot exceeds its RAM allocation, the OOM killer terminates it and Discloud restarts it — which looks like a crash loop if you're only watching logs casually.

Prerequisites

• A Discloud account with an application slot (free or paid plan).
• A project that runs locally with a single command (node src/index.js, python bot.py, etc.). If it doesn't start cleanly on your machine, it won't start on Discloud.
• Secrets (bot tokens, API keys) ready to paste into the dashboard's environment-variable section — not hardcoded in the config or source.

Write the config file

Create discloud.config in your project root:

MAIN=src/index.js
NAME=my-discord-bot
VERSION=1.0.0
DESCRIPTION=Moderation and utility bot

Three rules that prevent the most common failures:

1. The path in MAIN is relative to the zip root, and it is case-sensitive. Src/index.js and src/index.js are different files on the Linux host.
2. Zip the contents of your project, not the parent folder. If the archive unpacks to my-project/discloud.config instead of discloud.config at the top level, the platform won't find it.
3. Include your dependency manifest (package.json, requirements.txt) in the archive so the platform can install dependencies.

Upload and deploy

You have two routes:

• Dashboard: open your application, upload the .zip, and confirm the deploy. Suitable for manual releases.
• API/CLI: Discloud exposes a REST API for uploading archives and managing instances, authenticated with your account token. This is the better fit for CI — a pipeline step can zip the repo and POST it without anyone touching the dashboard. Check the current API documentation for the exact endpoint and header format, since these details change.

Either way, set your environment variables in the dashboard (or via the API) before or immediately after the first deploy. A bot that starts without its token will crash and trigger the automatic restart behavior, burning through restart cycles.

Verify the deployment

Don't assume success from the upload response. Open the console logs for the application and check for:

1. The platform reporting that it found and executed your MAIN file. If you see an error about a missing file, the path or zip structure is wrong — fix and re-upload.
2. Your application's own startup output (for example, a "logged in as" line from your bot library). This confirms dependencies installed and secrets loaded.
3. Stability over a few minutes. Repeated restarts with an out-of-memory signature mean you're exceeding your plan's RAM; either reduce footprint (fewer cached objects, smaller dependency tree) or upgrade the plan.

Recovery options

If a deploy goes wrong: re-upload a known-good archive to roll back — keep the previous working zip around for exactly this. If the app is stuck in a restart loop, stop it from the dashboard while you fix the config or code. For path problems, unzip your archive locally and confirm discloud.config and the MAIN file sit exactly where the config says they do.

One caveat: field names and supported options in discloud.config have evolved over time, so treat the four fields above as the reliable core and check Discloud's current docs before relying on anything more exotic.