Add a backend to a Framer site: auth, database and payments

A Framer site has no server code of your own, so a backend has to live somewhere else: either a separate app on another subdomain, or the same codebase after you convert the site to code. Once the site is a Next.js project, authentication, a database and payments are ordinary features: route handlers or server actions for the logic, an auth library for sign-in, a database client for data, and a payment provider's checkout and webhook. The marketing pages stay as they were, and the new features sit beside them.

This post maps out both routes and walks through the converted one, with the decisions that matter. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer. It converts only sites you own or have permission to convert.

What can a Framer site do on the server today?

Framer handles hosting, forms (sent to email or a webhook), the CMS and site search, and lets you embed code and connect third-party services. What it doesn't give you is a place to run your own server code: there's no way to add an API route, read a database on the server, check who's signed in before rendering a page, or receive a payment webhook. Third-party embeds can fill some gaps, such as a booking widget or a hosted checkout link, but each one is someone else's server with its own limits.

Two ways to add a backend

Keep Framer and add an app when the marketing team must keep editing in Framer and the app is genuinely separate, like a dashboard behind a "Log in" button. Running a Framer site and an app on one domain covers how to make them feel like one product.

Convert and extend when the backend touches the marketing pages: gated content, member pricing, a "Buy" button that needs your own logic, or personalised pages. The rest of this post is about this route.

Step 1: Convert the site

Convert the published site with Deframer, pick Next.js (the default; TanStack Start, Astro and React Router also run a server), verify you own it and download the TypeScript project. How to export a Framer site to Next.js has the steps. Commit it untouched, run it, then branch for the backend work.

Don't pick Vite for this. A Vite project is a static site with no server: its forms post to an external service, and anything server-side would need a separate backend anyway.

Step 2: Know where new code goes

The converted project keeps routes thin and content in views. Follow the same shape for new features:

src/
  app/
    (marketing pages, as converted)
    account/page.tsx        new: signed-in page
    api/stripe/webhook/route.ts   new: payment webhook
  views/
    account.tsx             new: the page's component
  server/                   new: database client, queries, auth helpers
  components/               converted components, reused in new pages

src/server is a suggestion, not a convention the project imposes; any folder works if the team agrees. Keep server-only modules out of client components; Next.js's server-only package makes an accidental import fail at build time.

The converted design system is the main payoff here. New pages can use the site's colour tokens from src/styles/tokens.ts, its text-style classes and its components, so the account page looks like the marketing site without a separate design pass.

Step 3: Authentication

Pick an auth approach based on who manages users:

• A hosted auth service (Clerk, Auth0, Supabase Auth and similar) gives you sign-in UI, sessions and user management. Fastest to add, with a dependency on the vendor.
• A library you run (Auth.js, Better Auth and similar) keeps users in your database. More setup, more control.

Whichever you choose, the integration points in a Next.js 16 project are the same: a provider in the root layout if the library needs one, a check in server components or route handlers for pages that need a user, and the library's handler under src/app/api/. The converted project already has src/proxy.ts (Next.js 16's replacement for middleware), which handles the site's URL forms and redirects. If your auth library wants to run in the proxy, add its logic there carefully and keep the existing redirect behaviour intact; test old URLs afterwards.

Protect pages on the server, not only in the browser. A client-side redirect hides a page; a server-side check keeps its data from being sent at all.

Step 4: A database

For most marketing-site backends, a managed Postgres database is the plain choice, used through a typed query layer such as Drizzle or Prisma. The steps:

1. Create the database with your provider and put its connection string in .env.local (and in your host's environment, never in Git).
2. Add the client in src/server/db.ts.
3. Write queries in src/server/, call them from server components, server actions or route handlers.

What about the CMS? Framer CMS collections arrive as JSON files in src/cms, which are fine for content that changes when you deploy. If content needs to change without a deploy, or be written by users, move it to the database or a headless CMS. Framer CMS to JSON in Next.js covers moving collections to a database.

Step 5: Payments

For one-off purchases and subscriptions, a hosted checkout is the safest start: Stripe Checkout, or a similar page from your payment provider. The flow:

1. A server action or route handler creates a checkout session with the price and the user's ID.
2. The browser is sent to the provider's checkout page.
3. The provider calls your webhook, for example src/app/api/stripe/webhook/route.ts, when payment succeeds.
4. The webhook verifies the signature and records the purchase in your database.
5. Your pages read entitlements from the database, never from a query string.

The webhook, not the success page, is the source of truth. People close tabs. For selling physical or many products, see adding a shop to a converted Framer site.

Step 6: Forms you already have

The converted project's forms are already backend code. Each native Framer form became an API route that delegates to src/lib/forms.ts, with a rate limit, a honeypot and field checks, delivering to the webhook in FORMS_WEBHOOK_URL. You can keep that, or change a form's route to write to your database as well. Migrating Framer forms shows the route's shape.

Step 7: Hosting a site with a backend

A Next.js project with a database and webhooks deploys to the same places as before: Vercel, Netlify, a container or your own server. What changes is configuration: environment variables for the database, auth and payment keys on the host, and a webhook URL registered with the payment provider for each environment. Preview deployments need their own test keys so a preview never touches live payments.

Add security headers once there are sessions to protect; security headers for a self-hosted Framer site covers them.

A sensible order of work

1. Convert, commit, deploy the marketing site unchanged to a preview URL.
2. Add auth with one protected page.
3. Add the database and one real query.
4. Add checkout in test mode, with the webhook.
5. Review, then move the domain.

Each step ships on its own, so problems are easy to place.