Self-Hosted Auth vs. Managed Identity Providers: A GDPR-Focused Comparison
A practical comparison of self-hosted and managed authentication for teams that need to keep user data under their own control.
Every API ends up needing authentication, and every team eventually asks the same question: build it, self-host something, or hand it to a managed provider?
What “managed” actually means
A managed identity provider runs your authentication for you: user records, sessions, and tokens all live on infrastructure you don’t control. That’s convenient until it isn’t: your users’ personal data now sits with a third party, subject to their retention policies, their breach history, and their jurisdiction.
For teams operating under GDPR, that last point matters more than it first appears. A “right to be forgotten” request against your own database is a delete statement. Against a managed provider’s, it’s a support ticket and a trust exercise.
What self-hosting actually costs
The traditional objection to self-hosting auth is operational burden: account lockout, rate limiting, token rotation, password reset flows, all things a managed provider hands you for free. That objection holds for auth you build yourself from scratch. It doesn’t hold for a self-hosted service that already implements those pieces and just needs to run.
The comparison that actually matters
| Managed provider | Self-hosted service | |
|---|---|---|
| Data residency | Provider’s infrastructure | Yours |
| GDPR erasure | Support request | Direct control |
| Setup time | Minutes | Minutes, if the service is built for it |
| Ongoing operational cost | Subscription, scales with users | Infrastructure you already run |
| Vendor lock-in | High | None |
The gap that used to separate these two options (“fast to adopt” versus “you own your data”) only exists if the self-hosted option is hard to run. When it isn’t, the choice stops being a tradeoff.
When each makes sense
Managed providers still make sense for teams with no interest in operating any part of their own infrastructure, or for products where user identity data genuinely doesn’t carry regulatory weight.
Self-hosting makes sense the moment data residency, GDPR compliance, or vendor independence matter. And it makes more sense once the self-hosted option is itself just one more service your team registers with and delegates to, the same way you’d add a managed one.
Ready to stop building auth yourself?