If your product checks permissions through Oso Cloud, October 2026 gave you a decision you did not plan for. The Oso Cloud product and its customer contracts went to a holding company, the team that built it went to Temporal, and the open source oso library had already been deprecated for almost three years.
Nothing has to change tomorrow, but your next renewal is a natural point to ask who will build your authorization layer from here.
What happened to Oso Cloud in October 2026
Tiny acquired the assets of Oso Cloud and its customer base, with the deal closing on 1 October 2026. Tiny is a Canadian listed holding company that buys software businesses and keeps them running. Most of the Oso team, including its founder, joined Temporal to build authorization for AI agents into Temporal's platform, and a "small but dedicated team" is staying on to run Oso Cloud.
So Oso Cloud is not shutting down, and no end of life date has been published. What has changed is the roadmap. The people who designed Polar, Oso's policy language, and the engine behind it now work on a different product, and the new owner has not published plans for the next few years. For a component that every request in your application depends on, that is reason enough to look at the options before the next renewal.
Who needs an Oso alternative, and how urgently
Teams on Oso Cloud have a working product and time. The sensible move is to evaluate now, run an alternative beside Oso on real traffic, and make the call well before the contract renews, rather than wait for a pricing or support change to force it.
Teams on the open source oso library are in a different position. That library evaluated Polar inside your application process, and it has been deprecated since December 2023, so the trigger for you was the deprecation, not the acquisition. You are running authorization code that no longer gets feature work, and the longer it stays, the more application code grows around it.
Teams evaluating authorization for the first time who had Oso on their shortlist should weigh vendor continuity the way they would for any infrastructure dependency. A clean API matters less if the team behind it has moved on.
What to look for in an Oso alternative
Who maintains it, and is authorization their whole business. An authorization layer touches every request. Check that the vendor or project is actively maintained, ships security fixes, and treats authorization as its core product rather than a side feature.
Where your authorization data lives. Oso Cloud works from facts you copy into it and keep in sync. Some alternatives also store a copy of your relationships, others read data where it already lives at decision time. Fewer copies means less sync code and less drift to debug.
Where decisions run. A check that leaves your network adds latency and a dependency on the vendor's availability. A decision point that runs next to your application as a sidecar or service keeps checks local.
The policy format. Polar has a single implementation. Look for policies in a format your team can read in a pull request, test in CI and move between tools if you ever need to. Standards such as OpenID AuthZEN for the authorization API reduce lock in further.
How it handles relationships. If your Polar policies rely on relationships, such as "members of an organization can read its repositories", check how the alternative expresses them, and how it handles recursive ones such as nested folders.
List filtering. Most applications need "which records can this user see", not only "can this user see this record". Check how the alternative replaces Oso's list and list_local for your database and ORM.
Testing and audit evidence. You want policy tests that run in CI and block a bad change, and decision logs you keep, in your own systems, for as long as your audits require.
The migration path. SDKs for the languages you use, a way to translate Polar, and a way to run the new system beside Oso and compare decisions before you switch.
The main types of Oso alternative
Most options fall into one of four groups.
Relationship graph databases. Systems modeled on Google's Zanzibar paper store every relationship as a tuple and answer checks by walking the graph. They are the closest match to Oso's fact model, and they fit products whose core permission question is sharing through many hops, such as document trees with millions of edges. You still keep a second copy of your relationship data in sync, and attribute conditions are an addition to the relationship model rather than its core.
Policy decision points with attributes at request time. A stateless decision point evaluates readable policies against attributes your application sends, or that are fetched for it at decision time, and keeps no copy of your data. This is the model Cerbos uses. It fits applications with roles, ownership, organization and tenant rules, attribute conditions and audit requirements, which covers the organization, repository and ownership patterns most Polar policies are built on.
General purpose policy engines. Engines built for infrastructure policy, such as Kubernetes admission control and configuration checks, can be used for application authorization too. They are flexible, but application concepts like roles, resources and derived permissions have to be built on top, and their policy languages are designed for general rules rather than application permissions.
Building it yourself. Some teams consider going back to authorization in application code. It removes the vendor question and brings back everything Oso was bought to solve, from scattered checks to list filtering and audit logs. Our post on build vs buy authorization works through the cost.
Staying on Oso Cloud for now is also a legitimate choice, as long as it is an informed one with an exit plan.
Cerbos as an Oso alternative
Cerbos is an authorization management platform. Cerbos PDP, the policy decision point, runs in your infrastructure and decides each request from the attributes it receives. Cerbos Hub builds, tests and distributes policies to every decision point and collects the decision logs. Cerbos Synapse fetches attributes your application does not have to hand from your databases and services at decision time.
The platform handles more than 2 billion authorization checks a month, and authorization is the only thing the company builds.
For a team leaving Oso, these are the parts that carry over most directly:
Your data stays in your database
Oso Sync and Local Authorization configurations are lists of SQL queries against your own Postgres or MySQL. In Cerbos those queries become either attributes your application attaches to the request, or a Synapse SQL data source that runs them at decision time. There is no second copy of your authorization data, so there is no dual write and no sync job.
Polar concepts map to Cerbos policies
Each Polar resource block becomes a resource policy, Polar permissions become actions, and roles scoped to a resource, such as admin of one organization, become derived roles granted by a condition. Policies are YAML with conditions in Google's Common Expression Language, readable by the security and product people who review them.
Decisions run next to your application
Cerbos PDP runs as a sidecar, a service, a DaemonSet, serverless or embedded in the browser and at the edge, so a check never leaves your network and there is no fallback node to keep warm. If the control plane has to stay inside your network too, Cerbos Hub on premise runs there, including air gapped environments.
Tests, list filtering and audit logs carry over
Polar tests port to YAML test suites that run in CI and on every Hub build. list and list_local become query plans that adapters turn into filters for Prisma, Drizzle, Mongoose, Convex, SQLAlchemy or LangChain with ChromaDB. Every decision is written to audit logs in Hub, a file or Kafka, so the evidence stays in systems you control.
Every Oso SDK language is covered
Cerbos has SDKs for Go, Java, JavaScript, .NET, PHP, Python, Ruby and Rust, which covers every language Oso Cloud ships an SDK for, and it supports the AuthZEN standard API.
For a side by side breakdown of the two products, see Cerbos vs Oso.
When Cerbos is not the right Oso alternative
Cerbos resolves relationships as attributes. One or two hops, such as organization membership or team ownership, are a single condition, and recursive chains such as nested folders are resolved before the check with a recursive query and passed in as a list. That covers most application models.
If your product's core permission question is reachability through a large sharing graph, with many hops and millions of edges, a relationship graph database may fit that part of your model better, and it is better to know that before you start than halfway through.
Moving off Oso Cloud without a big bang cutover
Whichever alternative you choose, the safe pattern is the same. Inventory your Polar resource blocks and the facts each one reads. Translate one resource type and port its tests. Run the new system beside Oso on real traffic without enforcing its answer, log every disagreement, and fix the cause of each one. Cut that resource type over behind a feature flag once the disagreements stop, and repeat for the next.
Most of the work is in deciding where each fact comes from after Oso, not in the policy syntax. Our Oso to Cerbos migration guide covers each step with a worked example, including list filtering and the shadow comparison code.
Book a migration call and bring one of your Polar policies. We will model it in Cerbos with you and show the decisions side by side. If you would rather start on your own, try Cerbos to build and test your translated policies.
Go deeper:
FAQ
Tagged in
