Risky Business - Risky Biz Soap Box: Run your own open source IDP with Authentik

Episode Date: February 14, 2025

In this SoapBox edition of the show Patrick Gray chats to Fletcher Heisler, the CEO of open-source identity provider Authentik. The whole idea of Authentik is you can take control of an essential IT and security function: identity. Because Authentik is open source it’s extremely flexible, and if you’re running it yourself, you get to decide where your IDP should sit in your architecture. You can run it on prem if you’re an emergency call centre or you’re operating an airgapped network, or you can spin it up in your cloud environment if you’re a typical enterprise. Fletcher talks through the reasons Authentik users are decoupling themselves from the major SaaS Identity Providers, and the flexibility that comes from being able to assemble exactly what you need. This episode is also available on Youtube. Show notes

Hey everyone and welcome to another edition of the Risky Business Soapbox Podcast. My name's Patrick Gray. In these soapbox podcasts, everyone you hear in one of them paid to be here. They're sponsored podcasts, but you know, they're actually very interesting because we get to speak to interesting companies all about what they're doing, how they see the world, so on and so forth. And today we are joined by Fletcher Heisler of Authentic. Now Authentic is an open source based IDP.

So you can think of it in terms of like being similar to Okta, I guess, but you can run it on-prem. You can also get it, well, eventually I think you can get it as SaaS from Authentic themselves. But the idea is you can really take the reins of this thing, get under the hood, make a bunch of changes, only use the features you want, write new features if you want new features, so on and so forth. And Fletcher is the chief executive at Authentic, which as I say,

began life as an open source project. So he's not the founder or a co-founder of the open source project, but he's certainly a co-founder of the commercial side of things over at Authentic. Fletcher Heisler, thank you so much for joining us. Thank you, Patrick, for having me. Now, how did I go at the intro there, right? Like, because I often find I introduce a company and they'll cringe when I say it's sort of like

an open source octa or something. They'll say, no, it's completely different. Like, why don't you articulate to us like how you would describe authentic? That's a pretty good one lighter. And as you mentioned, they're kind of the two components there. So our founding CTO, Jens, started building Authentic, the open source project, nearly seven years ago.

And so as a full fledged IDP, it's had a long life. It's had hundreds of thousands of, you know, Home Lab users building up and contributing and giving their feedback across that community. Authentic Security, the company, was also formed as a public benefit company around Authentic, the project, a little over a couple years ago. And so we have that mission of maintaining, supporting, building upon that open source project while building up the enterprise side of our subscriptions, obviously support from the team. But then everything on top of that, that typically a HomeLab user doesn't need all the bells

and whistles of auditing and compliance or other specific integrations, but any company at scale with hundreds, thousands of users and beyond is going to need a little bit more beyond that standard IDP as well. So yes, we are right now focused on self-hosted. It is a standalone Docker or Kubernetes. You can run that in your own private cloud. We just released cloud formation templates, so a one-click deployment on AWS. And we'll be probably moving into sort of managed hosting and making that even easier for folks to stand up over time as well. All right. So we know Authentic is an IDP. We know it's based on open source. We know, you know, all of the things you've just told us.

But like, how is it different to the incumbent IDPs? Why is there a need for people to look outside? Because this is a mature product category, right? Like it's not like IDPs, you know, it's some race, startup race, right? Where everyone's getting their series A rounds and like trying to build out this thing. IDPs have been around for a long time. We're talking publicly listed,

multi-billion dollar companies. You know, why is it that we have you now stepping into what is an extremely mature product category? What's different that you're bringing to the table here? Sure. So we do have a little bit of a startup race going on the last couple of years in identity and in access. And I think that's because there are so many problems to solve. But as you're saying, what we're seeing is here is your windows onboarding for desktop auth or, you know, very, you or very smaller pieces that someone can bite off with a seed series A,

a small team and build on over a year or two. We're in the rare situation where we've been building out this full-fledged IDP from the ground up with security and customization and flexibility in mind over the number of years that it's taken to get all of the sort of standards, name your protocol, SCIM, LDAP, RADIUS, SAML, et cetera. All of that takes a whole lot of time to build an IDP. And obviously, there are not many, but a few very large incumbents that are in the space that is a very sticky one. So there's also a lot of cost to changing over your IDP.

