How to leave AscendKit

How it works

1. 1. Keep your integration code

   Your Better Auth configuration, sign-in flows, session handling, and plugin setup are standard Better Auth. Leaving means changing the database adapter, not rewriting auth.
2. 2. Request your data

   Self-serve export is not shipped yet. Today this is a support-assisted process: contact us and we produce your data in Better Auth's schema shape.
3. 3. Point Better Auth at your own database

   Swap the AscendKit adapter for any standard Better Auth adapter — Postgres, MySQL, SQLite, Drizzle, or Prisma — load the data, and your app runs independently.

What does AscendKit actually store?

AscendKit is a hosted platform, so your user records live on AscendKit infrastructure. Being direct about that matters more than a comforting phrase: the SDK routes every Better Auth database operation to the AscendKit backend, which persists it.

The auth data uses Better Auth's standard models — user, account, session, verification, and jwks — rather than a proprietary schema. Alongside those sit the lifecycle domains: email templates and send history, campaigns, survey definitions and responses, journey definitions and per-user state, and webhook configuration. All of it keys to the same usr_ profile, which is the point of the platform and also the thing to understand before leaving.

What is the actual exit path today?

Contact support, receive your data, and repoint Better Auth at a database you control. The AscendKit adapter is one line in your auth configuration; replacing it with a standard Better Auth adapter is the whole code change.

The honest limitation is that this is not yet self-serve. There is no export command, and building one across five interlinked domains is real work rather than a weekend feature — it is tracked but not scheduled. Anyone whose risk model requires a one-command export today should weigh that before adopting.

The part that is genuinely reassuring is not the export. It is that Better Auth is independent of us. If AscendKit disappeared entirely, the library keeps working, your integration code keeps compiling, and your data sits in that library's documented schema. Compare that with a proprietary hosted user store, where leaving means both a data migration and an auth rewrite.

// Before: AscendKit as the backing store
export const authRuntime = createAscendKitAuthRuntime();

// After: standard Better Auth against your own database
import { betterAuth } from "better-auth";
import { Pool } from "pg";

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

What will not come across?

Anything with no receiving standard. Journey definitions and per-user journey state are the clearest example: no other platform models lifecycle journeys the same way, so those are rebuilt rather than migrated, exactly as they would be leaving Customer.io or Loops.

Deliverability reputation does not transfer either. Your domain's DKIM and SPF records point at AscendKit's SES configuration, so a new provider means re-verifying the domain and rebuilding sending reputation. This is true of every email platform migration.

Sessions are not worth moving; users sign in again. Password hashes are a policy decision rather than a technical limit — they are scrypt hashes and portable in principle, but exporting credential material requires explicit sign-off rather than being handed over by default.

FAQ

Related guides

• Set up with Claude Code — every configuration step is reproducible from the CLI, not just the dashboard.
• Add authentication to FastAPI — token verification is standard JWT, so your backend is not coupled to us.
• What to add after Better Auth — the inbound version of this page — what AscendKit adds on top of the library you keep either way.
• One user record, not four copies — why the data is consolidated in the first place, which is what makes leaving a single migration rather than four.
• AscendKit vs Clerk — how the exit path compares with a proprietary hosted user store.