Run Crunu on Vercel

On Vercel, the Crunu server runs as functions and keeps its data in Postgres on Neon. Choose it if your team already works on Vercel. Read Self-hosting: overview and platforms first and prepare .env.

What you need

• the vercel CLI, installed with npm install -g vercel, and a completed vercel login;
• a Neon database. Put its pooled address in DATABASE_URL, the one with -pooler in the host name;
• the web app of the same version in dist/web/, as described in Docker.

Deploy to production

sh deploy/vercel/deploy.sh --project vault-company --prod

Variables that are no longer in .env are listed by the script. Add --prune to remove them from the project.

Previews get their own database

Without --prod, the script deploys a preview. A build applies its migrations to whatever database it's connected to, so a preview must never use the production database by default. In .env, uncomment and fill in:

• PREVIEW_DATABASE_URL, a separate database such as a Neon branch;
• PREVIEW_SERVER_KEY, which server-init already filled in;
• optionally PREVIEW_BOOTSTRAP_TOKEN, to create a first owner in the preview database, and PREVIEW_PUBLIC_ORIGIN, if you want to sign in on the preview address.

Without these, a preview isn't deployed, and the script also refuses values equal to the production ones. Secrets that only production needs, such as SERVER_KEY_PREVIOUS, STATUS_TOKEN, CRON_SECRET and the alert email settings, aren't passed to previews. A preview with the production database and key is possible only with the explicit --preview-with-production-db flag.

Scheduled cleanup

Cleanup removes expired sessions, links and codes, trims the audit log and raises state-based alerts. On Vercel it runs from a Vercel cron job, only for the production deployment and only when CRON_SECRET is set. Without the --cron flag, the schedule is once a day at 17 3 * * *, because a more frequent schedule isn't allowed on Vercel's Hobby plan. Cleanup also runs along with requests, no more than once every 5 minutes per instance, and not at all without requests.

Deadlines don't depend on cleanup. Sessions, share links, break-glass access and the start of delayed network rule versions are checked on every request. What depends on cleanup are alerts that come from state:

• a machine pass used from outside and then from inside the allowed networks is found only by cleanup, and only while both uses are less than 10 minutes old;
• alerts such as "break-glass access expired" and "relaxation took effect" close only at cleanup.

If your organization uses network rules with machine passes, run cleanup every minute, as on your own server, or at least every 5 minutes. A frequent schedule needs Vercel's Pro plan. Pass the flag on every deploy, because each build writes the schedule again:

sh deploy/vercel/deploy.sh --project vault-company --prod --cron "* * * * *"

Each cleanup run queries the database, so with such a schedule the Neon database hardly ever sleeps. Take that into account in your Neon plan.

Old deployments

Every Vercel deployment stays reachable at its own *.vercel.app address, and old deployments run with the same database and secrets. A fix in a new deployment doesn't apply to requests sent to an old one. Vercel's Deployment Protection closes those addresses. It is on by default for new projects, so don't turn it off. If it was turned off, turn it on again or delete old deployments:

vercel ls vault-company
vercel rm <deployment address>

Client addresses and network rules

On Vercel the platform provides the client address, so you don't set TRUST_PROXY. Don't proxy the server's domain through Cloudflare if you use network rules. The server would then see Cloudflare's addresses instead of your clients', and the Vercel deploy script doesn't accept a Cloudflare TRUST_PROXY setting. Keep the DNS record unproxied, as DNS only.

Logs and rollback

• Logs: vercel logs <deployment address>, or the project's Logs in the dashboard.
• Rollback: in the dashboard, open Deployments, choose the previous production deployment and use Instant Rollback, or run vercel rollback. Migrations only add, so the previous version works with the current database.
• Backups: export Crunu archives with crunu-server export and turn on Neon's point-in-time restore as an extra layer. See Backups and restore.