So the difference for us is it's all a Django project under the hood. Everything is very configurable. And so as an end user, once you've been using more of a legacy provider with their own black box solution, the same sorts of things start happening over time. You're paying more for getting less. You have to pay extra for sort of the SSO tax, except it's API access or whatever other security mechanisms

you might need or want there. You're also spending a lot of engineering time building some duct tape widgets around those APIs to make them work with other integrations and applications. And so, you know, where someone might get you 80% of the way there, you end up building out so much extra infrastructure to manage on top. Something about that underlying system changes and then you're left in the dust. So we really let you customize as much as you'd like from the ground up with a very, very flexible solution that you own. So you can use Terraform

for everything. Everything you could do in Authentic, you know, in the UI is available over an API. You could even write your own custom expressions. So if you want to reach out with your own provider, you could do that directly in Authentic. And similarly, for a lot of big companies, they might have even multiple IDPs, or multiple systems and directories and sub-organizations that they need something to cohesively talk to. Within Authentic, we're very much sort of vendor agnostic,

protocol agnostic. You could, as an example, say, we're migrating sort of vendor agnostic, protocol agnostic. You could, as an example, say, we're migrating away from this legacy provider. Let's reach out to them dynamically as part of the authentic registration process. And so that's seamless for your users to be able to pipe that data in.

They don't see any difference. They don't have to take any other actions. You don't have any data zero, plug it in, and hope that it works. But similarly, if you need to access, say, a legacy application that doesn't even have SSO, you could do that through a reverse proxy through Authentic. So really, it's sort of the breadth and depth

of being able to use your IDP the way that makes sense for you and is much more manageable for these teams over time, that they can fully customize that to their needs. Yeah, I mean, I find the business opportunity here actually really interesting, right? And I forgot to disclose at the start of the podcast that I do have an advisory agreement with you guys, which means you do well, I do well, so it's good to be transparent about all of these things. But the obvious- We appreciate all the advice along the way. But all of these things. But you know, the obvious- I really appreciate all the advice along the way.

But all of the, you know, the interesting thing is here, right? You would think, well, this is a home lab sort of thing, right? Like started as a home lab sort of thing. So many people using it in their home lab. But when you really think about the most likely candidates to jump on board in a business context, it's the very large companies first who are going to be wanting to do this. Simply because, well, first of all, there's a cost reason there because the IDP tax at

a major enterprise is a very real budget item, right? This stuff is not cheap. So there's a budget reason, but then, yeah, again, there's that flexibility reason. So I'm guessing you would have already had some extremely large customers say, well, we're going to change this. So that's the thing. You can actually get in there and just say, oh, so many people using a major ADP.

Oh, god, we would solve so many problems if we could just make this one little change. But people with Authentic are able to actually make that change. So I guess this is all leading up to a question, which is what are the first sort of changes that people are making? What are the first little bits of tinkering that you see from very large enterprises?

So those earliest changes have already wrapped themselves up into features in authentic that other users can use as well. I think that's become kind of the natural progression that something might start as. That's the beauty of open source, right? Is someone says, I need to do this because it's useful and then it gets merged and everybody's got it. Yeah. Yeah. And I suppose application integrations are probably the most common. But we've also seen that with GOIP, for instance, setting policies to say, we expect this kind of team might be accessing for this kind of location. But if these folks do, we might want

to level that up with additional constraints. And that might start out as six lines of Python that you embed within Authentic, not even a code change, necessarily. But then we see that from customers and say, great, let's templatize that. Let's make that even easier as a best practice for someone else to adopt. Similarly, on the

application side, if you go out to our integrations page on our homepage right now, it's very B2C looking in that most of the community-driven stuff is, I want to use this with Discord or things like that. With our first major enterprise rollouts, Workday is probably a great example of with our first major enterprise rollouts. Workday is probably a great example of an API that is challenging for any software to work with usually. We didn't have a pre-built Workday integration, but we worked hand-in-hand with a customer,

