Discord Tickets: self-hosted ticket management for Discord communities

What Discord Tickets solves in a Discord community

Discord Tickets turns Discord conversations into organized support cases. A member creates a ticket, the bot creates or manages the associated Discord space, and staff can claim, release, move, transfer, and close that case. The intended users are Discord server operators, community teams, support groups, and moderators that want control over ticket creation and handling without relying on a hosted premium or white-label bot.

The feature set goes beyond opening a private channel. Members can provide a topic and up to five custom questions before creating a ticket. Tags offer another path for resolving a member's problem without escalation. Automatic closure targets inactive tickets, while statistics record staff activity. Archived messages are stored in the database so a transcript can be viewed later. The README also describes references to a message or a previous ticket, although it does not explain the matching rules or retention limits.

This makes the project a community help desk inside Discord rather than a general support platform. It does not present itself as an email ticketing system or an external customer-service suite. Its scope is tied to Discord interfaces such as slash commands, buttons, select menus, and modals, plus the surrounding guild, channel, member, and permission model.

Discord Tickets architecture and ticket data flow

The repository is primarily JavaScript. Its `package.json` identifies `@discord-tickets/bot` version 4.0.52, with `discord.js` version `^14.18.0` and Node.js `>=18` as the runtime requirement. The declared database layer uses `@prisma/client`, and the Docker deployment defaults to MySQL 8. Other packages include Fastify, JWT and cookie support, multipart handling, Sentry, archiving, compression, command-line utilities, and configuration or internationalisation libraries.

Based on the repository layout, the runtime is split across `src/`, `db/`, and `scripts/`. Prisma-related dependencies indicate that persistent ticket and configuration data is represented through the database layer. The compose file supplies a MySQL service with a named volume at `/var/lib/mysql`, while the bot keeps its user data in `tickets-bot:/home/container/user`. The bot publishes port `8169`, and the Dockerfile checks `http://localhost:${HTTP_PORT}/status` as its container health endpoint.

The visible flow begins when a member uses Discord's interaction model to request a ticket. Discord Tickets can collect context through its form controls, then apply the configured ticket type, create the case, and make it available to staff. Archiving copies the case history into the database, while ticket organization operations alter staff and category assignments. The README does not expose the internal handler names or a complete sequence diagram, so details such as transaction boundaries and Discord permission checks cannot be confirmed from the repository files.

Installation routes for Discord Tickets

The README directs prospective operators to the documentation before installation and presents three choices. A public bot offers instant setup but remains branded and is presented as suitable for trying the system. A managed service provides the operator's own bot while someone else hosts it. Self-hosting puts operation in the operator's hands, and the README marks that path as requiring experience.

For a source deployment, `package.json` defines a Node.js start command. The README does not show a complete dependency installation or environment setup tutorial, so no unverified command is added here. The documented entry command after cloning, installing dependencies, creating the required configuration, and preparing the database is:

npm start

The script is defined as `node .`, and `package.json` declares Node.js `>=18`. The README does not document expected console output for a successful first launch. It points to the configuration guide instead.

Docker is the more concrete route exposed by the repository. Its compose file includes a `bot` service, a `mysql` service, a shared network, persistent volumes, and port mapping. The compose file expressly warns that it must be read in full because incorrect environment variables can cause performance, stability, or security problems.

Docker Compose settings for the first deployment

The checked-in `docker-compose.yml` provides the bot image `eartharoid/discord-tickets:4.0` and MySQL image `mysql:8`. It maps host port `8169` to container port `8169` and declares the required Discord and encryption values. The complete file must be edited rather than copied unchanged because the database passwords and public HTTP address shown in the repository are placeholders or example defaults.

This excerpt shows the core service relationships and the connection string used by the bot:

bot:
  image: eartharoid/discord-tickets:4.0
  depends_on:
    - mysql
  ports:
    - 8169:8169
  environment:
    DB_CONNECTION_URL: mysql://tickets:insecure@mysql/tickets
    DISCORD_SECRET:
    DISCORD_TOKEN:
    ENCRYPTION_KEY:
    DB_PROVIDER: mysql
    HTTP_EXTERNAL: http://127.0.0.1:8169
    HTTP_HOST: 0.0.0.0
    HTTP_PORT: 8169

