Who Maintains OPA Now — Styra's Team Joins Apple, and 11 Months of Verifiable Record

• Introduction — How Much of "Apple Acquired OPA" Is True
• What the August 20, 2025 Announcement Actually Said
• So Was It an Acquisition? What Can and Can't Be Confirmed
• The 11 Months Since — Releases Never Stopped
• The Different Fates of Styra's Tools
• Governance Arithmetic — When Every Maintainer Belongs to One Company
• What Open-Core Users Should Check in Light of This Event
• So What Should You Do
• Closing
• References

Introduction — How Much of "Apple Acquired OPA" Is True

In late August 2025, a rumor spread among teams that had OPA installed in their authorization stack: "Apple acquired Styra," "OPA now belongs to Apple." A policy engine, once installed, sits deep inside your infrastructure, so a rumor like this isn't something you can shrug off. But these statements aren't accurate — and exactly where and how they're inaccurate matters to practitioners.

Every fact in this post was verified against primary sources: the original announcement on the official OPA blog, release/commit/repository metadata queried through the GitHub API, the repository's MAINTAINERS.md and GOVERNANCE.md source, and public DNS resolver lookups (as of 2026-07-17). Starting from grading the rumor, this post records where OPA actually stands 11 months later.

What the August 20, 2025 Announcement Actually Said

The announcement came from the OPA blog, not from Apple. Note from Teemu, Tim, and Torin to the Open Policy Agent community is a post under the names of OPA's creators, dated August 20, 2025. Here's the gist:

• OPA's founders and a number of Styra team members are joining Apple.
• Apple is already a large-scale OPA user — the announcement explicitly states Apple uses it as a core component of the authorization infrastructure for its global cloud services.
• OPA remains a CNCF graduated project, and the project's governance and license are unchanged.
• The maintainer list stays the same; the only thing that changes is those maintainers' listed affiliation, from Styra to Apple.
• The tools that lived under Styra's GitHub — the commercial distribution EOPA, OPA Control Plane, various SDKs (TypeScript, React, C#, Java, and others), and the Rego linter Regal — begin a community process to move to CNCF's OPA GitHub organization.
• The website continues to be run by CNCF and the community; the Rego Playground continues to be run by Styra.
• The monthly release cadence is maintained, and the 2025 roadmap (language extensions, type checking, tooling, partial evaluation, performance, decision logs) continues.

One thing worth noting: the word "acquisition" does not appear anywhere in this announcement. This is not a story about one company buying another — it's a story about people changing employers.

So Was It an Acquisition? What Can and Can't Be Confirmed

Checking the press coverage against the primary text makes the wording clearer. Cloud Native Now's article wrote that Apple hired Styra co-founders Tim Hinrichs and Torin Sandall along with senior engineers, but did not acquire the company or its assets, and called it an "acquihire without an acquisition." No separate announcement under Apple's name on this matter has been found.

What happened to the company Styra afterward isn't documented anywhere official. But there are observable facts. As of July 17, 2026, when this post is being written:

• styra.com returns SERVFAIL for both A-record and NS-record lookups against public resolvers (1.1.1.1, 8.8.8.8). The domain's website is effectively gone.
• The github.com/StyraInc organization page returns 404. Old addresses like StyraInc/regal now redirect to repositories under the open-policy-agent organization.
• No official statement on the company's legal status (whether it's been dissolved, etc.) could be found. It's more accurate to say plainly what's unknown.

Meanwhile, that people continue OPA-related work at Apple is directly confirmed by public commit history. For instance, the open-policy-agent/swift-opa repository continues to show commits from a founding member using an Apple-affiliated email even after the announcement. For reference, this repository itself was created in April 2025, ahead of the announcement, and the Swift OPA announcement post went up on May 14, 2025 — circumstantial evidence that Apple's use of OPA was already underway before the August announcement.

The 11 Months Since — Releases Never Stopped

Whether a project is alive or dead is answered by the release record, not by words. Filtering the OPA release list down to the minor releases since the announcement gives this:

