How to host a Discord bot 24/7 on a VPS with Node.js and PM2

If discordbot already exists, inspect its home, group, and shell instead of creating it again. A Gateway-only bot opens an outbound connection and does not need a public inbound port. Before enabling UFW, replace the SSH rule if the host uses a custom port and confirm that the provider has a recovery console.

A web dashboard, inbound webhook receiver, or OAuth2 callback changes the design. Expose only the required HTTPS reverse-proxy port, never the Node.js process directly.

2. Install a supported Node.js LTS release

At the July 31, 2026 factual cutoff, Node.js 24 is Active LTS and Node.js 22 is Maintenance LTS. The July 29 security release shipped patched builds 24.18.1 and 22.23.2. The Node project recommends Active LTS or Maintenance LTS lines for production on its release schedule.

The commands below download the official 24.18.1 AMD64 or ARM64 archive and verify its checksum before extraction. If a dependency still requires Node 22, set NODE_VERSION to 22.23.2. On a future deployment, select the current patched LTS version after reviewing its security notes.

The last two commands are checks for you to run. Confirm that they report the intended branch; no output is assumed here.

3. Publish a reproducible release

A releases/ directory plus a current symlink lets you switch versions without overwriting the last one. Deploy an immutable tag or reviewed commit rather than the moving tip of main.

Option A: clone with Git

Replace the example URL and tag. For a private repository, use a read-only deploy key. Never put a personal access token in the repository URL.

Record the hash returned on your server in the deployment log; this guide does not invent that value.

Option B: copy the project from your workstation

Run this on your local machine, excluding secrets, installed dependencies, and logs:

Then publish the upload on the VPS with the correct ownership:

4. Keep the token out of Git and install dependencies

Store the token at /opt/discord-bot/shared/.env, outside every release. Open it in an interactive editor so the secret never becomes part of shell history.

The file has this shape. Replace the marker inside the editor, never in a command you paste or share:

Lock down the file and inspect its metadata. It should report mode 600 and owner discordbot.

Keep the same policy in the project’s .gitignore, and check common variants with git ls-files -- '.env' '.env.*'. Only .env.example may appear, and only when it contains no secrets:

npm ci requires a lockfile and reproduces it. If TypeScript or another asset pipeline needs development packages, build and test in CI, or install all packages temporarily, build, and finish with npm prune --omit=dev. Do not run an ad-hoc npm install in production that rewrites the lockfile.

Before introducing PM2, you can run one short foreground test after replacing src/index.js with the real entry point. Keep the local instance stopped so the same bot does not open two sessions, and press Ctrl+C after you observe Ready.

If the token has ever appeared in Git, a log, a screenshot, or a visible command, treat it as compromised. Regenerate it in the Developer Portal, update the file, and restart the bot. Removing it from the latest commit does not invalidate leaked copies.

Declare only the Gateway intents and permissions each feature needs. Discord’s Developer Policy limits API data use to what is necessary for the stated functionality; extra events also expand cache use, failure surface, and data exposure.

5. Run PM2 as the bot user

Install PM2 into discordbot’s own prefix. Run every later PM2 command as that same identity. PM2 keeps per-user state, so root and discordbot would see different process lists and daemons.

Create /opt/discord-bot/ecosystem.config.cjs. The .cjs suffix keeps module.exports in CommonJS mode even when the application sets "type": "module". Replace script with the bot’s actual entry point.

PM2’s ecosystem file documentation covers the working directory, script, and restart controls used here. The bot token stays out of this file. One small bot runs as a single forked instance: adding generic cluster workers without deliberate sharding, locks, and idempotent jobs can duplicate replies and scheduled work.

restart_delay, min_uptime, and max_restarts contain a crash loop; they do not fix it. The max_memory_restart value is only a sample. Tune it below the VPS limit while leaving room for the OS. A memory restart may contain the immediate blast radius, but it is not a substitute for profiling and fixing a leak.