built that out as some custom expressions and scripting for, I think it took under a week. And then again, we can leverage that with any future enterprise customers to say, yes, Authentic can work with that and we can make that easier in the future for everyone else to benefit from that effort as well. Well, it's interesting what you said about B2C, right?

Cause it's something that I haven't mentioned yet in setting all of this up is that, a huge use case is you've got that, what in the commercial space would be more that Auth0 piece, which is when people want to add proper authentication to a web application, whatever they can use Authentic to do that. And that stuff, again, very expensive

from the commercial providers. So being able to get that for free, I am completely unsurprised that that's a popular use case. But I just want to go back to this issue of features, when you're talking about, OK, you see a lot of people doing this sort of thing, so you merge it as a feature. This seems a good way to sort of prioritize what should

and should not be a feature. But I also imagine you see people doing stuff where you think that's either stupid or dangerous, and you decide not to merge it, right? So how do you actually make that, those decisions? Do you have any sort of formal processes in place where you evaluate and say, well, you know, some people want to, want to do this with our product over here, but we don't really

think they should be doing it. So we're not going to merge it. Cause you know, how do you stop that sort of enterprise software bloat from taking over the product? Yeah. Great question. And we routinely have these conversations internally. I would say for anyone, I think we're moving past the days of open source is scary just in general.

But I hope no one's picturing that we just accept all contributions from anybody and that gets merged in fine. We keep a very tight watch on what gets merged in and why. And we're really the ones, especially on the enterprise feature side, driving what that roadmap looks like. I think maybe the best example we've had where it's not a completely decided discussion yet, but we've had a couple of folks come in asking for SMS

as a primary factor. We never built that in because we thought it was a terrible idea from a security perspective. Well, and this is a pickle. This is a dilemma, this one, because there's actually a case for it, especially on the B2C side. There's definitely a case for it. Exactly. But you don't want people to be doing it. We've been presented with a couple scenarios of customers saying, here's why.

It's not quite the standard auth, but the risk factor is very, very low here. Here's why we might want that. And so there are a couple options there. We've started hiding things behind admin flags so that the folks in charge of the rollout can get all of the nasty warnings ahead of time of, you can turn this on, here's what might result.

Yeah. But there's always that discussion of, should we provide the footgun if there are a few legitimate use cases there? I think it's really just about providing that flexibility so that everyone can meet their needs, but also defaulting to having sane defaults and having awareness from the end user and the end admin of what the end result will be there. But I mean this is a great example of security, what I'd call security ideology

colliding with the real world, right? Where sometimes you're gonna have to pull the trigger on a feature that you, you know, as you described it, it might be a foot gun, but you have to do it. Yeah, yeah, and so it's about also providing sort of enough warning and enough context where the folks who need that can get to that. But you're not going to have someone, you know, mistakenly implementing something that's less than secure. Yeah. So look, why don't we just have a quick chat

about what sort of customers are actually using this at the moment? I understand there's some really interesting use cases. I think like emergency services call centers is one, because if they lose their link, they still need to be able to authenticate to their computers and things like that. People in Europe concerned about Americans buying and using

American vendors. Ironically enough, I think there's going to be traction among some of the agencies those people are scared about too, because they're running AirGap networks, which I think is quite ironic. But why don't you just walk us through where this is getting the early adopter traction? Yeah, you've gone down the list there. And I think there's a, maybe a fourth category

of folks who, as I kind of alluded to, are finding they're spending too many cycles building on top of their implementation of a standard legacy player. And they're ready to take a little bit more ownership of what that IDP looks like without having to build everything themselves as well. On the emergency services side, yeah, the Emergency Service Center for the state of Washington is using Authentic to add in biometrics. They have six or seven different ISPs, but when things are literally on fire, they can't necessarily guarantee a connection there.

So they need the ultimate in terms of resiliency and reliability. Authentic can even be run air-gapped on the healthcare side as well. You might have a case where you have two instances and you have sort of a fallback when internet connectivity goes out, but you want authentication and all of the systems that come along with that to still proceed as normal for however long is necessary there. And as you mentioned, also in Europe, Jens is based in Germany,

