Treetop is an open-source authorization stack built on Cedar. It separates access-control policy from application code and provides a consistent path from authoring and validation to deployment, evaluation, and operations.
Most applications use Treetop through the standalone REST service. Official Rust, Go, and Python clients, a command-line client, and a browser workbench cover integration and day-to-day operation. The Rust engine powers the service and remains available for specialized deployments that require in-process evaluation.
- Make fine-grained authorization explicit, testable, and independent of application business logic.
- Make centralized authorization straightforward to deploy and consume through a strict REST API and typed clients.
- Retain an embeddable Rust engine for specialized applications that need in-process evaluation.
- Package independently owned policy modules into deterministic, verifiable release artifacts.
- Make policy systems practical to operate with typed clients, validation tooling, metrics, and human-facing inspection tools.
- Keep the complete stack open source and usable through versioned libraries, binaries, containers, and automation.
Treetop REST evaluates Cedar requests expressed as a principal, action, resource, and optional context. The underlying policy engine supports schemas, group membership, and resource attributes derived through label rules.
The wider toolchain provides:
- validation and deterministic composition of policies, schemas, labels, and module manifests;
- optional Ed25519 signing and verification of policy bundles;
- atomic bundle loading in the REST server;
- authorization, policy, schema, bundle, OpenAPI, and metrics endpoints;
- typed Rust, Go, and Python integrations;
- native command-line tools for authorization and bundle workflows;
- a browser workbench for requests, policies, schemas, server status, and metrics; and
- a GitHub Action for policy validation and unsigned bundle builds in CI.
The typical delivery path is:
Cedar policies, schemas, and labels
↓
validation and bundling
↓
Treetop REST service
↓
applications, CLI, and workbench
Specialized Rust applications can use treetop-core directly when a separate service is not the
right deployment model.
The coordinated release adopts declared label ownership by exact Cedar resource type and attribute. Early Treetop releases prioritize correctness over compatibility; ambiguous ownership, deprecated aliases, and old-format defaults are removed. Bundle/module format 2 requires rebuilt and re-signed archives.
The September 6 release shipped Core, Bundle, REST, Rust/Python clients, CLI, and Workbench as 0.1.0; the Go client is 0.3.0 and Bundle Action is v2. See the breaking migration and release set for the new syntax, required consumer updates, published artifacts, and upgrade order.
Core and Bundle 0.2.0 are published with Cedar 4.13.0. The dependency refresh status and migration notes track every repository, release prerequisites, and toolchain changes. The dependency updates are merged; versioned releases beyond Core and Bundle remain separate.
All repositories below are maintained parts of the Treetop project. Together they provide the REST runtime, policy engine and delivery pipeline, client integrations, and operator tooling.
| Project | Role |
|---|---|
| treetop-rest | Standalone authorization server and REST API |
| treetop-client | Typed asynchronous Rust client |
| treetop-client-python | Typed synchronous and asynchronous Python client |
| treetop-client-go | Typed Go client with validated requests and responses |
| treetop-cli | Command-line client and interactive REPL |
| treetop-frontend | Browser workbench for Treetop servers |
| treetop-bundle | Policy validation, composition, signing, and archive tooling |
| treetop-bundle-action | Bundle validation and builds in GitHub Actions |
| treetop-core | Rust policy engine underlying Treetop REST, also available for in-process deployments |
See the organization profile for installation and release artifacts.
This repository publishes organization-wide GitHub content:
profile/README.mdis rendered on the organization's public profile.profile/assetscontains the Treetop lockup, mark, and avatar variants.
When updating the profile, keep the project catalog aligned with the organization's public
repositories and published artifacts. Prefer durable links such as /releases/latest, registry
project pages, GHCR package pages, and reviewed immutable commits for GitHub Actions. Mark planned artifacts as
unreleased instead of linking to tags that do not exist. Use relative asset paths
and verify Markdown links before publishing changes.