All runtime configuration for the Capinetta RP Bot System lives in a singleDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/Capinetta-RP/capinetta-discord-bot/llms.txt
Use this file to discover all available pages before exploring further.
.env file at the project root. This file drives every moving part: the two bot tokens, the MariaDB connection string, Discord OAuth2 credentials for the web dashboard, optional Redis caching, HTTPS termination, Discord webhook alerts, monitoring thresholds, cache TTLs, and ticket behaviour timers. The file is validated at startup by config.js — if any required variable is absent, the process logs a fatal error listing the missing keys and exits before attempting to connect to Discord or the database.
Start by copying the provided example file:
.env in your editor and work through each section below.
Required Variables
These eight variables are checked byconfig.js on every startup. The bot will not start if any of them are missing or empty.
Discord bot token for the Bot General process (
capinetta-general). Obtain it from the Discord Developer Portal under your application’s Bot tab → Reset Token. Keep this value secret — it grants full API access as the bot.Discord bot token for the Bot Whitelist process (
capinetta-whitelist). Created the same way as GENERAL_TOKEN but from a separate Discord application. Both tokens are validated at startup.OAuth2 Client ID used by the web dashboard to initiate the Discord login flow. Found in the Discord Developer Portal under your General Bot application → OAuth2 → Client ID.
OAuth2 Client Secret for the web dashboard. Located next to the Client ID in the Discord Developer Portal → OAuth2 → Client Secret. Regenerate it there if you lose it.
The full URL Discord redirects users back to after they authenticate. Must exactly match one of the Redirects registered in the Discord Developer Portal → OAuth2.In production, replace
localhost:3000 with your actual domain (e.g. https://dashboard.capinettarp.com.ar/auth/discord/callback).A long, random string used by Express to sign and verify session cookies. Generate a cryptographically secure value with:Store the output in this variable and never reuse it across environments.
The Discord server (guild) ID for your main community. Used to scope slash command deployment and per-guild settings. Enable Developer Mode in Discord (Settings → Advanced), then right-click your server icon and select Copy Server ID.
Full MariaDB/MySQL connection string in Prisma format:Replace
USER, PASSWORD, and DB_NAME with your actual credentials. The database must already exist before running npx prisma db push.Whitelist Variables
These variables configure the Bot Whitelist process and are read at startup fromconfig.whitelist in config.js.
OAuth2 Client ID for the Whitelist Bot application. Used when deploying whitelist slash commands via
npm run deploy:whitelist.Discord server ID where whitelist applications are processed. Can be the same as
GENERAL_GUILD_ID or a separate staff-only server.Role ID of the Discord role whose members are permitted to run
/aprobar and /rechazar. Right-click the role in Discord (Server Settings → Roles) with Developer Mode enabled to copy its ID.Channel ID where whitelist decision embeds are posted after a staff member approves or rejects an application. The bot must have Send Messages permission in this channel.
General Bot Channel & Role Variables
These variables are read byconfig.general in config.js and configure the operational channels and roles used by Bot General. All are optional — the bot starts without them, but features that depend on them (welcome cards, audit logs, role restoration) will be silently skipped until they are set.
Channel ID where the Canvas welcome card is posted whenever a new member joins the server. The bot must have Send Messages and Attach Files permissions in this channel.
Channel ID for audit log events — message edits/deletions, role changes, bans, voice activity, and member updates are posted here.
Channel ID where the verification button panel (posted by
/set-verify) is displayed. If omitted, the verification system will not function.Role ID assigned to members who have not yet verified. The anti-bot system and the verification button use this role to identify unverified users.
Role ID granted to members after they complete verification. The
/unmute command also restores this role as part of the full role set stored in the database.Role ID applied by the anti-spam system when a user is moved to the isolation zone. The bot saves the user’s previous roles to MariaDB before applying this role, so
/unmute can fully restore them.Channel ID of a dedicated warning channel where scam-related support alerts are posted. Used by the informational support message sent via
/set-support.Optional Variables
These variables enhance the system but fall back to safe defaults if omitted.Redis Cache
Hostname or IP address of the Redis server. If Redis is unavailable or these variables are not set, the dashboard automatically falls back to an in-memory cache.
TCP port Redis is listening on.
Password for Redis authentication. Leave empty if your Redis instance does not require a password (common in local development).
HTTPS
Set to
true to enable HTTPS on the Express dashboard server. Requires SSL_KEY_PATH and SSL_CERT_PATH to point to valid certificate files.Filesystem path to your TLS private key file. Only read when
HTTPS_ENABLED=true.Filesystem path to your TLS certificate file. Only read when
HTTPS_ENABLED=true.Integrations
Base URL of your FiveM game server’s HTTP endpoints (e.g.
info.json and players.json). Used to display live server statistics on the dashboard.Example from .env.example:Discord webhook URL that receives automated system alert notifications when monitoring thresholds are breached. Format:
HTTP port the Express dashboard listens on. Change this if port 3000 is already in use on your host.
Monitoring Thresholds
These variables configure the automated alerting system. When a metric exceeds its threshold, an alert is sent toALERTS_WEBHOOK_URL. All values are read and parsed by config.monitoring in config.js.
HTTP error response percentage that triggers an alert. Default:
5 (5% of requests returning 4xx/5xx errors).Minimum acceptable cache hit rate percentage. An alert fires when the hit rate drops below this value. Default:
60 (60%).Maximum number of slow database queries before an alert is raised. Default:
10.Maximum process memory usage percentage before an alert fires. Default:
85 (85%).Maximum number of Discord API rate-limit responses before an alert is sent. Default:
5.Maximum average HTTP response time in milliseconds before an alert triggers. Default:
1000 (1 second).Cache TTL Variables
These variables tune how long data lives in the Redis (or in-memory) cache. All values are in milliseconds and are read byconfig.cache in config.js.
How long a user profile is considered fresh in the cache before being evicted. Default:
600000 (10 minutes).Interval at which the background job refreshes cached user profiles in batches. Default:
900000 (15 minutes).Number of user profiles the background refresh job processes per batch cycle. Keeping this value low avoids Discord API rate limits during large bulk refreshes. Default:
50.Maximum number of user profiles stored in the in-memory cache at once. When the limit is reached, the oldest entries are evicted. Default:
1000.Time-to-live for server statistics data shown on the dashboard. Default:
300000 (5 minutes).Time-to-live for Discord-specific metrics (member counts, online status, etc.). Kept short for near-real-time accuracy. Default:
45000 (45 seconds).How often the background job runs to purge audit log entries that exceed the retention window. Default:
86400000 (1 day).Number of days audit log entries are kept before the cleanup job deletes them. Default:
30 (30 days).API Variables
Minimum time in milliseconds between successive Discord API calls to fetch guild member data. This cooldown prevents hitting Discord’s rate limits when the dashboard or background jobs request member profiles in quick succession. Default:
30000 (30 seconds).Ticket Behaviour Variables
These variables control timing within the ticket lifecycle and are read byconfig.tickets in config.js. All values are in milliseconds.
Time after the last message in a ticket before the first inactivity reminder is sent to staff. Default:
1800000 (30 minutes).Time after the first inactivity reminder before a second (final) reminder is sent if there is still no response. Default:
3600000 (60 minutes).Duration the close-confirmation button remains active after a staff member initiates ticket closure. Default:
5000 (5 seconds).