Oso Cloud acquired by Tiny while most of its team joins Temporal, leaving users weighing a move

Oso Cloud has a new owner

Oso Cloud, the authorization service whose policies are written in the Polar language, has been acquired by Tiny, with the deal closing on Oct 1, according to a post on dev.to. The post says Oso has stated that the cloud product will keep operating normally, and that nothing in the announcement obliges customers to migrate right away. At the same time, most of the Oso team has taken roles at Temporal.

The dev.to post was written by a self-identified member of Permit's marketing team, and Permit sells a competing authorization product, so the migration advice comes with an obvious commercial interest. Even so, the procedural guidance is broadly applicable to anyone reconsidering an authorization vendor.

Why teams are re-reading their Polar policies

According to the author, many Oso users are revisiting their configurations this month in light of the acquisition. The step they tend to skip, the author argues, is the least glamorous one: exporting the existing Polar policies and classifying every rule before beginning vendor evaluations.

The suggested classification:

• Rules that assign roles within a resource block amount to RBAC.
• Roles that come from relationships between entities are ReBAC, for example a repository-reader role that a user holds only because they belong to a parent organization. Moving such a rule to another system also means migrating or continuously syncing the relationship data behind it.
• Conditions that inspect user or resource attributes are ABAC, and they force an architectural decision: attribute data can either be synchronized in advance or supplied with each authorization check.

List filtering, the author adds, deserves its own entry in the inventory. Answering whether one user can open one document and answering which documents a user can read stress an authorization system in different ways, and a replacement can handle the first while struggling with the second.

Parallel running before cutover

The post's final recommendation applies regardless of destination: keep the incumbent and the replacement running side by side for an extended period, log every case where the two disagree, and complete the switchover only once the disagreement log reaches zero. The author also notes that Permit has published a longer mapping of these policy patterns with code samples for its own platform.

Why it matters

Authorization decisions sit on the critical path of nearly every request an application serves, which makes an authorization migration one of the riskier refactors a platform team can attempt. An acquisition that closes while the bulk of the engineering team departs for another company changes the long-term risk picture for Oso Cloud customers, even if day-to-day operations are unchanged for now.

The practical takeaway from the dev.to post generalizes well beyond this episode: classify your policies first, across RBAC, ReBAC and ABAC, and record your list-filtering requirements separately, because that mix, rather than a feature checklist, determines which products can actually fit your system. One caveat worth holding onto is that the loudest migration guidance at moments like this tends to come from vendors courting departing customers, so it should be weighed accordingly.