and a lot of our very initial customers and early adopters were folks like German cybersecurity companies. But really, any folks who don't want to be just handing all of their PII off to a US SaaS provider, you can now do that and still own your data while running your own identity product. We have extremely limited and optional telemetry there.

Again, can even be red her cap for folks in some more sensitive labs or agency type situations as well. Yeah, yeah, it's funny, right? So OK, so here's the thing that I, if I had the crystal ball, if I could ask the oracle sort of thing, the thing I would wonder about is where you're going to land in five years with regard to the business side of Authentic.

And the reason I say that is because, you know, a big selling point at the moment is on-prem. On-prem and control, right? So you can run it yourself, you can fiddle with it yourself, it's all within your control. But I think IDPs are SaaS business models for a reason, in that it's very easy to not have to worry about running that infrastructure and whatnot. So while you're capturing all of these people who

want the on-prem and stuff, you are spinning up a SaaS version of this. And I sort of wonder if at some point, you're going to become what you hate, which is you're going to become another you hate, right? Which is you're going to become another SaaS, you know, SaaS IDP. I don't know. I just wonder what your thoughts are in terms of like, well, first of all, you know, how's the SaaS stuff coming along? Because funnily enough, this was something that you were, you know, really putting a lot of effort into, but you've been so busy just servicing the demand for on-prem, it's like, it's less

of a rush at the moment. But yeah, so walk us through the journey to SaaS and how you expect that to wind up, because I'm real curious to see how that's going to go. So I was literally about to say the same phrase, and we don't want to just become what we're actively rallying against here. I think there's kind of a philosophical stance where we do think that folks should avoid vendor lock-in, should aim toward ownership, should et cetera, et cetera. But if the mission is to make authentication simple

for everyone, there is clearly a let us help you run that component. So we are not actively actually working on building out a SaaS solution right now, because again, we've had enough inbound interest, and that's continuing to grow. But to be clear, that was kind of the plan, right? And now it's like, well, we're so busy with this other stuff, that's just sort of backburned

a little bit. Was originally the plan. I think folks are more on board with on-prem or whatever version of on-prem you want to call it than we were expecting. Run it yourself. I mean, yeah, if it's in your AWS, like is it on-prem? No, but you were managing it yourself. I forget what you mean.

Right. It's much more typically run it in your own private cloud using the same tools and infrastructure that are running everything else in your own private cloud. And so it's much easier to talk to that than to talk to somebody else's SAS black box, uh, for teams that are large and capable enough there. There is an overhead, obviously, when it comes to your own containerization, you have your own database, what does high availability look like for you and so forth. So our focus right now is making that as easy as possible.

Things like the cloud formation template. Um, we have is making that as easy as possible. Things like the CloudFormation template, we have an AWS Marketplace offer now as well. So I think when we dip our toes in, it'll be more managed hosted of how can you still own your data, but we can help you set things up, configure things, and keep things up to date. If we're to offer SaaS, that would start out as, if you want to try this out, but we'd very much

like to graduate you to full ownership, if and when that makes sense as well. But what happens if they don't? What happens if they're just like, no, we're good? That's the question. Well, that's another ongoing conversation similar to SMS primary factor. So I think that's going to be somewhat,

let the customer choose their own adventure, but try to guide them towards what we think is the most responsible solution. I think the most important point to me is with IAM as a service, there are the reliability concerns, but even bigger is the sort of shared attack surface there. And I, you know, I recognize that that's a very big problem to solve when you are taking in all that information for all of those companies and being the single point of failure for them directly.

the single point of failure for them directly. One of the many nice parts about sort of on-prem is that you can lock things down as much as you need for your company specifically. You don't have to rely on us deciding what reasonable rules or what an attack looks like from our perspective on behalf of your company. So as much as we can, I would like to keep that separation. Everything that you're saying, it's like the people

