For many teams, buying identity (or at least not running it from scratch) is the better call, because the real cost of running your own is engineering time and on-call ownership rather than the server bill. Building is the right call when identity is part of what you sell, or when you have specific control, data-residency or customization needs and a team that wants to own them. The honest way to decide is to count people and incident hours first, and compare vendor prices second.
This post is written so you can forward it to a CTO, a VP of Engineering or a founder. It lists what to check and what each side trades away, and it ends with seven questions you can answer in a sentence each.
Why is the question usually asked backwards?
Most teams start by comparing a vendor’s monthly price with their cloud bill for a self-hosted identity server, and the cloud bill looks small. That comparison is unfair to buying before it starts, because the largest cost of running identity yourself is the engineers who keep it patched, upgraded and available, and that cost does not appear on the infrastructure invoice.
A fairer starting point is to ask how many engineer-hours per month identity will take, who those engineers are, and what they would be building otherwise. Our deeper cost breakdowns are in self-hosted vs managed authentication cost and what it costs to self-host Keycloak, so this post links to those for the figures and sticks to the decision itself.
What does it actually cost to run your own identity system?
“Build” can mean two different things, and they carry very different risk. Writing your own login, session and token code is almost always a mistake, since authentication is a security-critical area where small errors become vulnerabilities. Running an established open-source server such as Keycloak yourself is a reasonable choice, and that is the version this section describes.
Engineering hours, not just infrastructure
Standing up a working Keycloak deployment is a matter of days for someone who has done it before. Keeping it healthy is the longer job. Keycloak ships regular minor releases and security fixes, so someone has to read release notes, test upgrades against your realms and themes, and roll them out. A cluster that serves customer logins also needs backups that have been restored at least once, monitoring, capacity planning and a tested failover path.
None of this is exotic, but it competes with product work for the same engineers, and it tends to be done in bursts when something forces it, such as a published vulnerability. For a team of a few engineers, even a fraction of one person’s time is a meaningful share of capacity.
The on-call and single point of failure question
If a login outage happens at 2 a.m. while the one engineer who built the setup is on holiday or has left the company, recovery can take much longer than anyone expects. Small teams often have exactly one person who understands the identity system, and the dependency tends to go unnoticed until that person is unavailable. If you decide to buy, the identity provider exit plan guide explains how to keep your options open.
Where building genuinely wins
It is worth being fair about the cases where running it yourself makes sense:
- You need the data to stay inside infrastructure you fully control.
- You have deep customization needs, such as unusual authentication flows or custom providers.
- You already have a platform or security team with spare capacity and identity experience.
- Your scale makes per-user vendor pricing painful and you have the staff to absorb the operations.
Our guide on whether self-hosting Keycloak is worth it goes through these cases in more detail.
What does buying trade away?
Buying is not free of cost, and a good decision names the trade openly.
Less control over timing and low-level configuration
A managed provider upgrades on its own schedule and exposes the settings it chooses to support. Deep customization may need a support conversation rather than a change to a config file, and some experimental features will not be available until the provider enables them. If your product depends on a very specific behavior, check that the provider supports it before you commit.
What you get back
You get engineering time back for the product, and much of the operational burden moves to the provider, though how fast they respond depends on the support terms of your plan, so check them. You also get a cost that is easier to forecast, though how predictable it is depends on the pricing model. Vendors that charge per monthly active user grow with your usage, while others charge by plan. Our Skycloak pricing is by plan rather than by user, and as with any vendor you should read the terms for your own situation.
There is a middle path as well: managed hosting of an open-source server. You keep the same software and the same exit options, and you hand off the operations. That also reduces lock-in, since your users, clients and realm configuration are in a standard format you can export. The vendor risk brief for CTOs explains how to evaluate that risk whichever vendor you pick.
A checklist to bring to the decision
Answer each of these in a sentence. A question you cannot answer is itself a gap to address.
- Who owns identity today? Name the person and their backup.
- What is the plan if they leave? Is there documentation, and has anyone else done an upgrade?
- What did the last incident cost in hours? Count the engineers, the delay to other work and any customer impact.
- What does enterprise-grade require for you? SSO, directory sync, audit logs, an uptime commitment and security evidence are the usual items, and each one has to be built or bought.
- What is the twelve-month cost either way? Include engineering time at a realistic loaded rate, plus infrastructure or vendor fees.
- What would you do if you had to leave? Check that you can export users and configuration.
- Which constraints are hard? Data residency, custom flows or contractual requirements may settle the question before cost matters.
What should you do next?
Run the checklist with the people who would be on call, put numbers on questions three and five, and decide whether any of the hard constraints in question seven apply. If none do and the numbers favor not running it yourself, shortlist managed options and ask each of them the questions in our ten-question list for IdP vendors about uptime, exports and support. If a hard constraint does apply, plan for the staffing needed to own it properly and write the on-call rota before you launch.
Frequently asked questions
Is it cheaper to build or buy identity management?
It depends on how you count. Infrastructure alone usually favors self-hosting, but once you include engineering time for upgrades, security patches, monitoring and on-call, the gap narrows and often reverses for small teams. Use the checklist above with your own numbers.
Should I write my own authentication code?
Almost never. Authentication has many subtle failure modes, and mature open-source servers and vendor services already handle them. Running an established product yourself is a different choice from writing the logic yourself.
What is the risk of vendor lock-in with a managed identity provider?
The main risks are proprietary configuration formats, user data you cannot export in usable form, and pricing that grows faster than your revenue. Choosing a provider built on an open-source standard and confirming the export path before you sign reduces all three.
When does self-hosting Keycloak make the most sense?
When you need full control over data location or behavior, and you have staff with identity and operations experience who can own upgrades, patching and availability.
How long does it take to switch later?
It varies with how many applications depend on the provider and how you store passwords and users, so plan for it as a project with a timeline, and keep your exit plan current. The earlier you ask the export question, the cheaper the answer is.