How is the release strategy planned?

[teawithfruit]

Hello Ory Team,

in your docs you're mentioning that it is better to use the stable docker images. This really makes sense to me.
https://www.ory.sh/docs/kratos/install#building-from-source

I don't wan't to stress or annoy you. But I ask myself how your release strategy is planned. The last update was in October 2024 and since then, there are many new features. Some of them are also created by the community (myself included with a small PR).

My question is when we could expect a new Kratos version?
Looking forward to it.

All in all, thanks for this open source product.
Thanks in advance for your reply.

[vinckr]

Hello @teawithfruit
Thanks for reaching out!
There are no guarantees given for when a release comes out, but the aim right now is to release 2-3 times per year.
There should be a release soon, basically when the Kratos maintainers find time to cut one - a lot of moving parts involved.

If you are using Ory Kratos in a commercial use case the recommendation would be to check out Ory Kratos Enterprise - this version of Ory Kratos has a much faster release cycle, 24/7 support, SAML, SLAs/SOC2, and proprietary features like B2B SSO.
Plus by becoming a customer you directly contribute to the long-term sustainability of the OSS project and your opinion has more weight in influencing the roadmap/direction of the project.

Feel free to reach out or contact me directly if you are interested.

[Micaso]

Hello @vinckr and Ory Team,

Thank you for the transparency regarding the release cadence and the target of 2-3 releases per year. That is helpful to know for our planning.

My main point of concern relates to the long-term health and commitment to the Open Source Software (OSS) version of Kratos.

Given that the last stable release was in October 2024—meaning it will soon be a full year—and considering the necessary focus on the Ory Enterprise License (OEL) version, this situation is personally worrying as an active user of the OSS project.

Simply put: Can the team offer high-level reassurance about the release plans for the OSS project, or has its development essentially been halted in favor of the OEL?

We value Kratos as a powerful, open-source tool and appreciate the team's ongoing work on the public repository.

Thanks for your reply in advance.

[vinckr]

Hello @teawithfruit

Ory has publicly and repeatedly affirmed its commitment to open source.
Open source remains at the core of Ory’s mission, and the Ory Network and Ory Enterprise License (OEL) are commercial offerings designed to fund and accelerate the development of Ory Open Source.

Regarding release cadence, it is true that OSS releases are less frequent than OEL releases. The current aim is to release at least once per year for the open-source version, but there are no hard guarantees on release dates.
This slower cadence is a matter of resource allocation and the complexity of managing releases, not an indication that OSS development has been halted. Community contributions are still welcomed and valued, and the roadmap is influenced by both open-source and commercial users.

If you need the latest features or faster release cycles for a mission-critical commercial use case, I recommend considering the various commercial options that Ory offers.

That being said there will be a new release in the coming weeks, follow this repo or https://changelog.ory.sh/

hope that answers your questions and also feel free to drop me an email if you want to chat about it - happy to listen to any ideas you have to improve the Ory open source community
🐝

[Micaso]

Hello @vinckr,

Thank you for the detailed response and for confirming Ory's continued commitment to open source, as well as the news about the release coming in the next few weeks—that is very encouraging!

However, I would like to gently push back on the "at least once per year" release cadence from a strategic user perspective.

The community that is most energized by and dependent on Ory's open-source projects includes Indie Hackers and small startups. We are building the next generation of applications on your OSS, with the very real dream of growing successful enough to become your paying Ory Network and OEL customers one day.

In the fast-moving world of IT, a one-year lag between stable releases is a significant barrier:

1. Stagnation Risk: It prevents us from leveraging new features and bug fixes crucial for modern development for a very long period.
2. Pipeline Risk: By creating this long gap, you are essentially discouraging the very user base that will form the backbone of your future commercial customers. We rely on a reasonably fresh OSS product to get our mission-critical applications to a stable point where we can then afford to buy the OEL for the guaranteed support and faster updates.

We fully respect that commercial offerings fund OSS development, but the current cadence risks damaging the pipeline from OSS user to OEL customer.

Thanks for taking the time to read and consider this perspective.

[aeneasr]

Hello @Micaso,

Thank you for taking the time to share such thoughtful feedback. We really value your perspective and we also agree with your point about the risks of long release cycles for the OSS community. That concern is very real, and we take it seriously.

At the same time, Ory as a company has to balance its open-source mission with the reality that we only exist if we have paying customers. That creates a difficult trade-off between what we make freely available and what we provide as part of a commercial offering. Our data shows that the median (!) Ory adopter, whether self-hosted or SaaS, can afford an enterprise plan easily. Our open source is primarily aimed at individuals, researchers, and smaller orgs in non-critical environments. The OSS software is reliable, secure, and scales well, but new features understandably appear more slowly than in the commercial versions.

