Skip to content
Day Planner

Running more than one instance

One container is enough for most installs. If you run two or more app containers behind a load balancer, for availability or on a platform that scales automatically, three things change.

Share rate limits through the database

Section titled “Share rate limits through the database”
Terminal window
RATE_LIMIT_STORAGE=database

With the default memory, each container counts sign-in attempts on its own, so the real limit is multiplied by the number of containers. database shares the counters through Postgres. It adds a few milliseconds to each sign-in-related request.

Run migrations once per deploy

Section titled “Run migrations once per deploy”
Terminal window
RUN_MIGRATIONS_ON_START=false

Then run this once per deploy, before the new version takes traffic, for example as Render’s pre-deploy command or a one-off job:

Terminal window
node ./node_modules/prisma/build/index.js migrate deploy

This stops several containers trying to migrate the same database at once.

Use the same secret everywhere

Section titled “Use the same secret everywhere”

Every container must have the same BETTER_AUTH_SECRET. A session signed by one container has to be accepted by the others.

Run the same image version on every container, too. Next.js builds an encryption key for form submissions into each image, so containers from the same image already agree. Only if you build from source on each server separately do you need to set NEXT_SERVER_ACTIONS_ENCRYPTION_KEY (generate it with openssl rand -base64 32) at build time.

See also

Section titled “See also”