All runtime configuration for the Capinetta RP Bot System is controlled through environment variables loaded from aDocumentation 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 startup. Copy .env.example to .env in the project root and populate every required value before running either bot or the web dashboard. The config.js module reads all variables, validates required ones, and exports them as structured objects used across the entire codebase.
Required Variables
These eight variables must be present and non-empty. Omitting any one of them causes an immediateprocess.exit(1) with an error message listing which keys are missing.
Discord bot token for the General Bot. Obtained from the Discord Developer Portal under your application’s Bot tab. Keep this value secret — it grants full control of the bot account.
Discord bot token for the Whitelist Bot. This is a separate bot application from the General Bot, requiring its own token from the Developer Portal.
OAuth2 Application Client ID for the General Bot. Found in the Developer Portal under OAuth2 → General. Used by the Express dashboard for Discord OAuth2 login flows via Passport.js.
OAuth2 Application Client Secret for the General Bot. Found alongside
GENERAL_CLIENT_ID in the Developer Portal. Required for completing the OAuth2 authorization code exchange. Never expose this in client-side code or logs.Full OAuth2 redirect URI registered in the Discord Developer Portal under OAuth2 → Redirects. Must match exactly. Example:
http://localhost:3000/auth/discord/callback for local development, or https://dashboard.capinettarp.com.ar/auth/discord/callback for production.A long, random, secret string used to sign Express session cookies. Generate a secure value with
openssl rand -base64 32 or a password manager. Rotating this value will invalidate all existing user sessions.The Discord snowflake ID of your main server (guild). Used for guild-scoped slash command registration and as the default guild for multi-guild lookups. Enable Developer Mode in Discord settings to copy IDs.
Full MariaDB/MySQL connection string in Prisma format. Example:
mysql://USER:PASSWORD@localhost:3306/capi_netta_rp. This single URL is used by the Prisma client in both bot processes and the dashboard.Whitelist Bot Variables
These variables configure the separate Whitelist Bot process (index-whitelist.js).
Discord Application Client ID for the Whitelist Bot. Required to register the
/aprobar and /rechazar slash commands via deploy-whitelist.js.Discord guild ID where whitelist slash commands are registered. Can be the same as
GENERAL_GUILD_ID or a separate staff-only server.Role ID whose members are authorised to run
/aprobar and /rechazar. The Whitelist Bot checks membership in this role before executing whitelist actions.Channel ID where whitelist result embeds (approvals and rejections) are posted by the Whitelist Bot.
Database — Individual Variables (Optional)
These variables are an alternative toDATABASE_URL for environments that construct the connection string programmatically.
MariaDB/MySQL server hostname.
MariaDB/MySQL server port.
Database user with read/write access to the bot database.
Password for the database user.
Name of the MariaDB database (e.g.
capi_netta_rp).Redis (Optional)
Redis is used as a distributed cache for the web dashboard — storing user profiles, server stats, and Discord metrics. If Redis is unavailable at startup, the system automatically falls back to in-process memory caching.Hostname of the Redis server. For Docker deployments, use the service name (e.g.
redis).Port the Redis server is listening on.
Authentication password for Redis. Leave empty (or omit) if your Redis instance does not require a password — common in local or Docker development environments.
HTTPS
Controls whether the Express dashboard server starts with TLS. Recommended for any publicly accessible deployment.Set to
true to start the Express server in HTTPS mode using the certificate and key at the paths below. When false, the server listens on plain HTTP.File system path to the SSL/TLS private key file. For Let’s Encrypt certificates this is typically the
privkey.pem file.File system path to the SSL/TLS certificate file (full-chain recommended). For Let’s Encrypt this is
fullchain.pem.FiveM Integration
Base URL of your FiveM server’s HTTP endpoint. Used to query
info.json and players.json for server status widgets on the dashboard. Example: http://your-fivem-server:10000. Defaults to null — FiveM integration is disabled if unset.Webhooks
Discord webhook URL for the system monitoring alert notifier. When a monitoring threshold is breached (see below), an embed is posted to this webhook. Example:
https://discord.com/api/webhooks/ID/TOKEN. Defaults to null — alerts are suppressed if unset.Monitoring Alert Thresholds
These variables configure the thresholds at which the monitoring system fires an alert toALERTS_WEBHOOK_URL. All values are parsed as integers via parseInt() in config.js, with the defaults shown below.
HTTP error percentage (4xx/5xx responses as a share of total requests) that triggers an alert. Default:
5 (alert when ≥5% of requests return errors).Minimum acceptable Redis/memory cache hit rate percentage. Alert fires when the hit rate falls below this value. Default:
60 (alert when cache hit rate drops below 60%).Maximum number of slow database queries (queries exceeding a latency threshold) permitted before an alert is sent. Default:
10.Maximum system memory usage percentage. Alert fires when RAM usage exceeds this value. Default:
85 (alert at ≥85% memory usage).Maximum number of Discord API rate-limit responses (HTTP 429) before an alert is sent. Default:
5.Maximum acceptable average HTTP response time in milliseconds for the dashboard. Alert fires when the average exceeds this value. Default:
1000 (1 second).Cache TTL Configuration
Fine-tune the in-memory and Redis cache behavior for the web dashboard. All values are in milliseconds and parsed viaparseInt() with the defaults shown.
Time-to-live for cached Discord user profile data in milliseconds. Default:
600000 (10 minutes). After this duration, the next access triggers a fresh database lookup.Interval at which the background job proactively refreshes user profile cache entries in milliseconds. Default:
900000 (15 minutes). Should be larger than CACHE_USER_PROFILE_TTL.Number of user profiles refreshed per batch cycle during the background refresh job. Limits API and DB load per tick. Default:
50.Maximum number of user profiles held in the in-process cache at any one time. Once reached, the least-recently-used entries are evicted. Default:
1000.Time-to-live for the
/stats and dashboard statistics cache in milliseconds. Default: 300000 (5 minutes).Time-to-live for Discord-side metrics (member counts, online counts, etc.) in milliseconds. Default:
45000 (45 seconds). Kept short to reflect near-real-time server activity.How often the background cleanup job runs to prune
activity_logs entries older than the retention window (default: 30 days). Value is in milliseconds. Default: 86400000 (24 hours).API & Log Retention
Additional tuning variables for member fetch rate limiting and log pruning.Minimum interval in milliseconds between full guild member fetch calls in the management dashboard. Prevents Discord rate-limit errors on large servers. Default:
30000 (30 seconds).Number of days to retain
activity_logs rows before the background cleanup job prunes them. Default: 30 days. Increase this value on high-traffic servers to retain longer audit history at the cost of additional database storage.Ticket Behavior
Control inactivity reminders and the close-confirmation flow inside ticket channels.Delay in milliseconds after the last message in a ticket before the first inactivity reminder ping is sent to staff. Default:
1800000 (30 minutes).Delay in milliseconds after the first inactivity reminder before a second, final reminder is sent. Default:
3600000 (60 minutes). Tickets without activity after this second reminder are flagged for review.Duration in milliseconds that the close-confirmation button collector waits for a staff confirmation click before timing out and cancelling the close action. Default:
5000 (5 seconds).