BoilerplateHub

Nuxt + Neon + Better Auth + Stripe

Nuxt with Neon, Better Auth and Stripe pairs preview deployments with preview databases. Nitro environments and Neon branches can be moved together, so a reviewer clicks through real auth and real billing state. It suits a team shipping a Vue SaaS where pricing changes often enough that it needs testing.

Nuxt NeonBetter AuthStripe

Database

Neon

Neon suits Nuxt teams who deploy a preview per branch, because Nitro's environment configuration and Neon's branch connection strings can be wired to travel together. Better Auth's tables and the Stripe mirror both live in that branch, so a reviewer is exercising real schema rather than a fixture. Use a pooled connection string on serverless presets, since every invocation otherwise opens its own client and Postgres eventually declines.

Authentication

Better Auth

Better Auth puts sessions in Neon, which means a preview branch carries its own accounts and a tester can sign up without polluting anything permanent. Server middleware resolves the session once per request and stores it on the event context, and loading Stripe state at the same time saves a second query on every page. Mount the auth handler under server/api so Nitro, not a client composable, is the only thing addressing the auth database.

Payments

Stripe

Stripe's subscription model is expressive enough that most pricing ideas fit inside it, and in this stack all of that expressiveness ends up as columns in Neon that Nuxt routes read directly. Being merchant of record means invoices carry your name along with your tax obligations, which is worth the effort for a business selling to companies that expect to see an actual supplier on the document they file.

What to watch out for

Decide early where migrations run. Better Auth's CLI and your own migration tool both want to touch the same Neon branch, and a branch created from production already contains the auth tables, so a blind generate-and-apply during branch creation either errors or produces a second set of half-applied changes. Make branch provisioning a scripted step with one owner instead of something each developer improvises.

Boilerplates close to this stack

Matched on Nuxt plus the parts of this stack our catalog tags. Each card shows which pieces actually line up, so you can see how much you would still wire yourself.

A CLAUDE.md for this stack

The rules that matter for this combination specifically, including who owns entitlement state. Adapt the commands to your repository before committing it.

CLAUDE.md
# CLAUDE.md

This project is a Nuxt SaaS on Neon, Better Auth and Stripe.

## Stack

- Framework: Nuxt
- Database: Neon
- Auth: Better Auth
- Payments: Stripe

## Boundaries

- Never edit a migration that has already run. Write a new one.
- Never hardcode Stripe price or product identifiers in components. They belong in config.
- Never trust a client-supplied user id. Read the session from Better Auth on the server.
- Treat webhook handlers as idempotent. The same event will arrive twice.

## Entitlements

- Stripe is the source of truth for what a customer paid for.
- The database mirrors that state; it never decides it.
- Any check for "can this user do X" reads the mirrored entitlement, not a live API call.

## Before you say a change is done

- The app builds.
- Tests pass.
- No secret, key or webhook signing secret appears in a committed file.

Related stacks