# Permify: a self-hosted Zanzibar-style authorization service in Go

> Permify is an open-source authorization service inspired by Google Zanzibar. It centralizes permission checks behind a gRPC and HTTP API, runs against Postgres or in-memory storage, and is licensed AGPL-3.0.

**Permify/permify** — An open-source authorization as a service inspired by Google Zanzibar, designed to build and manage fine-grained and scalable authorization systems for any application. — Permify is now part of FusionAuth 🎉

- Repository: https://github.com/Permify/permify
- Website: https://permify.co/
- Stars: 5,961 · Forks: 328
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/permify-permify

## What Permify solves, and who ends up running it

Authorization logic tends to grow inside application code: a role check here, a team membership join there, an exception for shared documents somewhere else. Permify's premise is that this logic should be a separate service. The README describes it as an open-source authorization service for building fine-grained, scalable access controls, and says it abstracts authorization logic from your codebase so it can be reasoned about, tested and debugged as a single entity. The questions it answers are runtime ones: can user X view document Y, and which posts can members of team Y edit. The README claims responses in tens of milliseconds.

The audience is teams whose permission model has outgrown a roles column. Permify's authorization language is described as compatible with RBAC, ReBAC and ABAC, so it targets resource-specific and hierarchical rules as well as context-aware ones. The README also calls out multi-tenancy: isolated authorization logic and custom permissions per vendor or organization, managed in one place. If your product is single-tenant and your rules are static, this is more infrastructure than you need.

## The mechanism: schema, relations, and a check API

The design follows Google Zanzibar, and the repository layout reflects it. There is a proto/ directory for the API definitions, an internal/ package tree, a cmd/permify binary, and an sdk/ directory of client samples. The service is written in Go: go.mod declares module github.com/Permify/permify and Go 1.25.7, and the Dockerfile builds ./cmd/permify with CGO_ENABLED=0.

The README points at three moving parts. First, an authorization model written in Permify's domain-specific language, covered in the modeling guide. Second, relationship data, the tuples that say which subject relates to which object. Third, a check API that evaluates the model against that data at request time. Permify does not push decisions into your database; your app calls the service. The README says it works in run time and can respond to access checks from any of your apps and services.

Storage is pluggable. The repository ships docker-compose.yaml with a Postgres service and a Permify service, and go.mod pulls in jackc/pgx/v5 and hashicorp/go-memdb, which matches the README's self-hosted Community Edition story. There is also a cache dependency, dgraph-io/ristretto, in the module graph. The README does not document cache invalidation semantics, so treat caching as something to verify against your own consistency requirements rather than assume.

## Installing Permify with Docker and making a first check

The repository ships a docker-compose.yaml that starts Permify alongside Postgres. The Permify service is exposed on ports 3476 and 3478, and the healthcheck runs grpc_health_probe against localhost:3478. The database service uses the postgres image with POSTGRES_PASSWORD=secret and POSTGRES_DB=permify.

```bash
docker-compose up --build
```

The Makefile wraps the same thing: make compose-up runs docker-compose up --build. The README does not document the first API call in the excerpt available here, so the honest next step is the documented API reference and the Playground at play.permify.co, where the README says you can build authorization logic and test it with sample data. The README's getting-started list also links the modeling guide and the SDK samples under sdk/.

If you prefer to build the binary yourself, the Makefile has a build target that compiles ./cmd/permify into ./permify, and the Dockerfile builds the same command. The container image entrypoint is permify with a default command of serve.

```bash
make build
./permify serve
```

The README does not document environment variables or a configuration file in the excerpt, but the repository contains example.config.yaml at the top level, which is the file to read before changing ports or storage settings. Do not assume flags that are not in that file.

## Where Permify is the wrong tool

The cost is operational. You are adding a service, a schema language, a relationship store and a second consistency boundary between your application and its data. For a small application with three roles and no sharing model, that is a large amount of machinery for a problem a single join solves. The README's own framing, minutes to days instead of months, is about building the model, not about the ongoing cost of running it.

The licence is the second constraint. Permify is AGPL-3.0. That is a strong copyleft licence with a network clause. Whether it obliges you to publish modifications depends on how you deploy and distribute the software, and that is a question for your own counsel, not something this article can settle. Teams that cannot accept AGPL-3.0 terms in their stack should stop at this paragraph.