`DISCORD_SECRET`, `DISCORD_TOKEN`, and `ENCRYPTION_KEY` are required according to the compose file. `MYSQL_PASSWORD` and `MYSQL_ROOT_PASSWORD` also require replacement before deployment. The bot URL must match the server address or domain through which the dashboard or associated HTTP interface will be reached. The compose warning specifically links readers to the project's environment-variable documentation.

After the values and Discord permissions are configured, the project can be started with the Docker Compose workflow described in the linked installation documentation. The README does not provide that launch command or list the exact Discord permissions, so neither is included here.

Configuration, transcripts, and staff operations

The included dashboard is the stated configuration surface. The README says that it supports settings and customisation for colours, messages, and other features. The dependency on `@discord-tickets/settings` is consistent with that dashboard-oriented configuration, but the repository files do not show its exact screens or saved fields.

Ticket organisation is more concrete. Staff can claim a ticket, release it, move it between categories, and transfer it between members. These operations make queue ownership visible without requiring every staff member to work from an external table. A ticket can also collect a topic and as many as five custom questions. That is useful when a support team needs consistent intake information, although the README does not state whether those questions are required or optional.

Archiving stores messages in the database and exposes transcripts later. This adds persistence beyond Discord's normal message history, but operators must account for the resulting database content and configuration. The compose file does not document retention periods, export controls, or deletion workflows, and the README does not establish whether transcript deletion is configurable. The availability of `db.dump`, `db.prune`, and `db.restore` scripts indicates maintenance commands exist, but their arguments and safety procedures are not explained in the README.

Limits of Discord Tickets compared with external support systems

The clearest limitation is platform scope. Discord Tickets automates a workflow inside Discord. It can claim and transfer cases, collect context, close inactive tickets, and retain transcripts, but the README does not mention email intake, web widgets, external CRM records, SLA routing, or customer account synchronization. A business expecting those integrations should confirm they are unnecessary before adoption.

Self-hosting also creates real operator work. The repository includes Fastify components, database persistence, encryption settings, Docker services, and health checking. Although Docker reduces setup effort, the compose file warns that malformed variables can create stability or security problems. Operators still need a Discord application, a persistent database volume, correct external addressing, credential handling, and a procedure for backups and upgrades.

A real alternative is a managed Discord ticket service. That approach moves hosting and some operations away from the operator but can add branding, pricing, or service constraints. Another alternative is a conventional support platform with email and CRM workflows. Its core difference is the channel model: it operates across external support channels instead of managing Discord-native channels and interactions. Discord Tickets is the better fit only when Discord is the operating environment and self-hosted control justifies the deployment work.

Maintenance, upgrades, and GPL-3.0-or-later obligations

The repository is not archived. Its last push was on 2026-10-04, and the same date is attached to release `v4.0.52`. Earlier listed releases include `v4.0.51` on 2026-08-13 and `v4.0.50` on 2026-03-02. These dates show recent release activity, but the README does not define a support window for old versions or publish a stable release branch.

The package license is `GPL-3.0-or-later`, as shown in both `package.json` and the repository's license label. This matters for operators planning to modify and distribute the bot. The README does not summarize the obligations, so organizations with distribution obligations should examine the actual `LICENSE` file and applicable obligations rather than treating this article as legal guidance.

Upgrade planning also involves more than changing the bot image. `bun.lock` is used by the Dockerfile to install pinned production dependencies, while persistent data lives in MySQL and `/home/container/user`. The repository includes dump, restore, and prune scripts, but the README does not specify a complete backup or rollback procedure. Before moving between versions, an operator needs a documented copy of the database and bot data, plus tested restoration steps for the target release.

Editorial conclusion

Adopt Discord Tickets when a community needs a configurable, self-hosted Discord support workflow and can operate Node.js, MySQL, credentials, and persistent volumes. Do not adopt it for a simple support desk that requires integrations or business processes absent from the project documentation. Before installation, verify the current configuration guide, review the complete Docker Compose values, and confirm that your Discord permissions and ticket workflow match the bot's documented model.

Frequently asked questions

Official sources

1. discord-tickets/bot on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases