Deploying Discord Bots on Discloud with Docker: From Dockerfile to Runtime Limits

Why Docker on Discloud Matters

Discloud’s Docker‑based deployment lets you bundle your bot’s runtime, libraries, and configuration into a single image. This guarantees that the container you run on the platform behaves the same as your local test environment, eliminating “works on my machine” surprises.

For Discord bots, the most common use case is a Node.js script that listens for events on a WebSocket. By shipping the bot inside Docker, you avoid platform‑specific installation steps and can version the runtime with the image.

Quick Start: Building a Minimal Bot Image

Below is a minimal example that assumes you have a bot.js file that connects to Discord using the discord.js library.

# Use a lightweight Node runtime
FROM node:18-slim

# Create working directory inside the image
WORKDIR /app

# Copy package files and install dependencies
COPY package*.json ./
RUN npm ci --only=production

# Copy the bot source
COPY . .

# Expose the port that the bot will listen on (Discord bots usually use 3000 for HTTP endpoints)
EXPOSE 3000

# Start the bot
CMD ["node", "bot.js"]

Key points:

• Base image – node:18-slim is small and includes only the Node runtime.
• Dependency install – npm ci --only=production creates a reproducible layer that does not include dev tools.
• Port exposure – EXPOSE 3000 is required so Discloud can route traffic. If your bot listens on a different port, replace it accordingly.
• CMD – the command that starts the bot; adjust if you use a different entry point.

Setting Environment Variables

Discloud injects environment variables at runtime, keeping secrets out of the image. In the dashboard, navigate to Projects > Your Project > Settings > Environment Variables and add:

• DISCORD_BOT_TOKEN – your bot’s token from the Discord developer portal.
• Any other secrets your bot requires.

In bot.js, read them via process.env.DISCORD_BOT_TOKEN:

const { Client, GatewayIntentBits } = require('discord.js');
const client = new Client({ intents: [GatewayIntentBits.Guilds] });

client.once('ready', () => {
  console.log(`Logged in as ${client.user.tag}`);
});

client.login(process.env.DISCORD_BOT_TOKEN);

Deploying to Discloud

Git Push vs. ZIP Upload

Discloud supports two deployment methods:

• Git Push – Connect a GitHub or GitLab repository. Every push triggers an automatic build and redeploy. The build logs appear in the dashboard.
• ZIP Upload – Drag‑and‑drop a .zip that contains your source and Dockerfile. The platform builds the image once and keeps it until you push a new ZIP.

Both methods require the Dockerfile to be in the repository root or ZIP root.

Monitoring and Logs

After deployment, the Logs tab streams stdout/stderr from the running container. Look for the bot’s startup message to confirm it connected successfully.

Resource Limits and What to Watch For

Free vs. Paid Tiers

Tier	RAM	CPU	Image Size
Free	512 MB	1 core	50 MB
Pro	2 GB	2 cores	200 MB
Premium	4 GB	4 cores	400 MB

Discloud automatically restarts containers that exit. If your bot consumes more RAM than the tier allows, the container will be killed and restarted, causing brief downtime.

Common Pitfalls

• Exceeding the image size limit – Large node_modules or media assets can push the image over 50 MB on the free tier. Remove unused packages or use multi‑stage builds to keep the final image lean.
• Wrong port exposure – Failing to EXPOSE the correct port results in a “connection refused” error. Verify the port your bot listens on and update the Dockerfile accordingly.
• Private base images – If you pull a base image from a private registry, the build will fail unless you supply a ~/.docker/config.json via the UI, which the free tier does not support.
• Unsupported runtime versions – Using a Node 18 base image on a platform that only supports Node 14 will cause build failures. Always specify the exact runtime in the Dockerfile.
• RAM leakage – Bots that keep large in‑memory caches can hit the RAM limit. Profile memory usage locally before deploying.

Verifying Your Deployment

Checking Resource Allocation

In the dashboard, the Stats tab displays current RAM and CPU usage. Compare these numbers to the tier limits. If the usage spikes near the limit, consider scaling up or optimizing the bot.

Ensuring the Bot Is Alive

Send a test command to the bot or use the Discord API to check its presence. In the logs, look for the startup confirmation line you added to bot.js. If it appears, the bot is running.

When Things Go Wrong

Build Failures

Common causes:

• Missing Dockerfile or incorrect path.
• Syntax errors in the Dockerfile.
• Large image size exceeding the tier limit.
• Private registry access without credentials.

Check the build log for error messages. Fix the issue locally, commit the change, and push again.

Runtime Crashes

If the container exits immediately, the logs will show the exit code. A 1 exit code often indicates an unhandled exception. Add error handling to your bot and redeploy.

Conclusion

Discloud’s Docker integration gives Discord bot developers a straightforward path from local code to a production‑ready container. By keeping the image under the tier‑specific size limit, exposing the correct port, and injecting secrets via the dashboard, you can avoid the most common deployment headaches. Use the Logs and Stats tabs to verify uptime and resource usage, and upgrade to a paid tier when your bot’s memory or CPU needs grow.