OccupySaaS ships ZeroAuthy 1.0 RC, a self-hosted Auth0 stand-in. What works, what doesn't, and the catch

OccupySaaS says it is a group of laid-off engineers rebuilding paid software-as-a-service products as free, self-hostable code. On November 4 it released ZeroAuthy v1.0.0-rc.1, the first release candidate of its Auth0-compatible identity server. ZeroAuthy is written in Go and licensed under Apache-2.0. It has a sibling project, SalesCompel, which aims to replace Salesforce. Both are built from public API documentation, with AI agents writing much of the code and humans reviewing every merge.

Why it matters: per-seat pricing is one of the biggest line items for small software companies. Login and identity are also a classic lock-in point. Moving off a hosted auth provider usually means rewriting client code. ZeroAuthy's pitch is different: keep your existing Auth0 SDK calls and point them at your own server. The project drew wide attention when a Hacker News thread about it passed 500 points and 300 comments on November 2, according to the Zeli aggregator. This release candidate is the first build the project presents as something to try.

What ZeroAuthy implements

According to the project site, ZeroAuthy "speaks the Auth0 APIs." The RC covers:

The gaps are important. If your Auth0 tenant relies on SAML single sign-on, passkeys or a corporate directory connection, ZeroAuthy can't replace it today. The Daily Diff checked the OpenID Foundation's listing and says it records a specific ZeroAuthy commit for those three profiles. It also notes this is self-certification for protocol profiles only. It is not a security audit and doesn't prove full Auth0 parity. That review predates the RC and listed multi-factor sign-in as later roadmap work, so check the RC's compatibility notes before you count on MFA.

SalesCompel is much earlier

The project site labels the Salesforce replacement "early, in progress." It has a Go/PostgreSQL core with persistent Account and Contact records, object describe, limited queries, external-ID upsert, bearer-token auth and an OpenAPI REST contract. It also ships an offline compatibility test lab. The Daily Diff warns that a separate Vue prototype uses only synthetic, in-memory data, so don't mistake it for the real backend. The same review says token lifecycle and public login are still future work. It adds that no full program milestone has passed its exit gate.

How it's built

OccupySaaS calls its method "clean-room." Agents implement features from written specs drawn from public API docs, open standards and the behavior of vendors' public SDKs. Compatibility is then checked against those SDKs. The project's rules forbid using leaked code, decompiled binaries, a former employer's confidential information, and copied UI assets or trademarks. It says it isn't affiliated with Auth0, Okta or Salesforce. Its "occupation map" lists docs/wikis, issue tracking, feature flags, observability and customer support as proposed next targets. The site adds that these are open for discussion, not commitments.

Try it, carefully

The site publishes a Docker image, ghcr.io/occupysaas/zeroauthy:1.0.0-rc.1. You need a master key and a bootstrap admin email to start it. The sample setup uses self-signed TLS, which the project says is for testing only. A sensible first test is to run it locally and point a staging app's existing Auth0 SDK config at it. Then check every login path you actually use before going further.

The catch

• Not production-ready, by its own account. The OccupySaaS site says so plainly. The Daily Diff's verdict is "needs review."
• Self-hosting moves the work to you. One Hacker News commenter pointed out that customers pay SaaS vendors partly for backups and security updates. With a self-hosted identity server, both become your job, and auth is where mistakes hurt most.
• Unverified backstory. RuntimeWire and The Daily Diff both note that the layoff narrative comes from the project itself. Neither verified who the contributors are. Licensing is clear (Apache-2.0), but the project's own clean-room policy acknowledges contractual risk.

Who should care: small teams paying Auth0 per active user for plain OIDC login, and anyone who wants a local Auth0-compatible server for development and CI. Teams that need enterprise SSO should wait and track the compatibility matrix.