Skip to content

Host Installation

Jump to bottom
Jerad Berhow edited this page Oct 12, 2026 · 8 revisions

Host Installation

Running PariahBot on a Linux host under systemd. Complete Bot Setup first — you'll need the token and application ID during this.

Prefer Docker? Container Installation runs the same bot from the published image, and compares the two. On AWS or Azure, start with AWS Hosting or Azure Hosting, which set up the machine and then come back here.

Requirements

  • A Linux host with systemd. The script uses apt-get, so Debian or Ubuntu; anywhere else it stops before changing anything
  • Node.js 24+ — the script installs it via nvm, you don't need it beforehand
  • sudo access from a normal (non-root) user account
  • Server Members Intent switched on for your application in the Developer Portal, or the bot can't connect. See Bot Setup

On better-sqlite3: it is pinned to 12.11.1 in package.json deliberately — the last release shipping a prebuilt binary. 13.0.0+ compiles from source on every install, which needs a C/C++ toolchain this deployment doesn't provision. If the Node floor is ever raised, check that package's releases for a version whose prebuilds cover the new minimum before bumping it.

Install

Run with sudo from your normal user account — that account becomes the one the bot runs under, so don't su to root first:

git clone https://github.com/CosmicCubicle/PariahBot.git
cd PariahBot
sudo ./deploy/setup.sh

The script:

  1. Installs system packages (ca-certificates, curl, git). No compiler is needed: see the better-sqlite3 note above
  2. Copies the repo to /opt/PariahBot (when run from elsewhere) and gives it to the invoking user
  3. Installs Node.js 24 via nvm and production dependencies (npm ci --omit=dev)
  4. Creates /opt/PariahBot/hom.env from .env.example on first run (mode 600), then prompts for the bot token (hidden) and application ID, and optionally a test server ID. Leave the server ID empty in production so commands register in every server; set it only for a test server, where commands appear instantly (see Configuration). Rerunning keeps existing values unless you enter new ones, and typing none clears the server ID
  5. Offers to set up the Admin-Dashboard: a port, the Discord client secret (hidden), and an optional public address for a Cloudflare Tunnel. Rerunning lets you keep, change or turn it off, and the end of the run prints the redirect URL to register and the SSH tunnel command
  6. Asks whether the Server-Log should include the text of edited and deleted messages (SERVER_LOG_MESSAGE_CONTENT). Only say yes once Message Content Intent is switched on in the Developer Portal, or the bot can't connect. Rerunning keeps the current answer on Enter
  7. Registers and enables pariahbot.service
  8. Offers to install the auto-update job that keeps it in sync with main (below)
  9. Registers the slash commands and starts the service, then reminds you to switch on Server Members Intent in the Developer Portal, which every install needs (see Bot Setup)

Rerunning it is safe — existing configuration is preserved and every step is idempotent.

It refuses to run while the same bot (the same token) is running in a container from Container Installation, because two copies would both answer every command and both run moderation, alerts and pollers. Moving from systemd to the container is covered on that page.

Auto-update job: staying in sync with main (optional)

A cron job that keeps the bot on the newest code in main. Every 15 minutes it checks GitHub, and only when main has moved it:

  1. hard-resets /opt/PariahBot to origin/main
  2. reinstalls dependencies if package-lock.json changed
  3. re-registers the slash commands if anything under commands/ changed
  4. restarts the service

When nothing has changed, it does nothing and logs nothing. Each update is logged to /opt/PariahBot/sync.log.

Leave it off if you'd rather update by hand, or if you change files in /opt/PariahBot yourself: the hard reset discards local edits to tracked files. hom.env, data/ and logs/ aren't tracked by git, so they're never touched.

The container install has its own equivalent, which pulls new images of main instead; see Container Installation → Updates.

Turn it on

The setup script asks near the end:

Install the read-only Git sync cron job every 15 minutes? [y/N]: y

If you said no at install time, rerun the script and answer y there. Press Enter at every earlier question to keep your current settings:

cd ~/PariahBot            # the clone you installed from
git pull
sudo ./deploy/setup.sh

It installs three things:
/usr/local/sbin/pariahbot-sync The sync script. It tracks main (BRANCH=main near the top)
/etc/sudoers.d/pariahbot-sync Lets the bot user run only systemctl restart pariahbot.service as root, so the job can restart the bot. Nothing else
A line in the bot user's crontab 0,15,30,45 * * * * /usr/local/sbin/pariahbot-sync, so every 15 minutes

The job runs as the bot user (the account you ran sudo from), not root, so it uses that user's nvm and Node.

Check it's working

As the bot user (not with sudo):

crontab -l                          # shows the pariahbot-sync line
/usr/local/sbin/pariahbot-sync      # run one sync now
tail -20 /opt/PariahBot/sync.log    # what it did

Running it by hand when main hasn't moved prints nothing and changes nothing. That's normal. After a sync, sync.log shows a syncing <old> -> <new> line followed by deployed <new>, service restarted.

To see what's waiting before it syncs:

cd /opt/PariahBot
git fetch origin main
git log --oneline HEAD..origin/main   # commits the next sync will bring in

Change how often it runs

Edit the bot user's crontab with crontab -e and change the schedule on the pariahbot-sync line. For example, 0 * * * * is hourly, and 30 4 * * * is once a day at 04:30. Rerunning the setup script and answering y puts it back to every 15 minutes.

Track a different branch

The branch is set only in the sync script; the crontab line doesn't name one. To follow another branch, for example to try out a change before it's merged:

sudo nano /usr/local/sbin/pariahbot-sync   # change BRANCH=main

Put it back to main when you're done. If the branch is deleted (say, after its PR merges), every run logs fatal: couldn't find remote ref. Rerunning the setup script and answering y also resets it to main.

Turn it off

Rerun the setup script and answer N at the sync question. It removes the sync script, the sudoers rule and the crontab line, and leaves the bot itself running.

Operations

sudo systemctl status pariahbot.service     # is it running?
sudo systemctl restart pariahbot.service
sudo journalctl -u pariahbot.service -f     # live logs
tail -f /opt/PariahBot/logs/commands.log    # command audit log
tail -f /opt/PariahBot/sync.log             # auto-update log

Data and backups

Everything the bot remembers lives in one file:

/opt/PariahBot/data/pariahbot.sqlite

Every server's settings are in there, keyed by server. That covers:

  • roles, alerts, voice hubs and role menus
  • auto-delete and /security
  • banned words, the streamer list, Instagram accounts and RSS feeds
  • moderation cases, warnings and temporary bans
  • giveaways and levels

Back up that file, plus hom.env for the credentials, and you can rebuild the host from scratch.

The database is in WAL mode, so a plain copy while the bot is running can miss recent writes. Stop it for the moment it takes to copy:

mkdir -p ~/pariahbot-backup
sudo systemctl stop pariahbot.service
cp /opt/PariahBot/data/pariahbot.sqlite* ~/pariahbot-backup/
sudo systemctl start pariahbot.service

The * copies the -wal and -shm files that sit beside it, when present.

The schema migrates itself on startup — the bot adds any missing tables and columns when it boots, so pulling a newer version never needs a manual migration step.

Next

Clone this wiki locally