What linking means
When you link, Alfiz Cloud records the association and begins brokering dashboard sessions. It does not receive a copy of your authorization data, become a writer, or sit between your application and any runtime check. The only data that flows to Alfiz Cloud is the opt-in audit stream: an append-only history of writes to your Application’s organizational-domain data. That stream is never evaluated. It is retained for compliance and inspection, and never for making access decisions. Your Application continues to own every decision.A linked Application is still standalone in every meaningful sense. The Application is the org root and the sole writer. Alfiz Cloud records the link, authenticates dashboard sessions, and forwards administrative operations back to your Application for enforcement. It never writes your data directly.
What you get
Dashboard
A styled, maintained admin dashboard that non-engineer administrators can use to manage roles, groups, grants, and access requests. It speaks the same provider contract your own admin UI would, backed by your Application.
Admin seats
Authenticated dashboard sessions for non-engineer administrators. Seat billing starts when someone uses the dashboard, not when you link.
Hosted approvals inbox
A hosted queue where approvers work through pending access requests, rendered from your Application’s own request data, with decisions written back through your Application’s enforcement.
Opt-in audit retention and export
Choose to stream your Application’s audit events to Alfiz Cloud for long-term retention and export, which helps when your compliance horizon is longer than you want to manage locally.
What linking does not do
It is worth being explicit about what does not change when you link:- No authority moves. Your Application remains the org root. Every write to organizational-domain data (groups, roles, global grants, the reporting hierarchy) passes through your Application’s enforcement. Alfiz Cloud forwards dashboard operations; it never originates writes directly.
- No federated topology. Linking is not federation. No catalog is published to a registry, no org-root read model syncs down, no upstream is acquired.
- No impact on the request path. Runtime checks remain fully in-process.
can(),canAny(), andcan.fresh()still run against your catalog, your grant rows, and your ancestry resolver, exactly as they did before you linked. - Unlinking is clean. Because no authority ever moved, unlinking deletes only the link registration at Alfiz Cloud. No snapshot, no handoff, no residual state. Your Application continues running exactly as it did before.
Runtime checks are unaffected
This is worth stating again plainly: nothing about your request path changes when you link.Pricing
Your linked Application
$0 / month. A linked application itself is included at no cost. You pay only for the work Alfiz Cloud performs.
Admin seats
**24 month-to-month). Metered on authenticated dashboard sessions, so an idle link accrues nothing.
How to link
Linking is a registration step: you associate your Application with an Alfiz Cloud organization and configure the connection. TheApplicationOptions shape does not change; orgRoot stays true (or its default).
1
Create an Alfiz Cloud account
Register your organization at alfiz.dev. No payment method is required to link, and billing begins when admin seats are used.
2
Register your Application
From the Dashboard, create a linked application entry and copy your connection credentials. These connect your Application to Alfiz Cloud, and are not used for runtime checks.
3
Configure the Alfiz Cloud connection in your Application
The connection is the Provider API: the provider contract your Application already implements, served over HTTPS by a handler that ships in Note what is not here:
@alfiz/application. Mount it as a catch-all POST route, and Alfiz Cloud forwards administrative operations through it to your Application for enforcement. Your createApplication options do not change.src/app/api/alfiz/[...op]/route.ts
storage. Passing it enables the two
org-snapshot ops, which write your org-domain dataset straight through the
driver without the Application’s enforcement. Those exist for
promotion, and a linked deployment does not need them.
Add storage when you federate, not before.The Provider API setup guide covers the full flow, including registration, the connection URL, the secret, and the connection health probe.4
Invite admin seats
From the Dashboard, invite non-engineer administrators. They authenticate through Alfiz Cloud, and their operations are relayed to your Application for enforcement. Seat billing begins when they first authenticate.
Replacing the hosted dashboard
The hosted dashboard buys convenience. It buys no capability. It speaks the same provider contract your own code does, and every write it makes lands in the sameApplication methods, so there is no workflow it can perform that your own admin UI cannot.
If you outgrow it or need a custom look, build your own admin surface against the Application you already have, using the headless permission tree in @alfiz/core for the role editor and grant picker logic. Unlinking your Alfiz Cloud registration removes the relay and the hosted access, and nothing else changes.
Next: federation
Linking covers the single-application case. When a second application arrives, or when you need provisioned third-party integrations such as Zoom or Slack, the next step is federation.Federating applications
Federation moves the org root to Alfiz Cloud, unlocking cross-application role composition, a shared catalog registry, and provision-and-reconcile integrations. Promotion from the linked state is the typical path, because the connection to Alfiz Cloud is already established.