Security and Hardening

Durabull can change live queue data. Secure access to the dashboard, API, and connected Redis instances before using it with production workloads.

Before exposing the app

• Set DURABULL_AUTHLESS=false and a strong BETTER_AUTH_SECRET.
• Terminate HTTPS at your reverse proxy or load balancer.
• Set APP_BASE_URL and VITE_PUBLIC_APP_URL to the public app origin.
• Generate and preserve DURABULL_REDIS_URL_ENCRYPTION_KEY using openssl rand -hex 32.
• Set a separate DURABULL_SECRET_ENCRYPTION_KEY for Linear tokens or webhook signing secrets.
• Keep Redis and PostgreSQL reachable only from trusted services and networks.
• Back up configuration data and encryption keys, and test recovery before relying on it.

Email/password sign-up is enabled and email verification is not required in the current auth configuration, including production. There is no environment toggle that enables email verification; restrict ingress or customize the authentication implementation if your deployment requires it.

Authless mode

Authless mode grants owner access to everyone who can reach the app. Use it for localhost or isolated private deployments with external authentication, VPN, or equivalent controls.

MCP_AUTHLESS_BEARER_TOKEN protects only /mcp. It does not protect the dashboard or REST API. Production authless deployments require that token, and Durabull Cloud rejects authless mode.

Redis URLs and network access

Durabull validates URL format and allows only redis:// or rediss://. It intentionally permits private and internal hosts to support self-hosted infrastructure. URL validation does not prevent an authorized connection manager from reaching internal Redis services; enforce that boundary with network policy and app access controls.

Use separate credentials for staging and production. Prefer TLS (rediss://) where supported. Keep self-signed-certificate overrides disabled unless required by the provider.

Saved connection URLs are encrypted at rest. For legacy plaintext rows, use bun run db:encrypt-redis-urls with the correct database and encryption key before rollout. Do not replace encryption keys without a data re-encryption plan; preserve them with backups.

Webhook targets have a separate policy that blocks private and localhost addresses. See Webhook Notifications.

API protections

The app applies secure headers, a CORS policy, a 1 MiB request-body limit, and in-memory rate limits in production. General API requests allow 600/minute, authentication 50/10 seconds, and connection tests 10/minute per limiter key. Limits are skipped in development, test, and CI or when DISABLE_RATE_LIMIT=true.

Enable TRUST_PROXY=true only if a trusted proxy replaces forwarding headers and direct access to the upstream is restricted. Without trusted forwarding headers, anonymous callers can share a fallback rate-limit key. Durabull Cloud enables proxy trust automatically.

MCP

MCP adds OAuth bearer validation, resource binding, per-operation scopes, and organization checks. Service accounts also require policy bindings. Read scopes are the default consent bundle; write scopes must be requested explicitly.

• Ingress limit: 120/minute per bearer or trusted client-IP key across /mcp traffic.
• Operation limits: 60/minute per tool or resource name; heavy tools use 30/minute. The MCP guide lists the heavy tools.
• Output redaction: sensitive keys, Redis URLs, and token patterns are sanitized.
• Audit: tool and resource calls write mcp_audit_event rows on a best-effort basis. Records can be dropped under backpressure; transport auth failures are not included.
• Logs: mcp_telemetry JSON records policy denies, rate limits, and tool outcomes. Monitor HTTP access logs for transport auth failures.

Dynamic OAuth client registration at POST /api/auth/mcp/register is unauthenticated and rate-limited to 20/minute. Monitor it at the edge. Use the MCP operations runbook for deployment checks and incident response.

All in-memory limits are per process. Multiple replicas increase the effective allowance; apply shared edge limits when you need a global quota.

Secrets and operational checks

Keep real .env files out of version control and use your deployment platform's secret store. Plan authentication and integration credential rotation, while keeping encryption-key rotation separate from ordinary password changes.

Monitor auth bursts, connection-test failures, alert delivery failures, and Redis health. Verify that backup and restore includes the Durabull database, necessary Redis data, and encryption keys.