
Your auth already works... well, mostly.

You've got password login, a users table, and some basic permissions. It's been perfect for your company's needs... until you get **the request**.

There's a deal on the line and the customer needs your auth to change. Sometimes it's simple:

> "We need sessions to expire after 12 hours."

Sometimes it's big:

> "We need SSO with Okta and SCIM provisioning."

And sometimes it shows up as a finding on a security audit:

> "Application must limit the number of concurrent sessions to 4."

Now you have a choice to make.

## The decision: keep building or migrate?

Your first option is straightforward: build it yourself. It gives you full control, but it takes time and effort away from your core product.

Your other option is to switch to an external auth provider. This gives you a lot of features quickly, but most external auth providers are designed to be all-in-one solutions. To get the features you need, you have to migrate your users and some of your existing auth code.

We've spent years helping teams through that trade-off when building [PropelAuth Cloud](https://www.propelauth.com). The pattern we kept seeing was the more these customers already had in place, the less appealing a full migration looked.

These companies didn't want to _replace_ their auth - they wanted to **extend** it.

## An auth product that feels like you built it

What we wanted was a solution that gives you the flexibility of something you built yourself while still giving you the speed, future-proofing, and tooling of an external auth provider.

That's why we built **PropelAuth BYO**.

**PropelAuth BYO** is a self-hostable sidecar that **enhances your existing auth** instead of replacing it.
Keep your users table, passwords, and login flows.
Layer on the enterprise features customers ask for - feature by feature, on your schedule - without a migration.

When designing BYO, we focused on a few core principles:

### Self-hosted by design (keep control)

Auth data sprawl creates risk and complexity. BYO runs in _your_ cloud, next to _your_ app, against _your_ Postgres. No fragile webhook chains. No second source of truth. Your data and logging stay in your control.

### Boring to operate (fast to ship)

A sidecar should be uneventful. BYO is a single container with one dependency: **Postgres**. Point at an existing cluster or spin up a dedicated instance.

It's built in Rust, so it's fast under load and frugal with resources. Detailed, structured logs are built in so your SREs aren't flying blind.

### Tooling you'll actually use

Endpoints are necessary; **tooling** is what keeps you sane. BYO comes with:

- A **focused dashboard** for support and security workflows.
- **Structured JSON audit logs** for every action - who, what, when, where, why - ready to ship to your log pipeline.
- Everything you can do in the dashboard, you can also do **via API**, so you can update your internal tools if you don't want to use ours.

### Clean, easy-to-use SDKs

I know, I know, every devtool ever says they are easy to use. Instead of telling you, I'd like to show you one code snippet, annotated with the important design decisions:

```ts
// Each method is a single, focused action, scoped to a single feature.
const result = await auth.sso.completeOidcLogin({
    stateFromCookie: req.cookies["stateFromCookie"],

    // Normally, you'd parse the query params and pass them in
    // But why can't we just do it for you by taking the whole URL?
    callbackPathAndQueryParams: req.url,
});

// Every method returns a Rust-like Result type, so you get explicitly typed
// success and error states to handle.
if (result.ok) {
    // result.data is well-typed and documented
} else if (result.error.type === "LoginBlockedByEmailAllowlist") {
    // Each function has a set of error types that you can handle
    // They are both in the docs and will auto-complete in your IDE
    // Note: We do this differently for each language, to match conventions
}
```

### Add only what you need, when you need it

Each feature is designed to work independently, so you can pick and choose what you want to add.

If you only need better session management, you shouldn't need to adopt a different permissions model to get it.

## When should you actually migrate?

There are still good reasons to replace your auth:

- You're early-stage and don't have a reliable foundation yet.
- You actively dislike your current system and want to hand off operations.
- You need an all-in-one platform with opinionated flows and you're okay adopting its model.

If that's you, migrate. Otherwise, you don't have to.

## For everything else, there's BYO

Keep what works. Add what's missing. Give customers the features they ask for - without moving your users, rewriting your login, or freezing your roadmap.

**Don't migrate your auth. Enhance it.**


PropelAuth Blog

Topics

Don't migrate your auth. Enhance it.

Join the conversation