Operations and Maintenance

This page covers routine admin work after Ticket-Bot is installed.

Restarting

Local install:

bun run start

Node.js/npm install:

npm run build
npm run node:start

Docker:

docker compose restart bot

On restart, the bot deploys commands and syncs panels again.

Updating

Local install:

git pull
bun install
bun run drizzle:push
bun run start

Node.js/npm install:

git pull
npm install
npm run drizzle:push
npm run build
npm run node:start

Docker:

git pull
docker compose up -d --build

After updating, check logs for startup validation errors.

Backups

Back up:

• .data/
• config/config.ts
• config/.env
• customized files under messages/

The database contains ticket records, panel tracking, close state, claim state, invited users, and transcript URLs.

Command Redeploy

Commands are deployed on startup to the configured guildId, so updates should appear quickly in that server after a restart.

Panel Re-Sync

Panels sync on startup. Ticket-Bot stores panel message IDs in the database and edits those messages on future restarts.

If you delete a panel message manually, the bot creates a new one on next startup.

If you change a panel's channelId, the bot posts in the new channel and updates the tracked record.

Changing Config

After editing config/config.ts, restart the bot.

Common changes that need restart:

• Adding ticket types.
• Editing panels.
• Changing staff roles.
• Changing close behavior.
• Changing message template references.
• Changing presence text.

Production Notes

• Keep the bot token private.
• Use a process manager or Docker restart policy.
• Keep .data/ on persistent storage.
• Monitor logs after config changes.
• Test ticket open and close flows after large updates.
• Keep the required Ticket-Bot attribution visible.