Delegated Access
Bring in a developer, hand billing to your accountant, give a client a read-only window onto their own sites, or let our support team look at a problem. Every grant is a role with defined permissions, scoped to an organisation, enforced in the database, and written to an append-only audit log.
Sharing one login is how account access goes wrong. On Zinn Digital® every person has their own identity, and access is a membership — a user, an organisation, and a role — that you can grant, change or revoke on its own.
Each collaborator signs in as themselves through Keycloak, our identity layer. Nobody types your password, nobody shares a browser session, and removing someone is one action rather than a password rotation and a scramble to work out who else knew it.
Accounts are hierarchical — a reseller organisation holds client organisations, and client organisations hold sites. A membership applies to an organisation and everything beneath it, so you can hand an agency client control of their own organisation without ever exposing your other clients.
Tenant separation is not a filter in application code that a bug could skip. Postgres Row-Level Security scopes every query to the caller's organisation subtree, so a request outside your scope has nothing to return.
Ask for an organisation or a site outside your scope and the API answers with a plain not-found rather than a permission error. A permission error would confirm the record exists; not-found tells an outsider nothing at all.
Permissions are granular keys — module plus action, like sites.restart or billing.refund — and roles bundle them. Four roles cover the shapes real teams need, and each one is data we seed, not logic buried in code.
Full control: create child organisations, invite and remove members, change roles, manage API keys, create, restart, purge, suspend and delete sites, run billing and invoices, raise tickets and read the audit log. The role you keep for yourself.
Sees the organisation, its members and the plan catalogue, and manages invoices, payment methods and charges. No access to create, change or delete a single site — exactly the shape an external bookkeeper should have.
Views and creates sites, restarts services, purges cache, manages API keys and works tickets. Deliberately excluded: billing, invoices, payment methods, member management, site suspension and site deletion. A contractor can build without being able to bill you or destroy anything.
Sees the organisation, its members, its sites, its billing, the plan catalogue, tickets, translation status and the audit log — and can change none of it. The right grant for a client who wants visibility, an auditor, or a stakeholder who only needs to look.
Delegating access is only safe if the accounts you delegate to are hard to take over. Authentication runs through Keycloak for every person on the account, on every surface.
Support work sometimes means looking inside your account. That access is governed by the same permission model as everything else — staff simply sit in a staff organisation, organised into departments with narrow grants.
Staff are grouped into Support, Billing and Finance, Abuse and Trust-and-Safety, Sales, Onboarding, Engineering and Ops, Marketing, and Management. Each role grants specific modules and actions, so an agent sees the part of the admin console their job requires and not the rest.
The Support Agent role grants exactly this: view customers, view and reply to tickets, view sites, restart a site and purge its cache. It carries no billing configuration, no refunds, no plan editing and no fleet management. The remediation an agent can perform is bounded by the role, not by good intentions.
The customer.impersonate permission is not part of the Manager role — it is held by Super Admin only. When a session is running on your behalf, the dashboard carries a persistent impersonation banner so it is never ambiguous who is acting.
Every privileged and administrative action appends to an append-only audit log recording the actor, the action, the target, supporting metadata, the IP address and the timestamp — time-partitioned in production. Owners and read-only members can read their organisation's log themselves.
Sensitive and destructive staff actions can require step-up authentication or two-person approval before they run, and new departments and roles are configuration rather than a code change.
Scripts, CI pipelines, the CLI, the Terraform provider and AI agents all authenticate through the same permission model as people — no shared human credentials, no long-lived secrets pasted into a build.
Keys belong to an organisation and carry granular scopes tied to the same RBAC permissions — read-only, billing, provisioning. Grant a pipeline the narrow scope it needs rather than a member's whole account.
Test-mode and live-mode keys are distinct, so an integration under development cannot reach into production data by accident or by a copied environment variable.
We store a SHA-256 hash of the secret and a lookup prefix — never the raw key. You see a key once at creation. Each key tracks when it was last used and can be revoked on its own without disturbing anything else.
Our MCP server lets any MCP-capable agent manage your hosting in natural language, authenticated with OAuth 2.1 and scoped to your organisation and RBAC role, with per-tool revocable tokens, confirmation on destructive actions, spend caps and full audit logging.
Account access and server access are different problems. Site-level credentials are managed in the dashboard, issued least-privilege, and jailed so that one collaborator's shell is one site's shell.
A solo operator keeps a single organisation and one owner membership, and adds a Developer role when a contractor comes in for a project. When the project ends, the membership is removed and their sign-in stops working immediately — there is no shared credential left behind to rotate.
An agency uses the organisation tree. Each client gets its own child organisation, holding that client's sites, and the client's own people get memberships there — read-only for a stakeholder who wants visibility, owner for a client who wants to self-serve. Your staff hold memberships higher up the tree and see the portfolio; a client sees only their own branch, and Row-Level Security is what makes that true rather than a promise.
A reseller works the same way, one level further up: a reseller organisation holds client organisations, each with its own members, billing view and sites. The same primitive powers sub-accounts, agency teams and reseller hierarchies — there is no separate, weaker mechanism for any of them.
Everything is available on the card-free 7-day trial. Sign up without payment details, invite a colleague, watch what each role can and cannot reach, and read your own audit log back.
Today a membership grants its role across an organisation and everything beneath it in the tree, so the way to separate site sets is to separate organisations — put those sites in their own child organisation and grant the membership there. It is a clean model for agencies and resellers, where each client already wants their own boundary. Per-membership resource scoping, pinning a single membership to named sites within one organisation, is a planned refinement rather than something available now.
The Developer role does not carry site deletion or site suspension — those keys belong to the Owner role. It grants viewing and creating sites, restarting services, purging cache, managing API keys and working tickets. Deployment and push-to-live permissions are not part of the Developer grant either, so promotion to production stays with the account owner. Pair that with staging so build work happens off the live site in the first place.
It depends entirely on the staff role, and each role is a narrow set of permission keys. A Support Agent, for example, can view your account and sites, view and reply to your tickets, restart a site and purge its cache — and cannot touch billing configuration, refunds, plans or the fleet. Signing in as a customer is a separate permission held only by Super Admin, and when it happens the dashboard shows a persistent impersonation banner. Every privileged action is recorded in the audit log with the actor, action, target, IP and timestamp, and you can read your organisation's log yourself.
Remove the membership and their access to that organisation ends — they still have their own identity, but no role and therefore no permissions in your account. API keys are revoked individually, so a pipeline key can be cut without disturbing anything else. If you use SAML single sign-on, deprovisioning in your identity provider handles sign-in centrally. Site-level credentials such as SSH keys are revoked in the dashboard, and the removal itself is audit-logged.
No — but it is worth being precise about why. API keys belong to the organisation, not to an individual member, and they carry their own granular scopes tied to the same permission catalogue. So rather than handing a person a key, you create a key for the job it does with the narrowest scope that job needs, and revoke that key when the job ends. Only a hash of the secret is ever stored, and each key records when it was last used so unused keys are easy to find and retire.
Yes. Our MCP server authenticates agents with OAuth 2.1 and scopes them to your organisation and your RBAC role, with per-tool revocable tokens, so you grant a specific capability rather than blanket access. Destructive actions require confirmation, spend caps apply, and every action lands in the same audit log as human activity.
Postgres Row-Level Security scopes queries to the caller's organisation subtree in the database itself, with the application-level filter as defence in depth rather than the only line. Requests for records outside scope return not-found rather than a permission error, so nothing is revealed about what exists. On the server side, per-site isolation through CageFS keeps each tenant's shell and files to their own site.
Yes. The 7-day trial is card-free — no payment details, no commitment — and covers Footprint-Free Hosting with up to five sites. It is enough to invite a colleague, assign a role, and confirm the boundaries behave the way you need before you commit.
Start on the card-free 7-day trial, invite someone, and watch the permission model do its job — roles you can name, scopes you can revoke, and an audit log that says exactly who did what.
Start free