Third, the project changed hands. The README leads with the news that Permify has been acquired by FusionAuth, linking the Permify blog post and the FusionAuth press release. The repository is not archived and the last push was on 2026-09-21, with v1.7.4 released on 2026-09-10. So the code is moving. What the README does not say is how the Community Edition and the commercial Cloud offering will be divided going forward, beyond the comparison table it includes. Anyone planning a multi-year commitment should read that table carefully rather than assume the current split is permanent.

## Permify versus OpenFGA

The closest comparison people search for is OpenFGA, the CNCF-hosted Zanzibar implementation. Both take the same starting point: a model, relationship tuples, and a runtime check API. The difference is in packaging and language surface. OpenFGA's model is defined through its own DSL and its API, and it is governed as a CNCF project. Permify's README presents its authorization language as spanning RBAC, ReBAC and ABAC, and the repository includes a dedicated playground/ directory and a hosted Playground for building and testing a model with sample data. Permify is also a single Go binary with Postgres or in-memory storage behind it, and go.mod shows a CEL dependency (google/cel-go), which is consistent with the ABAC side of the README's claim.

Neither choice is decided by features alone. OpenFGA's CNCF governance is a different answer to the long-term maintenance question than Permify's acquisition by FusionAuth. If neutral governance is a hard requirement for your organization, that is the deciding difference, and Permify's README does not offer an equivalent. If you value a single self-contained binary and an in-browser playground for iterating on the model, Permify's layout is friendlier.

## Maintenance, upgrades and the licence question

The signals here are current. The repository is not archived, the last push was on 2026-09-21, and releases have been regular: v1.7.2 on 2026-07-07, v1.7.3 on 2026-08-17, and v1.7.4 on 2026-09-10. That is a roughly monthly cadence over the last three releases, which is a reasonable proxy for a project that is still being worked on.

Upgrade cost is harder to judge from the repository alone. The README does not document a migration or rollback procedure, and the presence of pressly/goose/v3 in go.mod suggests schema migrations are run by the service itself, but the excerpt does not describe how they are applied or reversed. The practical step is to read the migration tooling in internal/ and the release notes for each version before upgrading a production instance, and to test the upgrade against a copy of your relationship data, not just an empty database.

The licence is AGPL-3.0. For internal use behind an API, the obligations are lighter than for a redistributed product, but the network clause is exactly the kind of thing that surprises teams who embed an AGPL service in a hosted product. The README does not discuss licensing implications of the FusionAuth acquisition, and the repository ships a NOTICE file alongside LICENSE. Read both, and get advice from someone qualified to give it.

## Conclusion

Adopt Permify if you want permission logic out of application code and behind an API, and you accept running Postgres plus a new service. Skip it if your rules fit in a few SQL joins or a policy library you already ship. Before committing, verify the CE versus Cloud split in the README table, the licence obligations of AGPL-3.0 for your distribution model, and whether the schema language covers your hierarchy depth.

## FAQ

### What is authorization as a service, and how does Permify fit that description?

It means permission decisions are made by a separate service your application calls at runtime, rather than by code inside the application. Permify is an open-source authorization service that answers checks such as whether user X can view document Y, using a model written in its own language plus relationship data.

### Is Google Zanzibar open source, and what does that mean for Permify?

Google Zanzibar itself is not released as open source; Permify is described as inspired by it. The README links Google's Zanzibar paper and a Permify article explaining the system in a nutshell, and Permify's own implementation is published under AGPL-3.0.

### What is permission-based access control, and does Permify support it?

Permission-based access control means decisions are expressed as named permissions on resources rather than raw roles. Permify's authorization language is described as compatible with RBAC, ReBAC and ABAC, so role-based models are one option among several rather than the only one.

## Sources

- [License: AGPL-3.0](https://github.com/Permify/permify/blob/master/LICENSE)
- [Permify/permify on GitHub](https://github.com/Permify/permify)
- [Project website](https://permify.co/)
- [README](https://github.com/Permify/permify/blob/master/README.md)
- [Releases](https://github.com/Permify/permify/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/permify-permify