Teams and access
Four customer roles, sub-accounts that mirror how your business is actually structured, per-organisation API keys, single sign-on and an audit log behind every privileged action. The same access model runs across the dashboard, the API, the CLI, Terraform and our MCP server — on the platform that hosts 100,000+ PBN sites across every niche.
Access is not a single on/off switch. Every customer organisation ships with four roles, each a fixed bundle of granular module.action permissions — so a finance contact never touches a server and a developer never sees an invoice.
Full control of the organisation and its sub-accounts: create child organisations, invite and remove members, change roles, manage API keys, provision, restart, suspend and delete sites, manage invoices and payment methods, and read the audit log. Two things deliberately sit outside it — closing an organisation and issuing refunds are staff actions, not a customer role.
Everything financial and nothing else: invoices, subscriptions, payment methods and the plan catalogue, plus a view of the organisation and its member list. No site access at all — a finance contact or an external bookkeeper cannot restart, suspend or delete anything.
Work on sites without touching money: view and provision sites, restart services, purge caches, manage API keys, and raise or reply to support tickets. No billing view, no member management, no suspend and no delete — the destructive and commercial actions stay with the owner.
A complete view with no ability to change anything — members, sites, billing, plans, tickets, translation status and the audit log. The right role for a client stakeholder, an internal auditor or a new starter still finding their feet.
Tenancy is a tree, not a flat list. A reseller organisation sits above its client organisations, and sites sit under those. A team member is a membership — one user, one organisation, one role — so the same primitive powers a two-person team, an agency managing a hundred client accounts and a reseller running sub-accounts under its own brand.
Roles are granted per organisation, and enforcement is per organisation too. Holding site-creation rights in one organisation grants nothing in another. A contractor can be a Developer on one client account and Read-only on a second, from the same login, and there is no combination of memberships that quietly widens their reach.
Isolation is enforced in the database, not just in application code. Postgres row-level security scopes every tenant query to the caller's subtree, and anything outside that subtree returns a not-found rather than a permission error — so the platform never even confirms that another tenant's organisation or site exists.
Roles are not a dashboard-only convenience. Every way into the platform resolves to the same permission keys, so there is no back door that skips your access rules.
Sites, billing, tickets, notices, notifications, API keys and team management in one shell. The interface renders what the signed-in member's role permits, so people are not shown controls they cannot use.
The published API is the same engine API the dashboard uses. API keys are issued per organisation with granular scopes tied to the RBAC permissions, and separate sandbox and live modes mean you can test integrations without touching real billing or provisioning.
Manage sites, domains, DNS, mailboxes and plans as infrastructure-as-code and run terraform apply to provision hosting — governed by the same scopes as everything else.
Connect Claude Code, Cursor, ChatGPT, Claude Desktop or any MCP-capable tool. Tokens are scoped to an organisation and its RBAC permissions, revocable per tool, with confirmation on destructive actions, spend caps and a full audit trail.
Only a hash of each API key is stored — never the raw key. Keys carry a name and a visible prefix so you can tell them apart, record when they were last used, and are revocable individually without disturbing the rest.
Identity runs on Keycloak, so authentication is proper OIDC and SAML rather than a bespoke login form bolted onto a hosting panel.
Every privileged action writes an append-only audit record: who did it, what they did, what they did it to, the supporting evidence and the originating IP address. Nothing is edited or overwritten after the fact, and in production the log is time-partitioned so it stays fast as it grows.
Reading that log is itself a permission. Owners and read-only members hold it, so the person responsible for the account and the person auditing it can both see the full history without needing elevated rights to do so.
Around that sit the controls larger teams ask for: session policies, optional per-organisation IP allowlists, and step-up authentication on sensitive actions so a live session alone is not enough to do something serious.
The permission catalogue is data, not hardcoded logic — which is why it can be extended without re-plumbing the platform.
Owner has full control of the organisation and its sub-accounts, including members, API keys, sites and payment methods. Billing Manager sees invoices, subscriptions, payment methods and plans, with no site access. Developer manages sites and API keys and handles tickets, with no billing or member control. Read-only can view members, sites, billing, plans, tickets and the audit log without changing anything.
Not as a per-site setting yet — narrowing a single membership to specific sites is a planned refinement. Today you achieve the same separation with the tenancy tree: put those sites in a child organisation and give the person a role there. Because roles are granted per organisation, that access does not carry over to anything else in your account.
No — API keys are issued per organisation, with granular scopes tied to the same RBAC permissions, and separate sandbox and live modes. Use them as service credentials for integrations, CI or Terraform, and use memberships for people. Only a hash of each key is stored, each key records when it was last used, and any key can be revoked on its own.
The Developer role covers viewing and provisioning sites, restarting services, purging caches, managing API keys and handling tickets. It does not carry publishing rights over a live site, so if you want someone to be able to promote changes, that access needs to sit with an owner. Roles are per organisation, so you can hold a different one on a different account.
Yes. Identity runs on Keycloak with OIDC and SAML, so SAML single sign-on is available for enterprise and agency customers alongside magic-link login, email and password, social providers, passkeys and TOTP two-factor authentication, which is enforced by policy. One session covers the dashboard, the public site and knowledge base, and support tickets.
Every privileged action is written to an append-only audit log recording the actor, the action, the target, supporting evidence and the IP address. Reading it is a permission in its own right, held by both the Owner and Read-only roles, so an account owner and an auditor can review the same history.
Plans are priced by hosting capacity rather than by people. On the Footprint-Free line, for example, all 42 tiers share exactly the same entitlement set and differ only by the number of sites they allow. Pricing is always rendered from the live catalogue, in your currency, so what you see on the pricing page is what is actually charged.
Yes. The Footprint-Free trial runs for 7 days, needs no card details and covers up to 5 sites, so you can set up your organisation, invite your team and test the roles against real work before you pay anything. There is a 30-day money-back guarantee behind the paid plans.
Start a card-free 7-day trial on the Footprint-Free line, invite your team, and see the roles working against real sites before you pay anything.
Start free