There are patch releases in between, and as of this writing the latest is v1.18.2 (2026-07-02). The monthly cadence the announcement promised is being kept, literally. For reference, OPA 1.0.0 shipped on December 20, 2024, so the entire 1.x era overlaps with this upheaval — yet no seam is visible in the release flow.

The content isn't just maintenance patchwork either. Some items from the roadmap the announcement laid out have actually shipped.

• v1.15.0 — a logger plugin interface and a file logger with rotation support. This corresponds to the roadmap's "logging to disk" item.
• v1.17.0 — the future.keywords.not import improves a long-standing negation-semantics issue in Rego. This is one of the roadmap's language-extension items.
• v1.18.0 — container-aware resource limits (restored GOMAXPROCS, GOMEMLIMIT support), and one breaking fix: the outbound User-Agent header violated RFC 9110, so it changed from the Open Policy Agent/version form to Open-Policy-Agent/version. If you have a WAF rule or log filter that matches this string exactly, it needs updating.

Names beyond the Apple-affiliated maintainers continue to appear in the contributor lists of the release notes. That said, "releases keep shipping" and "the project is healthy" are not the same sentence — we'll revisit that in the governance section below.

The Different Fates of Styra's Tools

The migration the announcement promised actually happened. But the subsequent trajectories of the migrated tools diverge sharply — this is where this event has the most to teach.

Regal — the survivor. The Rego linter Regal has kept releasing steadily since moving to the open-policy-agent organization. The latest is v0.42.0 on July 16, 2026 — the day before this post.

OPA Control Plane — the new growth. opa-control-plane is a management component that builds policy bundles from Git repositories and deploys them to object storage like S3, GCS, and Azure Blob. Its first tag after the migration, v0.1.0, landed on November 18, 2025, and the latest, v0.7.0, on June 9, 2026. Take the fact that it's still 0.x at face value — it's still being built.

EOPA — donated, but stalled. EOPA, formerly the commercial distribution for data-heavy workloads, was donated as open source, and releases continued from v1.43.0 on August 28, 2025 through v1.45.1 on November 6. Then it stopped. After that, only occasional dependency-bump commits followed, until the repository was archived on June 26, 2026 with an "archival notice" commit. The README says to feel free to take the code, and to reach out on OPA Slack if you're interested in maintaining it. About 10 months from donation to archival — nobody stepped up to take it over.

Everything else. The Rego Playground still responds with HTTP 200 today (at the time of the announcement it was run by Styra; who runs it now is not confirmed by any official document). The SDKs were also on the migration list, but this post doesn't verify the activity level of each individual repository. And there's one conspicuous gap — DAS, Styra's SaaS management plane, does not appear anywhere in the announcement's FAQ list. What guidance commercial customers received is something there's no way to confirm from public sources now that styra.com is gone.

Governance Arithmetic — When Every Maintainer Belongs to One Company

Now for the uncomfortable part. Reading today's MAINTAINERS.md, all 6 maintainers responsible for the opa repository area — Anders Eknert, Ash Narkar, Charlie Egan, Stephan Renatus, Tim Hinrichs, and Torin Sandall — are listed as affiliated with Apple. The Gatekeeper line (constraints, gatekeeper, and so on) is a different story: it's covered by 1 maintainer at Google and 3 at Microsoft, and the 3 at Microsoft carry an update timestamp of January 30, 2026.

GOVERNANCE.md specifies organizational voting — 1 vote per organization no matter how many maintainers it has, with the stated intent that no single organization can dominate a given area. But do the arithmetic, and the only organization holding a vote in the opa area right now is Apple. The safeguard formally still exists, but there's no counterweight organization present in that area.

To be fair, this concentration isn't a new problem. The same people were with Styra until yesterday, so the opa area being effectively concentrated in a single company was just as true during the Styra era. What changed is the character of that company — from one that made its living selling a policy engine, to one that uses a policy engine as internal infrastructure. A vendor has an incentive to keep the open source as a funnel for its commercial product; a large-scale user has an incentive to keep it for the stability of its own infrastructure. Which structure serves the community better can't be settled definitively, and at minimum, the 11 months of data so far doesn't support a neglect scenario.