who are gonna do a better job of that than like the majors, they're gonna be big enterprise, right? They're gonna have security teams, they're gonna have monitoring, all of that, right? So this really does look like it's, for the time being, targeted towards people who have specific requirements, like those call centers that need to operate offline, air gap networks, you know, sensitive lab, things like that,

and also very large enterprise, right? Like, it's unlikely to see, you know, a small to medium business that might have one IT person going off and spinning up their own IDP and Kubernetes. Defense, we've seen quite a few of those who go from the Home Lab to their SMB and decide, I'm already familiar with this. It's easy enough. But yeah, I see it as kind of, if there's a bell curve, we're attacking both ends there, where there might be some very specific use cases, regardless of team size, often quite

small sometimes. And there are some very large enterprises that have, you know, that ability and ownership to run things in a very complex environment and are looking to level it up from there. Well, I mean, that might be the bell curve in terms of users and people admitting it, but the money is very much concentrated up the right hand side of that bell curve, right? Which is the enterprise market. And speaking of, you alluded to this earlier, but Authentic makes money by selling sort of enterprise features around compliance modules and whatnot. Is that about right? And are there any features that you're offering

that you can't get from the majors in terms of like those compliancy, logging, et cetera, features? So yeah, on the enterprise side, it's things like Chrome Enterprise Browser Device Trust and things like that that you won't see at a OnLab user, but we've seen quite a few enterprises who rely on Chrome and all things Google for sort of that layer of trust, and they want to bring that into their IDP.

So that's one of a few examples of specific enterprise features. There's also enterprise support, obviously, that's included with that from our team, that we want to make sure that it's a successful rollout for those very large complex environments. And also that's where we get, as I mentioned, a lot of our ongoing features.

So there might be a case where someone says, we are rolling this out, but we need, actually, as an example, application entitlements. That was our most recent very large rollout where application level folks wanted to be able to assign roles and groups and permissions, sort of like similar to a sale point kind of setup. Because of the flexibility of Authentic,

we were able to build that in in just a couple of weeks. That's maybe a many, many months project, if ever, for some more of the legacy players if they'd like to build that kind of flexible layer in. Yeah. I mean, one nice little feature that you've got, I don't know if the majors offer this, they might, but you can gate SSH access behind the IDP and serve it in a browser, which I

like. That's a cool little trick. I'm working with another company that does like gated access via whatever IDP you're using and they can do it via network controls or whatever. But yeah, essentially, proxying stuff through like a web enabled gateway. Is that popular? It is.

It's actually just as popular with our HomeLab users. And so we're looking at allowing that in the open source rather than just enterprise, because you can imagine someone who just wants to SSH or RDP into their remote box at a small scale. But then I'm sure there will be enterprise features on top of that if you want to say record sessions or something like that. That's probably something that more on the enterprise you'd be interested in as well. You doing that yet? A lot of the, not yet, but it's built in.

The pieces are there if we see the need from customers to do so. I mean, there's all of these companies that make stuff specifically for that, right? Like the one that springs to mind is like Strong DM. They're really good at that. Just having that box between you and your prod environment and doing all of the auditing and access control

and whatever. But I can imagine that for people who don't need to go necessarily the whole way, with that, something like this would be tremendously usable. And it would tick the box, basically. And to your earlier question of what can't you do with other IDPs, because there are broad strokes. You can compare similar features and functionality across any major IDP and we help check those boxes too. I think it's the additional levels of flexibility and access and customization. So as an example, if you

are enrolling employees with Yubikeys, you can actually check that ID and ensure that that is a secure Yubikey. It's a particular version essentially that's not something that if you want to ensure further security, all of the data is available to you essentially. So that's one piece where we've built it in as sort of a templated feature. But there are many others where all the data is available to you. Let's say you wanted to use, with the GOIP example,

any other customer metadata. Maybe it's even coming from another identity provider. We don't have any qualms about letting you do what you'd like with that as an admin. So it's really just about that flexibility that's provided to allow you access to all that information in a way that makes sense for you and your team to use it appropriately. Now we've spoken about some of the positive features people have tried to bake into this. What about some of the worst ones that you've rejected? Have you got like a top three?