The reason is simple: if we gave away everything, businesses would almost never pay, because the financial incentive always favors free. That in turn makes it impossible to pay engineers, fund development, and keep the project alive. Unfortunately, this is the structural reality for open-source companies. The industry has experimented with different models:
• going closed-source only
• restricting OSS features through OpenCore (often alienating contributors)
• relying purely on SaaS (less attractive now that many want on-prem installs)
• or even abandoning or relicensing projects altogether

None of those outcomes are what we imagine for Ory. Our goal is to build a long-term, sustainable, symbiotic relationship: OSS remains free for experimentation, learning, and non-critical use, but once a project becomes mission-critical in production, a commercial relationship makes sense. That not only reduces risk for the user (support, SLAs, compliance, faster releases), but also ensures Ory can keep investing in the open-source ecosystem instead of cutting it off.

We know this puts smaller teams in a tricky spot. That is why we generally recommend that startups and indie hackers avoid self-hosting and instead use the Ory Network production plan. It saves time and operational effort, always includes the newest features, and is relatively inexpensive. We also offer startup programs (for example for YC incubator, Insight Partners, Balderton teams) to make the entry even easier.

Looking ahead, we are exploring ways to better support organizations that fall between “hobbyist” and “enterprise.” For example, we are considering an Ory Business License that would be more accessible to smaller organizations, or optional add-on components that OSS users could pay for without committing to a full enterprise license. These ideas are still in an early phase, we need to learn more about what people actually find valuable, but the intent is to bridge the gap you highlighted. If we are successful we may consider moving to a different release cadence again, but it’s far in the future.

So to your main concern: development of Ory OSS has not been halted (just check the commit history!). Releases will continue, though on a slower cadence than the commercial channels. It is not perfect, and we acknowledge the risks, but it is the trade-off we have chosen to ensure Ory remains a healthy, long-lived project rather than one that burns out or abandons its open source roots.

Thanks again for pushing us on this, it is important feedback and helps us refine how we strike this balance.

[ericktollespark]

Okay, honestly, I think this is absurd because I know you need to make money, but one incredibly problematic thing is making our OSS systems vulnerable out of greed.

A CVE is a CVE, period. It is an emergency that puts companies at risk, and it should be released to everyone. We are not asking for more updates; we are only asking that when you find a CVE, you fix it as quickly as possible.

Our stacks depend on these systems, and if one part of the stack is vulnerable, especially authentication, which is already a sensitive area, then that is a serious problem.

Look at HashiCorp. They have the same model as you, but when CVEs come in, it is a red alert because thousands of people may be vulnerable. That is responsibility.

It is not responsible to put something as important as CVEs behind a paywall for whoever has the biggest wallet. That is irresponsible, and you should be ashamed of what you are doing.

[vinckr]

Hello @ericktollespark,

A few corrections, since your comment mixes factual claims with an accusation that doesn't hold up.

Exploitable CVEs in Ory software get fixed and shipped to OSS users fast. For example this March: a SQL injection via forged pagination tokens, patched and disclosed in Kratos OSS through the standard advisory process. Real vulnerabilities are rare, and when one lands the license you run doesn't change how fast a fix is shipped.

"A CVE is a CVE" is not accurate in practice. Most CVEs flagged against the community Docker images sit in transitive dependencies in code paths Ory does not execute. A JSON parsing CVE in a client library is not exploitable against a server that emits JSON. Those are scanner findings on inapplicable code paths, not exploitable bugs. If you have a specific vuln you believe is exploitable against Ory Kratos (or other Ory software), report it to security@ory.com and qualify for the bug bounty.

The Ory Enterprise License doesn't cover "the right to receive CVE patches." It covers the triage and remediation work: a defined SLA (critical within 14 days, high within 30), maintained images with clean scanner output, and a team that owns the per-finding assessment. That is paid work because it is work. Producing the same output for free on the community builds means asking a small team to subsidize compliance for organizations that can afford to pay.

On the HashiCorp comparison: HashiCorp's Community Edition is under the Business Source License, which is source-available, not open source, and restricts who can use their security patches.
Ory Kratos is Apache 2.0.
HashiCorp also doesn't backport CVE fixes to older Community releases; that is an Enterprise LTS feature.
On both license openness and CVE backports, Ory is more open, not less.

On "you should be ashamed": Ory has over a decade of unpaid maintainer work behind it.
Shaming the team for funding that work through a commercial offering is the attitude that makes serious open source work unsustainable. We reject it.
We will keep doing both: free fixes for real vulnerabilities in OSS, and paid support for organizations that need SLAs, compliance artifacts, and scanner triage.

If you can point to a specific unpatched, exploitable vulnerability in Ory OSS, report it. That is a conversation worth having.

I am locking the thread here; the points are on the table and further back-and-forth will not add more.
If you want to keep the conversation going with the Ory team and the rest of the community, join us in the Ory Community Slack.