Keycloak’s total cost of ownership extends well beyond licensing. This webinar breaks down the infrastructure, training, maintenance, implementation, and developer-time costs that determine what Keycloak actually costs to run. It also shows where FusionAuth reduces that burden, where Keycloak remains the better fit, and how to make the decision using your team’s real constraints instead of a feature checklist.
.png)
%20(1).png)
Hello. Thanks for joining us. We're going to give people a couple more minutes to file in here, so take your time, grab yourself a drink, get comfy, and we will get started in about two minutes.
Alrighty. I think that is enough time to let people come on in and get themselves comfortable. So welcome — we are happy to have you join us today.
I'm Brad. I'm going to be walking you through a strategic framework for choosing between two highly popular authentication platforms in the market today: Keycloak and FusionAuth. I promise, however, it's not going to be a sales pitch. We're going to give you the real data and framework that you need to make those decisions, even if that decision is to not use FusionAuth.
We're going to cover total cost of ownership and developer experience, and most importantly, hopefully help you understand when each platform makes sense. I lead product marketing here at FusionAuth, and I can hear your collective groan because I know how much devs love being marketed to. But here's the thing — part of the reason that I love working for FusionAuth is that they've never asked me to BS anybody, and I get to work alongside our product team. So I have a very realistic view of what FusionAuth does and doesn't do well. I like to think of my job as simply being a giver — I'm here to give information to help people make a decision based upon that information.
I'm joined today by Dan Moore, our principal product engineer here at FusionAuth. He's going to help answer any technical questions, and hopefully he'll call me out if I say something that's wrong. Dan, can you give the folks some background about yourself and what you do here?
Thanks, Brad. I'm looking forward to this, and I do want to echo that. Obviously we work with FusionAuth — that's just how it is — but we really want you all to make the right decision for you. I definitely have been on sales calls and had conversations with devs where FusionAuth wasn't a great fit, so we want to give you the tools and the framework to pick the right thing.
As far as what I do: I'm a principal product engineer at FusionAuth. I've been here for about five years, worn a lot of hats, talked to a lot of customers and a lot of developers about their authentication needs. I'm looking forward to any questions or discussions we have around Keycloak and FusionAuth and the complexities of choosing between them in this webinar. So thanks for having me.
I'm going to cross my fingers that this poll works, because I had to use a third-party tool for it and we're going to see. I would love to understand who's in the audience today, so we've got a quick poll running. Take a moment and select your current auth situation — it'll help me tailor the discussion to what's most relevant to you. If the QR code or the URL doesn't work, feel free to toss it into the chat and we can talk about it there as well.
I'm hopeful we can see a good mix of people from different stages in their auth journey, because my goal is to make this framework and discussion valuable for you whether you're migrating from a homegrown solution, comparing vendors, or maybe you're using FusionAuth right now and wondering why. It doesn't look like my poll came up, unfortunately. I'm going to guess that a lot of people in the webinar today are probably looking at homegrown and custom auth solutions. That's something we hear more often than not — people who have either built those systems already and are questioning their long-term viability, or who are considering building them and trying to decide whether that's the right choice.
So here's what I'm hoping we'll accomplish in the next few minutes. First, I'm going to give you a strategic framework that you can take back to your team and use immediately. Second, we're going to dive deep into total cost of ownership — and I mean the real costs, not just what's on a pricing page. Though we try to keep our pricing as transparent as possible, there are opportunity costs involved with every decision you make. Third, I'm going to share some actual implementation timelines and stories from real customers. And finally, hopefully give you a clear decision matrix to determine which platform fits your specific needs. By the end, you should have everything you need to make a decision and a confident recommendation to your team and leadership. Thanks, Dan — Dan is in the chat backing me up. If you'd like to join the poll, we'd love to go back and take a better look at the results after the event as well.
Brad, what about questions? Do people submit them via the Q&A, do they drop them in chat — what's the right way for people to get questions answered?
Any of those works. If you can keep an eye on the chat with me, Dan — for the most part I'd hope people will submit questions whenever they come up through the discussion, but we'll have dedicated Q&A time at the end as well.
So, the authentication decision matrix. We're going to start with why the decision is so critical, because auth is no longer just a technical checkbox. It impacts everything from your security posture to how fast your devs can ship features. We've seen teams spend months building out custom auth only to realize they need to rebuild it when compliance requirements hit. Others choose a platform that looks great on paper but requires so much operational overhead that it actually slows down their development cycle. Today's reality is that homegrown auth is often becoming a liability for teams.
So why is it still such a popular option? First, there's the age-old question we see pretty much every time somebody talks about authentication on Hacker News: "Well, how hard can it be?" And oftentimes people end up answering that question for themselves not too much further down the line, when a big security breach happens. But beyond that question, there are also framework defaults — "I'm already building in Django, why do I want to use something else?" There's a desire for control, especially in today's markets where data repatriation is an increasingly popular topic, and of course cost avoidance: "I don't want to pay a licensing fee." The reality, unfortunately, is that there's a lot of complexity and technical debt, and business pressures like lost deals due to a lack of compliance support, security incidents, scaling issues, GDPR, and other compliance problems — all of those can make homegrown authentication a very hard problem to solve. And that's not to mention maintenance: patching together multiple libraries — one for OAuth, one for passkeys, another for SAML — every piece of that builds operational overhead, and every bit of overhead removes developer productivity.
I want to set the stage for this talk by describing our typical FusionAuth audience. We've got developers of every flavor who use FusionAuth, but generally speaking, the people coming in and talking to us are making decisions at the engineering leader or senior engineering manager level. They're juggling multiple priorities — they need to deliver features that drive revenue while managing technical migrations. They're going deeper than just feature lists; they want to know about total operational burden. They're asking questions like: can their team actually implement and maintain this? Will it slow down the CI/CD pipeline? What happens when they need support at 2:00 in the morning? Those are the real questions we keep running into, and that's the lens I want to use for today's discussion.
So we've taken a close look at FusionAuth customers and the people who are often weighing FusionAuth against an open source option. In most cases, the choice to move away from open source — whether they've already built on it or are just deciding about it — comes down to total cost of ownership. I'm going to start with the number, because it gets everyone's attention. We did a comprehensive three-year TCO analysis and found that Keycloak, in many cases, costs over $300,000 on an enterprise-level deployment compared to about $103,000 with FusionAuth. $212,000 is not a small difference over three years. I know Keycloak is open source and free — you're right about the licensing aspect of that — but the operational costs tell a very different story. The analysis digs into infrastructure, training, maintenance, and developer productivity impacts.
To keep things fair, we looked at a Keycloak deployment handling around 40 logins per second and compared it to a FusionAuth instance of the same capability. Here's where the costs actually come from: Keycloak requires a three-node cluster for production use — that's three times the infrastructure right off the bat. But the bigger cost is human time. We've tracked that developers need forty or more hours to become production-ready with Keycloak versus around four hours with FusionAuth. It really comes down to complexity differences — Keycloak has a steeper learning curve, more concepts to master, and a significant maintenance burden. We're seeing stories of teams regularly spending three-plus hours every week managing their Keycloak instance, compared to thirty minutes to an hour with FusionAuth. When you multiply that across three years, those numbers add up fast.
Breaking it down by category: infrastructure-wise, you're looking at about a 60% savings with FusionAuth due to simpler deployment requirements. You don't have to have a three-node setup — you could run it on pretty bare-bones hardware and still see solid performance. Training costs are really significant too.
Sorry — not that we recommend running it in the back of your closet. That's a hypothetical, but your point about different levels of infrastructure requirements is a good one. And I think it's worth noting: Brad is doing a great job of outlining a generic case. We can always recommend: download FusionAuth, download Keycloak, and run your own scenario too. Everyone's use case is slightly different, and that's one of the reasons we have a free community edition you can download right now without talking to anybody — you don't need to talk to me, you don't need to talk to Brad. You can go download it, run it in your Kubernetes cluster or on your EC2 instance, and actually see the performance in your own environment with your own needs. Just wanted to add that context.
And if you don't even want to download it, you can play with it in our sandbox at fusionauth.io/sandbox. We reset it every day, but you can go and play around, look at the admin interface, and get a feel for things with no investment at that point.
Talking about investment — training costs are a dramatic part of it. When you're paying a developer their full blended cost, including salary, benefits, and so on, you're looking at around $150 an hour. Thirty-six hours of training at $150 an hour is $5,000 per dev. And then there's the ongoing operations gap — about two and a half hours saved per week. If you're spending three hours with Keycloak versus half an hour with FusionAuth, that's two and a half hours saved every week, about 130 hours per year, roughly $19,000 of developer time annually. The productivity impact is the thing a lot of people miss. I've been going back and listening to calls with our solutions engineering team, and when auth is simple to work with, developers ship things faster. When it's complex, it becomes a bottleneck, and that slows down your entire development cycle.
Sorry, Brad — just want to chime in real quick. When you talk about developers in the TCO, that's obviously important, and you gave the $150 an hour figure. In your experience, when someone's implementing authentication, is it "hey intern, go ahead and implement authentication" — or is it something a more senior engineer needs to be involved in?
We've seen different use cases. The people asking about the learning curve are often ones who have a mix of senior and junior engineers and need something that's not going to become a bottleneck. Without harping on Keycloak, it can do really complex things. FusionAuth, because of how it was built, should feel familiar and relatively simple in many use cases. We try to keep our docs cohesive and readily available, and we even extend that thinking to terminology — using "applications" instead of "clients," for example. Does that speak to the point?
I think that's helpful. Thank you.
So we've talked about the money side, and that's a big part of the story. Using Keycloak is complex — as a matter of fact, one thing I saw recently was a developer saying that the testing framework was "too complicated to use." Let's dive into what things actually look like when your team starts implementing these platforms.
With Keycloak, you're looking at a two-to-four-week journey minimum to get things up and running, and that's before migrations. The first one to two weeks are really just the learning curve — understanding realms and clients and identity providers and the admin interface. Then you're going to spend another couple of weeks on configuration, which can also be pretty complex.
Our goal with FusionAuth is to get teams running faster — we want your "oh, this makes sense" moment to come as quickly as possible. We've actually seen teams get things up and running in a day with Kickstart automation. Even for more complex deployments, you're typically looking at two, maybe three or four weeks. Does that sound about right, Dan?
Yeah, I do want to always be clear that different complexities are going to take different timelines. But we definitely see people move fast — I've seen people migrate from a provider in about a week when they had external pressures and were working on it full-time. One thing I do want to mention: Kickstart is something people might not be familiar with. Do you want to dig into that a little bit?
That's really your ballgame. You've worked with our Kickstarts a lot and have more experience there than I do, so go for it.
Let me give a quick overview. We have two related pieces of documentation. The first is what we call Quick Starts. These are for the developer who says: I'm a Django developer, I'm a Rails developer, I'm a Java developer — how do I integrate FusionAuth with my application? They're very technology-specific and cover lots of web frameworks, mobile apps, and even APIs. If you're a Go developer just working with an API, there's a Quick Start for how to use FusionAuth to generate access tokens to protect that API.
Kickstart is different. It's a technology you can think of as almost a write-only Terraform. It's a way to configure a FusionAuth instance — you can install a license, create users, create applications, register users for applications, do all the setup — and you do it in a JSON file that can be checked into Git, versioned, and used to set up new developer environments quickly. Our Quick Starts use Kickstart.
The important thing to understand about Kickstart is that it's write-only — it's a one-time thing that sets up a developer machine or a CI/CD instance to a known state. It's not something you'd run in production because it doesn't apply changes going forward. It really is a dev-focused tool to help you and your team get up to speed quickly. You might write a Kickstart that has all the configuration in it, and when a new team member comes on you can say, "here's this JSON file" — it will set FusionAuth up exactly the way you want it, alongside the rest of your application. That's Kickstart and Quick Start. Sorry for the rhyming.
That's great — I appreciate the deeper discussion there. Terraform is part of this discussion as well, right?
Yeah. We basically have three ways to configure production instances. The first is you can use any of our SDKs, which support all of our APIs, and do all the configuration in Python, Java, JavaScript, Ruby, PHP, .NET Core and Go. The second is Terraform — we have a Terraform provider, and both Keycloak and FusionAuth have them. I think ours is perhaps a little more cohesive, reflecting the single company behind FusionAuth versus the community-driven nature of Keycloak.
Terraform is great for production deployments because you want to treat your configuration like code. Just like you'd track changes to your database configuration or network infrastructure, your authentication server is a core component of your application. If you'd track changes to your queue system — your JMS, SQS, or whatever you use — you want to do the same for your auth provider for things like application configuration or tenant configuration. You obviously wouldn't track a user being added the same way you wouldn't track a message being added to a queue or a row being added to a database, but the larger application configuration of these core components is something you want to leverage Terraform for.
The third option, which is great for just testing, is to use the UI directly, like Brad mentioned with the sandbox. That's great for exploring, learning, and seeing new functionality, but for production or CI/CD instances we recommend one of the other two options.
One thing that came up in a conversation with our solutions engineers that I thought was a neat way to put it: we do have an admin UI, and you can think of it almost as a proof of concept, because that entire admin UI is built on our APIs. You can build something yourself that is equal to or better than that. As Dan said, in a CI/CD context that's not the way forward, but it is a great way to jump in, get a feel for how things work, and start to see the architecture face to face.
I do want to say — this is a bit of a sneak peek for everyone on the webinar — our admin UI is not the most beautiful. A little birdie told me it's going to get more beautiful, and I'll say no more about that.
I make no promises on timelines, but yes, I've heard the same. A lot of what Dan was talking about there gets at the developer experience gap. Keycloak was built with an admin-first mindset, where APIs often reflect the complexity of the admin interface. FusionAuth was built API-first, which means cleaner, more intuitive endpoints for the things you're going to be working with on a regular basis. We have automated examples and clear testing patterns out of the box.
If you're using modern frameworks like React or Angular, there's a good chance you're going to hit CORS issues in Keycloak that require workarounds. Day one might be a simple API call, day two is a quest through configuration, and then by day three it's working but staging has new issues. Suddenly you've got a $150-an-hour dev spending three days on configuration, becoming an auth expert instead of a domain expert for your product. Just less than ideal.
One thing I wanted to share: a developer implementing FusionAuth described it as "the petrichor of APIs" — having a proper "API mouthfeel." We're not perfect, but we pride ourselves on our API-first approach. What we really want is for you, once you've spent time getting up to speed with the first API call, to find that the next API call looks exactly like the previous one. We spend a lot of time thinking about how to name things, using the same verbs over and over, having a consistent error framework — all that cohesiveness leads to a great developer experience.
Unfortunately, you can listen to us talk about this and it's hard to understand until you've experienced it. That's the kind of thing you only discover after you've implemented something in anger — after you've really built something with it. But it is a design goal of the engineering team and of the product itself.
I always want to be careful when we're talking about other open source projects. We have a big heart for open source — a number of our developers have their own projects out there or contribute to others, and a big part of FusionAuth's foundation is built on open source. This is definitely not bagging on the open source world. Building on standards is something that's critically important to us.
On upgrades and day-to-day operations: when upgrades require coordination because you've got a multi-node setup, you're looking at planned downtime windows of fifteen, twenty, or thirty minutes. FusionAuth supports rolling upgrades, so you can upgrade with minimal downtime.
Performance is a really big differentiator as well. Keycloak shows significant performance degradation beyond about 200 realms — there are lots of stories about this at different hardware levels. Even when you look at the number of nodes being thrown at an instance, degradation still ends up being a common topic of conversation when people get deeper into Keycloak. FusionAuth's goal is to maintain consistent performance as you scale.
Documentation quality is another big deal. With Keycloak — especially now that it falls under Red Hat — the documentation can be fragmented and inconsistent. I've seen developers having to go to Red Hat documentation to figure out what was going on with their Keycloak instance. We try to maintain cohesive, comprehensive docs, and we have entire staff whose job is specifically to keep them that way and make them better. These might seem like small differences, but when they compound into major productivity issues over time, they're not so small anymore.
Hey Brad, I want to chime in on a couple more things. First, on the upgrade situation: I think it's worth pointing out that both Keycloak and FusionAuth have gotten this right in terms of not forcing upgrades. When you run Keycloak yourself, or when you run FusionAuth yourself or let us run it for you, version upgrades are something you control. That's really important for a part of your system as critical as auth.
On documentation — the other audience for our docs now is AI and LLM agents reading and understanding them. And I think we've done a good job with that, both with our current documentation and with a forum that has over 4,000 questions asked and answered, which has been scraped by tools like ChatGPT.
And on the performance degradation after 200 realms — maybe everyone on this call knows exactly what a realm is, but just to clarify: a realm is what Keycloak calls a tenant, basically a group of users and applications that are isolated from each other. In a B2B SaaS environment where you're selling to 10 different companies, you don't want any commonality between those user bases — that's what you do with a realm. So if you only have one product with one set of users, that realm performance issue might not be a big deal for you. But if you're running a B2B SaaS with thousands of different companies that all have separate user bases, you absolutely want to understand the relative performance differences between FusionAuth and Keycloak. We're pretty confident you're going to find FusionAuth is superior in that particular scenario.
Good point about the realms — I had actually meant to leave myself a note to explain what a realm was and forgot.
I do want to be clear: Keycloak is a solid, enterprise-grade solution, and so is FusionAuth. We both handle core authentication requirements exceptionally well. We both provide multi-tenancy with proper data isolation. We both give you full customization control over the user experience and workflows. We can both be self-hosted and integrate well with CI/CD pipelines — though as Dan mentioned, we do have a more SaaS-like offering with FusionAuth Cloud, and even with that option you choose your own upgrade cycle. We never force you into a version update. Both Keycloak and FusionAuth offer enterprise features like SAML, OIDC, and advanced user management. If you're currently using either of these platforms successfully, great — you've chosen well. The differences we're discussing today are really more about operational efficiency and developer experience than core functionality. That said, there are some deeper capabilities where each platform differs, and that's where the "same but different" element comes into play.
The core differences really come down to philosophy. Keycloak's scaling model assumes you'll add more infrastructure as you grow — more nodes, more complexity. FusionAuth scales efficiently within your existing resources. That's not to say you'll never need to add infrastructure; as your business grows and gets wildly successful, you will need more at some point. But those additions will come later and be less severe than what you'd experience in most Keycloak setups.
Operationally, Keycloak is very configuration-heavy. It benefits from having someone on your team who isn't just DevOps, but DevOps with Keycloak-specific experience. The API-first approach FusionAuth uses makes operations more intuitive for general developers. Authentication is still a challenging domain — your day-one fresh-out-of-bootcamp dev probably isn't going to get it right away — but it doesn't take much longer, once someone has built an actual application, for them to understand how FusionAuth operates.
The support model is also fundamentally different. With Keycloak, you're relying on community support and hiring specialized consultants. With FusionAuth, you have the option of professional support from the team that built the software. When you're talking to our support team, oftentimes those are people who — when they're not supporting customers — are writing code and making things work better. We've got someone on our team whose entire job is to work directly with customers who have really complex setups, and that's just something you're not going to get with an open source project that doesn't have some sort of commercial backing.
I want to talk about some real customer outcomes. BettyBlocks is one of my favorites — they're running over 10,000 applications on FusionAuth. They're a low-code platform that serves primarily enterprise customers. They chose FusionAuth specifically for operational simplicity at scale. There's a great quote from them about the architecture: "it's not a patchwork, it's one product with very basic architecture that does one thing really right" — and that's something we pride ourselves on.
Another one — Dan, you actually talked to these folks — is Switchboard. Their initial migration plan was twelve months, and it came down to four months, migrating from a legacy auth system. Developer productivity was really the deciding factor. They were surprised to launch that migration with just one full-time engineer, light support from an infrastructure engineer, and support from one other full-stack developer. These are real-world conversations we have with people who are actually running on FusionAuth today.
Just a quick note on that Switchboard example, because it really shows the nuance. You might hear "twelve months down to four months" and think that's still a long time — but go read the story. They were moving from a relatively complex setup that included connections with other identity providers and other integrations. We're not here to paint a Pollyanna picture. If anyone comes to you and says "I guarantee your authentication migration will be simple," I'd encourage you to dig in, because authentication is simple until you start pulling things back — especially when you start talking about migrating users. The front door of your application is a core architectural component. You don't want to mess it up. So just to be clear: twelve months down to four months is an amazing decrease, and it was partly due to the nuance of their existing setup.
Four months is actually on the higher end of what we typically see with migrations. The final customer story I love to talk about is a company that migrated from a cloud-based SaaS provider because their costs were getting out of control. They had considered open source previously but knew the developer overhead was a nonstarter for them. They needed a flexible solution with full control but minimal operational overhead — and we like to think that's exactly what FusionAuth delivered. These aren't cherry-picked examples. They represent the typical experience we see from teams prioritizing operational efficiency, and these are stories you can go read on our blog right now with direct quotes throughout.
I also want to be really fair about when Keycloak makes sense, because it often does. If you need advanced federation capabilities or legacy protocols like WS-Fed that aren't commonly supported, Keycloak is going to make a lot of sense. If you have strong DevOps with existing Keycloak expertise, you can often overcome that operational complexity. If you have zero budget for licensing and can absorb the operational costs, Keycloak works. If you need to modify core authentication flows extensively, Keycloak's open-source nature gives you that flexibility. The key success factors are dedicated expertise and sufficient infrastructure resources. If you've got those, Keycloak can work really well — and it does work well for literally thousands of users.
However, there are times when FusionAuth is just going to be a better option. When developer productivity is a big priority and you want your team focused on building product features rather than fighting with auth infrastructure, Keycloak is probably not the best choice. FusionAuth makes sense when you have limited DevOps resources and need operational simplicity. If you're on a tight implementation timeline, FusionAuth's faster deployment is pretty crucial. When you need predictable support options from the team that built the software, FusionAuth delivers. And if resource efficiency matters — minimizing both infrastructure costs and human overhead — FusionAuth is designed for that. The key success factor is balancing full functionality with operational efficiency.
So let me take a minute to summarize the takeaways. First: total cost of ownership extends far beyond licensing, and operational costs tend to dominate those equations. Second: developer experience impacts long-term success — not just for your business, but for your authentication itself. Productivity gains compound over time, and so do productivity losses. Third: operational complexity scales with your organization. What's manageable today for a small team becomes a major burden as you grow. And finally: choose based on your team's actual strengths and constraints, not just feature requirements. As Dan has mentioned a few times, the right choice depends on your specific situation — there's no universal answer.
The real value comes from discussing your particular constraints and requirements. Dan is happy to dive into Q&A. Every use case is going to be different, and we're a little limited on how deep we can go into any one deployment scenario with about fifteen minutes left, but we'd love to talk through typical scenarios and how they've been handled.
One question that came in earlier: someone is building a B2B SaaS platform and needs to support multiple customer tenants with different authentication requirements. Dan, can you talk about how the platforms approach that configuration?
Yeah. As we've tried to keep fair, both Keycloak and FusionAuth have strong multi-tenant stories. You can see a little bit how Keycloak got there through evolution versus FusionAuth's more structured approach — and the Terraform provider is a good example. We talked earlier about configuration management and how important that is when you're rolling things out across thousands of tenants or realms. Both platforms support things like password rules, but FusionAuth's support is structured through the Terraform provider, whereas Keycloak's is more of a free-form string.
FusionAuth also recently rolled out a feature called universal applications, which lets you configure an application once inside FusionAuth and then deploy it across one to a thousand tenants. As far as I'm aware, there's no analogous feature in Keycloak.
Taking a step back on large tenant counts — sometimes you want to delegate control to the customer. Say I'm a B2B SaaS provider and I have a customer named Brad. Brad has his own customers. I want to let Brad manage his customers, do password resets, do other things — but obviously I don't want Brad viewing anyone else's customers. Both FusionAuth and Keycloak can absolutely handle this use case. Keycloak's solution is essentially to give you a more limited view of the admin UI — it works, though I'd say it's a bit cumbersome. FusionAuth has a separate UI that gives the customer — in this case Brad — control over their own users, without them ever seeing the main admin UI. Different approaches, both solve the problem, just different sets of trade-offs.
That's a great way to put it. Another comment that came in was about migrating away from either Keycloak or FusionAuth — vendor lock-in is a big concern these days. Can you talk about what that looks like if someone needs to move away from FusionAuth?
Sure. I think thinking about how you're going to leave a service before you engage with it is always important. I've been a dev — you're under pressure to solve a problem, you visit Google, look at the top three solutions, maybe ask ChatGPT, and pick. And it's even more important to think about this when it's not just data or functionality at stake, but your actual user profile data — the thing that makes your application really valuable.
Both Keycloak and FusionAuth have gotten this right. By being able to self-host, or in FusionAuth's case even when you host with us, we will never hold your data hostage. As soon as you decide FusionAuth isn't for you, we do an out-of-band secure data transfer — it's your data, we're never going to hold it hostage.
In that way they're very similar. The full nuts and bolts of migration complexity does depend on what your integration looks like. There are some things common in any case — like, can you get access to users' passwords in a hashed format? Never in clear text, but can you get those hashed passwords? Both solutions give you that option.
We actually have a doc about migration from Keycloak that we can drop in the chat. The first quarter of it is about migration planning in general, so if you're on Keycloak right now and thinking about moving to any other solution, reading that first section will be helpful for thinking through what kind of migration you're looking at and what you need to consider beyond just users — including other configuration.
We also have a doc about leaving FusionAuth. I'm super proud of that one because I never want someone to stay on FusionAuth just because their data's there. That would be a disservice to our customers, and publishing it is a testament to the confidence we have in our product — even though we want to keep customers, we do right by them. We've had people leave FusionAuth and that was absolutely the right choice for them: their business was winding down, they got acquired, whatever the situation. We want to do right by you, the customer. Our ethos is that it's way better to let a customer leave, give them their data — which is theirs, by the way; we're only holding it in custody — and wish them well, than to make migration so difficult that they keep paying us out of frustration. That's something we've seen from some other providers, unfortunately. Not Keycloak, though. Not Keycloak.
No. That is one of the advantages of open source — you own all your data. Dan, there was one other question. You talked a bit about docs, and I think that's really important. Someone asked about documentation quality and community support. When developers get stuck at 2AM during a critical deployment, how confident can they be they'll find answers quickly?
Let's talk about this for both. For Keycloak, your options are in-house expertise or having a contractor or consultant on speed dial. That may be a very viable solution for you. For FusionAuth, depending on the license you buy — I'm not going to pretend everyone gets the same level of support — we try to meet everyone where they're at. That ranges from the forum I mentioned earlier, which is monitored by both the community and FusionAuth employees, to a ticketing system, to — if you have a highly critical application and want to purchase that level of support — a direct phone line. We call it the bat phone internally, which is kind of a funny name, but that goes to an engineer 24 hours a day, 7 days a week, 365 days a year. Our pricing is transparent — that's not free — but it's a 100% available option, and if it's the right one for you, we're happy to discuss it.
On docs: I think it's a tale of two options. Keycloak has a great feature set and can meet your needs in certain places, but with open source, people often want to spend more time writing code and solving problems than writing docs. That's not to say Keycloak's docs aren't there, but they have caused some frustration — we've seen threads and conversations about that. FusionAuth docs, while not perfect, represent a huge collective investment in time. We've spent a lot of effort making sure links are active, making sure new functionality gets documented across the board. And it's not just technical writers or documentation engineers who own the docs — our engineers actually write documentation too, and I think that's a differentiator. It leads to a more cohesive documentation experience. I'm not going to claim our documentation is perfect, just like I won't claim our code is perfect, but we really do invest heavily in making it a great experience for people trying to understand a relatively complicated, high-stakes architectural component.
We don't want to do vendor lock-in, but we also understand that authentication is hard and people don't want to keep dealing with it. We see some competitors in the market — mostly in the SaaS space — whose answer is to make it such a pain to leave that you just keep paying. I don't think that's the way forward for a business long term. And I think the fact that we don't have multiple billions of dollars in acquisition fees that we need to justify somehow works in our favor there.
So here are your next steps for continuing evaluation. If you're leaning toward Keycloak: dive into the documentation, consider professional services for implementation — you're likely going to need that expertise, to be completely honest about it. If FusionAuth looks promising: start with the free trial or the developer sandbox. We have migration guides, implementation support, and professional services available if you need them. Most importantly, use the decision framework we've talked about today with your specific scenario — that's critically important, as Dan has mentioned a few times. Run those TCO calculations with your own numbers. Evaluate the platforms against your real use case. Consider proof-of-concept implementations before making a final decision.
Feel free to reach out to me directly if you have follow-up questions. I may not know all the answers — I guarantee I won't — but I know someone who does. My email is simply brad@fusionauth.io. Thanks, Dan. We're always more than happy to answer those questions or point you to a resource where someone else has already asked them, so you can see the full context of the discussion around them. Thanks to all of you for showing up today and giving us your time. A recording of this will be available on the FusionAuth website under on-demand webinars. Dan, anything else to finish up with?
First, thank you everyone for your time — really appreciate it. And thank you for the great questions. We are an engineering-based company and we understand there's no one-size-fits-all solution. We really appreciate the chance to educate you on what we've found about these two great solutions. Thank you.
Great. Well, thank you again for taking time with us today. We'll hopefully see you soon. Feel free to browse the website — the /download page is a great place to get started, or we have a /get-started page where you can self-select and figure out what option is best for you. That'll do it for us. Thanks again, and we'll talk to you soon.