You should get Jensen here for that. I think he's probably got a long list of things we won't do. Let's see. I think what's happening more and more, there's kind of a marketing strategy of, you should integrate with our platform so that there's some awareness there. And so we get a lot of requests to work

with a particular hosting provider or work with a particular application that we've just never heard of. And we're looking to do that if a customer requests that from us. If a vendor comes to us without any proof points there, we might be a little more suspect of shoving that into the docs and the code and bloating things with something someone hasn't asked for actively

as an end user. I imagine there's a lot of managed service providers and whatnot who white label this too, right? For sure, yeah. And we see every now and again, we will see authentic login pages come up in unexpected places. And we just take it to the side of pride that we're glad to see our name out there. And we're certainly the ones who know the system the best.

And so I'm not too worried about anyone building on top. There's a reason this is open source. But we're happy to see what works the best and add on top as our customers and our community want us to. Yeah, I mean, I can't imagine that's a bad thing, right? Having MSPs do this because, yeah, it's more awareness. It's more authentic everywhere. And I mean, it's kind of like comes to the territory

of being open source. Definitely. Exactly. Now, Fletcher, one thing we're going to argue about now is the security benefits of open source because this is something that you wanted to talk about. The many eyes make bugs shallow. You know, substantiate that claim for me, please, because this has been a long-term

argument that I've had over the last 20 years where, you know, I think in my mind, having something be open source is great, but that doesn't necessarily motivate people to go forth and audit the code. How many eyes do you actually have on your code? You know, and what brought them there? For sure. Well, we get lots of our customers testing Authentics code directly, whether that's black box or white box. You know, you can actually see the code. And so they've done some code reviews as well.

We get our at least annual pen tests and we publish all of those results as well. And we, I think our fourth or fifth hire was on security ops, which is rather unusual for a startup. So we've been taking this pretty seriously as a matter of transparency and prioritization from the start. So that's what we could do on our side to sort of encourage that. By way of comparison, I would say

encryption is probably a good example. As a developer, would you use an encryption library that's been examined and out in the world, and you can take a look under the hood and see what it does and how it works for a number of years? Or would you go with the package that can only be examined by attackers, and you don't get to know how anything is done?

That sounds like madness, but to me, that's kind of the state of identity and access as an industry. Point of comparison, OctaNOS zero, these are both proprietary code bases that have been leaked on the Dart web. We as end consumers of them still don't get to know how things are secured unless a vulnerability is found

and then we get to know possibly about the change that was made. Rather than everything is open source and source available, you can see under the hood, you can see the decisions we've made over time, you can suggest changes, you can code review that yourself. That just seems like a no-brainer in terms of the approach to take for building a secure system out in the open. Probably the strongest part of your argument there is that you've had customers actually do code reviews.

And I can imagine that's absolutely true, given that you're in some pretty big environments. And if they're going to make the switch, they're going to want to throw some hours at it. I think that's my issue with that just general argument, that open source equals more secure, is that quite often you'll have a project just sitting around and everyone assumes someone else has looked at it, right?

And they haven't, but you know, if you are going into high security environments and very large enterprises that do have teams, they're going to actually spend a bit of time with it. Can you think of like, I imagine some of the early code reviews would have been sobering, right? They always are.

You know, Pien has been very careful in terms of building things out from the very ground up with security in mind. So it's not like we've never made any mistakes. We certainly have had plenty of CVEs, which again, we publish, we fix as quickly as we can. And I'm not pretending that we will make a bulletproof system from day zero. We've actually had a hard time finding really good pen testers. And so we had a pen test that essentially said,

we've come up empty, and we got a second one for the past year to really try to dig in there. Was this code review looking at your infrastructure or what was the scope of the task? It was both, yeah. But I think the code review in particular, to your point, open source doesn't guarantee more secure by default, but it does allow you to dive in and see how things