The last safety net is the fact itself that the project sits with a foundation rather than an individual or a company. OPA became a CNCF graduated project in February 2021, and its code is Apache-2.0. Even in the worst-case scenario, forking and succession remain legally open — OpenBao, which split off from Vault during HashiCorp's license change, is a concrete example of that path, and that story is covered separately in the OpenBao v2.6 rundown. The most striking part of the contrast between the two cases is that because governance sat with a foundation, OPA passed through this upheaval without a fork.

What Open-Core Users Should Check in Light of This Event

EOPA's trajectory is the key lesson. When a vendor disappears, open-sourcing its commercial product is undeniably a graceful exit, but open-sourcing only guarantees the code's survival, not the product's. Even with the code public, if nobody steps up to maintain it, it gets archived 10 months later. If you're using a tool in a similar position, here's a checklist:

• List out the parts of your current stack that depend on commercial-only features. For EOPA users, that means things like data filtering or database-integration features.
• Check the project's ownership structure. Whether it's owned by a foundation (CNCF, etc.) or solely by a vendor makes a completely different outcome for a vendor-disappearance scenario. This is the primary reason OPA passed through this event largely unscathed.
• Actually read the MAINTAINERS file. The diversity of maintainers' affiliations is a risk indicator you can confirm from a public document.
• Calculate your exit cost ahead of time. Policy engines are on the high end of switching cost — porting across policy languages (Rego, Cedar, relationship tuples) is effectively a rewrite.

So What Should You Do

Teams running open-source OPA only — there's nothing to do right now. The release cadence, governance documents, and license are all being maintained exactly as they were before the announcement. Still, there are indicators worth watching: whether the monthly cadence holds, and whether non-Apple contributions and new maintainer recruitment show up.

Teams that depended on EOPA features — you need to make a decision. The repository is archived, and since it's Apache-2.0 you're free to fork and maintain it yourself, but if you can't absorb that cost, you need a migration plan to an alternative. Note that upstream OPA has not absorbed all of EOPA's features.

Teams that managed an OPA fleet with Styra DAS — the announcement didn't mention DAS, and the migrated OPA Control Plane covers the same problem space (bundle building and distribution). But no document officially declares it a successor, and it's still 0.x. This is not something to switch to without verification, not yet.

Teams considering adopting it for the first time — this event by itself isn't a reason to avoid OPA. If anything, it's closer to a case that demonstrates the value of foundation governance. Engine choice is still decided by the type of problem — general-purpose policy evaluation (OPA) versus relationship-based authorization (the Zanzibar family) — and that comparison is laid out in the Authorization Engine Deep Dive. If your goal is Kubernetes admission policy, also see the Kyverno vs. OPA Gatekeeper Comparison — as we saw above, the Gatekeeper area is watched over by Google and Microsoft maintainers.

Closing

Strip it down to the facts and this is what's left: no acquisition was ever announced; people changed employers. The project sat with a foundation, so governance and releases continued even as people's employer changed. The commercial products were donated as open source, and among them the linter survived while the commercial distribution was archived within 10 months — the same event showing, simultaneously, that open-sourcing something is not the same as making it sustainable.

"When the vendor disappears, the open source project is over" is wrong, and so is "it's open source, so it's automatically safe." The fork in the road was where ownership structure and maintenance incentives sat. I'd recommend using this as an occasion to open the MAINTAINERS file first, and figure out which components in your stack are hanging off a single company.

References

• Note from Teemu, Tim, and Torin to the Open Policy Agent community (OPA blog, 2025-08-20)
• OPA release list (GitHub)
• OPA MAINTAINERS.md (source) / GOVERNANCE.md (source)
• open-policy-agent/eopa — the repository archived after donation
• Regal releases / OPA Control Plane releases
• OPA v1.17.0 release notes — future.keywords.not / v1.18.0 release notes — User-Agent breaking fix
• CNCF, OPA graduation announcement (2021-02-04)
• Apple Buys Styra Brains, OPA Remains Open (Cloud Native Now)
• Introducing Swift OPA (OPA blog, 2025-05-14)
• Authorization Engine Deep Dive — FGA/Zanzibar family comparison (related post)
• OpenBao v2.6 — After Splitting from Vault (related post)