Use case

A hosted dashboard for Better Auth

AscendKit is built on Better Auth, so it is a companion, not a replacement. Better Auth gives you free, self-hosted login and you run the database. AscendKit is the managed version of that foundation plus the layer you need next: transactional and verification email at scale, lifecycle journeys, NPS and CSAT surveys, webhooks, and a hosted dashboard. The trade is explicit — AscendKit hosts the user record so that email, journeys, and surveys can all read it without a sync layer. The schema underneath stays Better Auth's.

How it works

1. Keep your Better Auth foundation
AscendKit wraps Better Auth, so your existing login flows, sessions, and plugin configuration carry over. The models stay Better Auth's — user, account, session, verification.
2. Add the lifecycle layer
Turn on transactional and verification email, lifecycle journeys, and surveys from one project keyed to the same user record.
3. Get a dashboard
Manage auth settings, email templates, journeys, and survey analytics from the hosted portal instead of building admin UI yourself.

What does Better Auth deliberately leave out?

Everything after the session exists. Better Auth is an authentication library and a very good one — it is not trying to be a lifecycle platform, and its scope discipline is a feature rather than a gap.

The consequence shows up a few weeks in. You need verification email that actually lands, which means SES or Postmark plus DKIM, SPF, and a verified domain. You need a welcome sequence, which means a lifecycle tool. You want to know whether onboarding works, which means a survey tool. You want to see users without opening a database client, which means building admin UI.

Each of those is a vendor, an integration, and a copy of your user records that has to be kept in sync. Building on Better Auth is the right call; the question is what you assemble around it.

The layer above authentication, and who usually provides it.
Need	Better Auth alone	Typical stack	AscendKit
Sign-in, sessions, OAuth	Built in	Built in	Built in (Better Auth)
Verification email delivery	You wire a provider	Resend or Postmark	Built in
Domain, DKIM, SPF setup	Manual	Manual	Automated
Lifecycle journeys	Not in scope	Loops or Customer.io	Built in
NPS and CSAT surveys	Not in scope	Typeform or Sprig	Built in
Admin dashboard	You build it	You build it	Hosted
Copies of your user record	1 (yours)	4, synced by webhook	1 (hosted)

What actually changes in your code?

The database adapter, and little else. Your Better Auth configuration, sign-in flows, session handling, and plugin setup are standard Better Auth and carry across unchanged.

AscendKit implements Better Auth's adapter interface, so instead of pointing at your Postgres pool you point at the AscendKit runtime. The models stay Better Auth's — user, account, session, verification, jwks — and plugins you already use continue to work.

This is also why the exit is a database migration rather than a rewrite. Swapping back to a standard adapter is the same one-line change in the other direction.

auth.ts

// Self-hosted Better Auth
import { betterAuth } from "better-auth";
import { Pool } from "pg";

export const auth = betterAuth({
  database: new Pool({ connectionString: process.env.DATABASE_URL }),
});

// On AscendKit -- same Better Auth underneath, different backing store
import { createAscendKitAuthRuntime } from "@ascendkit/nextjs/server";

export const authRuntime = createAscendKitAuthRuntime();

When should you stay on self-hosted Better Auth?

When owning the database is a hard requirement, when you have EU or other data-residency obligations, or when you genuinely only need sign-in. In all three cases self-hosting is the better answer and you should not move.

AscendKit hosts your user records. If your compliance position or your own convictions require the records to sit in infrastructure you control, that is a real disqualifier rather than something to negotiate. AscendKit currently runs on US infrastructure, so EU residency is not available today.

The case for moving is narrower than most vendor pages admit: you want the layer above auth, you would rather not run four vendors to get it, and you would rather not build the admin UI. If that is not you, Better Auth alone is free and excellent.

Troubleshooting

A Better Auth plugin I rely on does not seem to work

Cause: Plugin models are stored in namespaced collections rather than the core five, and some plugins assume direct database access.

Fix: Most plugins work unchanged. Check the plugin against a test environment before migrating production, and tell us which one if it does not — plugin coverage is a compatibility question, not a design limit.

Verification emails were fine self-hosted but now look different

Cause: Templates now come from the dashboard rather than your codebase, so the default template is being used.

Fix: Author your template in the dashboard. It is versioned, has HTML and plain-text bodies, and supports variables that resolve against the user record.

FAQ

Is AscendKit a replacement for Better Auth?

No. AscendKit is built on Better Auth and complements it. You keep Better Auth for login and add AscendKit for email, journeys, surveys, and a dashboard.

Does my database still hold the user records?

No — this is the real trade. On self-hosted Better Auth you own the database. On AscendKit the records live on AscendKit, in Better Auth's own schema, so auth, email, journeys, and surveys can share one record without a sync layer.

What happens to my users if AscendKit goes away?

Better Auth is open source and independent of us, so the library and your integration code keep working. Your records sit in its standard schema. Self-serve export is not shipped yet — today, moving off is a support-assisted process.

Related guides

How to leave AscendKit — read this before adopting, not after — the exit path, and what does not migrate.
One user record, not four copies — the core argument for consolidating the layer above auth rather than assembling it.
Send email without managing SES and DNS — the deliverability work Better Auth correctly leaves to you.
Build a user onboarding journey — the lifecycle layer, driven by your own product events.

Start with one API key

Auth, email, surveys, and journeys share one user record, so you ship this without stitching vendors together.

Start free