were done very specifically. And if your attackers are going to see that, then it seems like your end user should also be able to see that, examine it thoroughly. And we have had a lot of really good, even advice, not even necessarily security findings, but suggestions from customers of better ways to do things that we've implemented. I remember once an audit, a company I was working with years ago, they have a kernel driver, a Windows kernel driver, and they had that audited by a guy who's like a real specialist in that. And he didn't find any bugs, but he said, you should take this part here and move it into user space, because it doesn't need to be there You could do this and just a few architectural suggestions that they they acted on but sometimes that can be the most useful part of the

Process is just you know the the resulting advice which is there's nothing here, but that's because you got lucky One that was interesting Finding from our pen test which was a little bit of sloppiness on our part. The testers pointed out that we didn't have secure password requirements for our testing at staging server that they tested on. Again, this kind of goes to do you supply the footgun to the end user.

To us, there wasn't a big security concern with doing that. But the more that we thought about and talked about it, if we did that, our customers are probably doing that in more production sensitive environments too. And so besides just adding stronger passwords onto our testing environment, we turned that into we should have some better default policies that, you know, you really have to work around to be able to spin up Authentic without having secure passwords from day zero. Yeah, I mean, sensible defaults are good, right? But then there's the question. So, you know, you act on a finding like this, whether it's a CVE or a change to a default, you've got all

these customers running this stuff on prem. How do you then distribute fixes, configuration changes, and whatever? And because this is customizable, how do you do that in a way that's not going to break your customer deployments? Because I can totally see that you could give a customer a really bad day by shipping an update that's

fine for everybody else, but ruins their lives. So how do you manage all of that? It is a lot to manage. There's no quick easy answer besides we have a very long checklist and we try to be as careful as we can with any sort of breaking changes. You know we have pretty standard docs of here is how to upgrade authentic and still communicating ahead of time to our customers and their security teams, what to expect.

The nice part about open source is we also get a lot of early testing in. And so as soon as a feature is merged or technically even before then, we have a lot of folks out in the community who are alpha testing that. And so we can get ahead of a lot of those issues before, you know, officially hitting publish and say, good luck, everybody, roll it into your production environments and get back to us.

So, I mean, I guess the issue there is like just having a patch bump into a customization. But again, like having a hot site backup of your IDP, I can't imagine that's too difficult or expensive. So you could just have that thing sitting there, roll out the patch to the prod, and then if it goes sideways, you just cut over. Do most people run a dual setup like that? So Authentic itself is stateless.

And beyond that, in the background is Postgres for all of your backup data. And so on the enterprise side, that's high available Postgres. There's some replication. There's some offsite backups happening as well. And we've seen a lot of those configurations where we can make recommendations

depending on the particular use case. But I mean, I'm not just talking about the database here. I'm talking about all of the custom scripts and all of the little bits and bobs, all of the weird stuff people have done with it. I just would have thought it would make sense to have that mirrored on some other box, right? So you could do an upgrade,

and if things don't go well, you'd revert. Yeah. Yes, and that's all essentially those two components. There's the stateless authentic, and there's everything that gets stored in the database and called up from there. We do use Redis a little bit for sessions, but, you know, yes, that is essentially, you can pull that back from your backup along with all of the customizations you had in place. Yeah, without breaking anyone's sessions. Yeah, so I think the only other separate piece you might have there is you know maybe some terraform

scripts in terms of provisioning some some separate components there. Yeah, all right well Fletcher Heisler we're going to wrap it up there. Thank you so much for joining us to talk all about authentic and that's authentic with a K not a C and yeah anyone who wants to go and just spin it up and play with it They can I mean, you know, I'd imagine you do a lot of you know Like downloads just an insane amount of downloads of people spinning it up. So where can people find you? Yeah, millions and millions of them. They can go to our github. They can go to our site go authentic.io Or just search for authentic AUTHENTU-T-H-E-N-T-I-K. And I'm sure it will come up.

You can, as Patrick said, download it, get started locally right away. You don't have to sign up for anything. You could just run it in your own little Docker, Docker Compose, and then reach out if you want to scale up from there. All right. Well, we'll be talking to you a lot more through the year. Fletcher Heisler, thanks for joining us.

Thanks so much, Patrick.