DISCORD.JS HOSTING

Hosting for discord.js,
from repository to running bot.

Deploy a Node.js Discord bot from GitHub or ZIP with an explicit npm start command, environment-based token handling and visible runtime limits.

01 · RuntimeNode.jsdiscord.js projects
02 · Startnpm startpredictable command
03 · Sources2GitHub or ZIP
04 · Free slots2per account
A FOCUSED HOSTING MODEL

Everything the promise needs to mean.

01

Start with package.json

Declare discord.js and every production dependency, then expose one non-interactive start script. Commit the lockfile for repeatable installs.

02

Keep the token out of code

Read DISCORD_TOKEN from process.env. Never commit a live token, paste it into a log or include it in a downloadable archive.

03

Build from a known revision

Select a GitHub branch or upload a versioned ZIP so every deployment can be traced back to a specific source revision.

04

Diagnose the process, not a VPS

Botkeep focuses the interface on build state, process output, memory, CPU and lifecycle actions rather than exposing server administration.

INPUT → RUNTIME

The discord.js deployment contract

01

package.json

Dependencies and the start script live at the project root.

02

Source revision

GitHub branch or clean ZIP identifies what is being built.

03

DISCORD_TOKEN

The application reads one secret from the runtime environment.

04

stdout / stderr

Useful process output remains visible in the Botkeep console.

READ BEFORE DEPLOYING

Important answers.

Open the full FAQ
What happens if my bot crashes?

The production design records the process exit, keeps the relevant logs visible and retries with backoff so a broken bot cannot restart in a tight loop forever. Repeated failures move the bot into a crashed state for diagnosis instead of hiding the problem. The current panel only simulates this flow.

Will a new deploy replace the working version immediately?

The intended GitHub workflow builds a new immutable revision first and replaces the healthy deployment only after the build succeeds. A failed build should leave the previous deployment available. This production deployment pipeline is not connected in the current prototype.

Are CPU, RAM and the physical servers shared?

The underlying nodes are multi-tenant. Each bot receives an enforced allocation or cap rather than dedicated physical hardware. On Free, the intended per-bot limits are 512 MB RAM, 0.5 vCore and 1 GB storage. CPU remains a shared scheduling resource, so a displayed maximum is not a dedicated core or a guarantee of constant peak performance.

Can I host a real bot in the current public prototype?

Not yet. The current dashboard is a frontend prototype with local mock data. Do not enter a real Discord token, private repository or production file. Live Botkeep API, provisioning, authentication, database and payment integrations are not connected.

Two free bot slots. One clear starting point.

Choose Node.js or Python, bring a GitHub repository or ZIP, and review the exact limits before the beta opens.