createApplication: permission grammar, scoped grants, groups, roles, access requests, management-layer approvals, sessions and view-as, and permission metrics.
Standalone is a finished place to stand. Most deployments stay here permanently, and nothing about staying is a compromise: the feature set is complete and no capability is gated behind a paid tier. The pages that follow answer organizational problems, such as a non-engineer who needs to administer access or a second application arriving. None of them is a gap in what standalone can do.
What standalone means
Standalone is the composition of two packages:@alfiz/core
The Client: the evaluator. Grammar, catalog, typed keys, check shapes, closure caches, the headless permission tree, and the listing helpers. Every capability is a pure function over provider-supplied data, with no storage and no I/O of its own.
@alfiz/application
The Application: your local provider. Implements the provider contract against your own database through a storage seam. In standalone mode it is the org root: the single authoritative home of all organizational data.
@alfiz/prisma for a Postgres, MySQL, or SQLite-backed storage driver, or use memoryDriver() for tests.
What you get
The full feature set, locally, with no external dependency:- Permission grammar and catalog. Declare every permission in code; template-literal types verify every call site at compile time
- Four enforcement points. Page gate, navigation visibility, server action, conditional UI;
alfiz-verifyproves coverage in CI - Scoped grants with expiry. Grant a role or a permission pattern at any scope, optionally time-bound, with provenance on every row
- Groups and nested groups. User cohorts with union-only inheritance; cycle detection enforced on every parentage write
- Roles. Named bundles of permission patterns; forward-inclusive wildcards absorb future keys automatically
- Reporting hierarchy. A
reports-toedge per user drives implicit groups (directs:<id>,orgof:<id>) usable as grant subjects and approval predicates - Access requests with management-layer approvals. Requestable roles and scope types; multi-stage workflows; management-chain routing resolved against your locally-stored hierarchy
- Sessions and view-as. Typed per-request sessions, plus admin preview that intersects the actor with the previewed identity and attributes denials to the actor
- Permission metrics. An optional structured observation per check, an OpenTelemetry adapter, a local aggregator, and the revocation safeguard
- The headless permission tree.
buildPermissionTree,toggleNode, andisNodeChecked: the wildcard-aware selection logic behind any role editor or grant picker you build, rendering from your catalog with no markup of its own - Listing helpers.
grantedScopesplusplanListingand the SQL-fragment builders, so a permission-filtered list becomes one indexed query instead of a per-row check
The Application is the org root
In standalone mode,orgRoot defaults to true. That means your Application is the single authoritative writer of all organizational-domain data: user groups and their nesting, role definitions, the reporting hierarchy, global-scope grants and revokes, and approval policies attached to those entities.
When you later link to Alfiz Cloud or federate, the org root can move, but in standalone it never needs to leave.
Runtime checks never leave your application
Regardless of where you go from here, this holds in every topology: everycan(), canAny(), and can.fresh() call runs in-process against your catalog, your grant rows, and your ancestry resolver. Alfiz is never a dependency of your request path, and check volume is never a billing dimension.
Setting up a standalone deployment
1
Install the packages
@alfiz/prisma.2
Define your catalog
The catalog is the single source of truth for your permission tree. It lives in code, not a dashboard.
src/authz/catalog.ts
3
Create the Application
Pass your catalog, a storage driver, and an ancestry resolver.
orgRoot defaults to true, so you do not need to set it explicitly in standalone mode.src/authz/app.ts
4
Create the client and start checking
src/authz/index.ts
await through render helpers:5
Wire deletion cleanup
Grants key on subject and scope strings, not foreign keys. When you delete a user or a resource, call the corresponding cleanup so stranded rows do not resurface on id reuse.
Who standalone is right for
Standalone is the right starting point for any organization with a single application. It is also the right answer for engineering teams who need full authorization capabilities today but do not yet need a non-engineer to administer access from a hosted dashboard.The standalone tier is complete, forever. Every capability listed above runs at no cost and with no external service dependency. You can build your own admin UI on the headless permission tree and the provider contract without ever upgrading.
The growth path
Standalone is a complete system. When your needs grow, the path forward is additive and reversible:Link to Alfiz Cloud
When a non-engineer needs to administer access, link your Application to get the Alfiz Cloud dashboard and admin seats. Your Application stays the org root and sole writer, and nothing architectural changes.
Federate
When a second application arrives, or when you need provisioned third-party integrations, federation moves the org root to Alfiz Cloud and unlocks cross-application role composition.
Share one database
When a second application already runs against the same operational database, partitioned storage lets both Applications share the Alfiz tables with strict isolation, and the mesh adds granted cross-application access with no new infrastructure.