llmBreakr

Self-hosting

Running llmBreakr in production, with your own database and infrastructure.

llmBreakr is built to be lightweight to operate: one container, two external dependencies.

What you need

  • MySQL — a managed instance (RDS, Cloud SQL, PlanetScale, etc.) or self-managed. llmBreakr doesn't bundle a database.
  • Redis — for rate-limit counters and caching. Same story — bring your own managed or self-hosted instance.
  • The yashbansal0412/llmbreakr-ai-gateway image — from Docker Hub or GHCR, pinned to a release tag.

Production checklist

  • Pin IMAGE_TAG to a specific release rather than tracking latest.
  • Generate JWT_SECRET and CREDENTIAL_ENCRYPTION_KEY with a real random source (openssl rand -hex 32) and store them in your platform's secret manager, not in a checked-in .env.
  • Put the gateway behind TLS — terminate at your load balancer / ingress, not in the container.
  • Point DB_HOST / REDIS_HOST at managed instances with backups and monitoring already in place.
  • Restrict inbound access to port 3000 (dashboard) to your team, and expose port 4000 (data plane) only to the services that need it.

Scaling

Because rate limiting and session state live in Redis rather than in-process, you can run multiple replicas of the gateway container behind a load balancer without limits drifting between instances. MySQL and Redis are the only stateful pieces to scale independently.

Upgrading

Images are tagged by release. Bump IMAGE_TAG in your .env or compose file and redeploy — check the GitHub releases for changes between versions before upgrading in production.

A managed SaaS version of llmBreakr is planned as a separate offering, but it won't replace or gate features from the open-source gateway — everything documented here stays free and self-hostable.

On this page