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-gatewayimage — from Docker Hub or GHCR, pinned to a release tag.
Production checklist
- Pin
IMAGE_TAGto a specific release rather than trackinglatest. - Generate
JWT_SECRETandCREDENTIAL_ENCRYPTION_KEYwith 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_HOSTat managed instances with backups and monitoring already in place. - Restrict inbound access to port
3000(dashboard) to your team, and expose port4000(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.