6. Add a Gateway readiness check

PM2 can see a process, not whether the Discord client is ready. Add a local endpoint in the module where client already exists. This discord.js 14.x example returns 200 only when client.isReady() is true and listens on loopback, so it does not create a public endpoint. Check the API against the installed version’s Client documentation.

Adapt the import if the project uses CommonJS, confirm that DISCORD_TOKEN matches the variable your application reads, and close the server from your signal handler if the bot already implements graceful shutdown. Next, check the PM2 file, start it, and inspect process state and logs:

Ctrl+C exits the log stream; it does not stop the bot. After the application logs Ready, run the local readiness probe:

Production validation has three layers: PM2 reports the process online, /healthz reports a ready client, and a safe slash command in a private test server receives a reply. Do not automate the last check with a normal user account. For external monitoring, emit an outbound heartbeat or place the route behind authenticated HTTPS.

7. Restart the bot after a reboot

PM2’s startup documentation separates two jobs: registering a startup service and saving the process list that it will restore. As discordbot, run:

PM2 prints a command tailored to the service manager, user, home directory, and PATH. The block then uses exit to return to the sudo-enabled account; from there, run that exact generated command. Do not assemble one by hand or reuse one from another server. Then switch back to the bot user and save the current list:

Schedule a maintenance window, reboot, and reconnect:

Once SSH is available again, verify the service, the per-user PM2 state, and actual readiness:

If the generated command created a different service name, use that instead of pm2-discordbot. The deployment is not complete until this reboot test passes. After changing the Node.js installation, PM2 recommends regenerating its startup script so the service uses the current runtime. Follow the host-specific output from pm2 unstartup and pm2 startup, then save the list again.

8. Keep logs useful and bounded

PM2 writes logs under $HOME/.pm2/logs by default and can filter them by process, as described in its log management guide. Use a finite window for routine diagnosis and watch disk space as a separate metric.

Install rotation as discordbot. The following settings are an initial policy, not a universal retention requirement; tune them for log volume, available storage, and compliance needs.

Never log the token, authorization headers, private data, or complete payloads you do not need. Useful operational events include startup, Ready, disconnect with its code, resume, contextual errors, and shutdown.

9. Update by tag and keep a rollback path

Test each release tag in CI and, where practical, staging. Build a new server-side release without touching the active one, install its production dependencies, and record the previous target before the atomic switch:

Replace the syntax check with the project’s own validated pipeline where appropriate; it is not a functional test. Check the new release before saving PM2 state:

If validation fails, point current back to the recorded release. This rolls back code and dependencies, not data or database migrations:

For SQLite or any other mutable state, use backward-compatible migrations or a tested restore plan. Keep at least one known-good release until the new version is proven.

10. Backups and ongoing maintenance

• Code: retain immutable tags/commits and package-lock.json. A remote repository does not back up production-generated data.
• Secrets: keep the token in an approved secret manager or encrypted backup with restricted access, never in Git or an unencrypted archive.
• Data: back up SQLite, uploaded files, and persistent configuration with an application-consistent method. Copying a live database can produce an unusable backup if its own backup mechanism is ignored.
• Configuration: retain a reviewed, secret-free copy of ecosystem.config.cjs and record the deployed Node, PM2, and commit versions.
• Recovery: regularly prove that you can restore data, publish a release, and run pm2 resurrect from the saved process list.

If the bot uses SQLite, its official CLI provides the .backup command for copying the open database. Adjust both paths, move the result off the VPS over an encrypted channel, and test restoration. This example does not include .env:

As routine maintenance, review Node and dependency advisories, patch Ubuntu during a window, inspect PM2 restart counts, Gateway latency, memory growth, and disk usage, and repeat the reboot test after Node, PM2, or systemd changes.

Troubleshooting common symptoms

At that point, “24/7” no longer means leaving a terminal open. It means a supervised process, repeatable startup, a meaningful health signal, recoverable data, and a known-good release ready to restore.