Production Stacks
Run SiteKnock at scale — multiple backend replicas, shared Redis, managed database, and S3-compatible storage.
Scaling beyond one instance
A single frontend and backend container is enough to launch. As you grow, scale each tier independently and move shared state out of the containers.
Shared services
| Concern | Single instance | At scale |
|---|---|---|
| Database | Any supported provider | Managed PostgreSQL (recommended) |
| Storage | Filesystem | S3-compatible (AWS S3, Cloudflare R2, MinIO) |
| Cache | In-memory | Redis |
| Rate limiting | In-memory | Redis |
Why Redis for multiple replicas
In-memory cache and rate limiting live inside a single backend process, so they don't coordinate across replicas. Once you run more than one backend instance, switch both to Redis so state is shared:
CACHE_PROVIDER=redis
RATE_LIMIT_PROVIDER=redis
See Caching & Rate Limiting for the configuration details.
Storage at scale
Use S3-compatible storage rather than the filesystem so every replica reads and writes the same files. Keep an optional private bucket for sensitive uploads, and serve public assets directly from the bucket or a CDN.
Database at scale
Use a managed PostgreSQL service, apply migrations as part of each release, and point all backend replicas at the same database. Connection pooling at the database or proxy layer keeps connections healthy under load.
Rolling out updates
Because the frontend and backend are independent, you can roll out each tier separately. Health-check new backend instances at GET /api/health before shifting traffic, and keep the previous version available until the new one is healthy.