Multi-Tenant.
Three doors into one fleet.
One instance of the Zodyria stack, three views into it. Admin sees everything. Team sees their lane. Clients see their orders and reports — nothing else. Same engine, different dashboards, one bill.
Admin, Team, Client — each sees only what they should.
The multi-tenant layer is built into the router, not bolted on as a permission table. A user's door determines which guardians they can call, which reports they can read, and which actions they can approve.
Admin Door
Full access to the entire fleet. Deploy and retire guardians, edit their skills, set autonomy tiers, view the full audit ledger, manage billing, add users. Admin is the owner — the only door that sees every tenant.
OWNERTeam Door
Access to assigned guardians and shared workspaces. A team member can give orders to their guardians, review reports, and approve Class B actions — but cannot change tiers, edit permissions, or see other team members' work unless shared.
MEMBERClient Door
Limited to project-based views. A client sees only the guardians assigned to their project, the current status of their tasks, and delivered reports. No visibility into other clients, the fleet roster, billing, or internal operations.
CLIENTThe same stack, isolated per user.
Multi-tenancy at Zodyria means one deployed instance of the Command Center, one set of guardians, one vault — but each user group sees a different slice of reality. Data is isolated at the router level, not at the database level, so nothing leaks between tenants.
Per-User Work Spaces
Every admin, team member, and client has a named workspace. Orders, reports, and history stay scoped to that workspace. No cross-contamination between tenants.
Assignable Guardians
Guardians can be assigned to specific tenants. A client's door only sees the guardians working on their projects. The same Zythria can serve two clients — each sees their own reports only.
Per-Tenant Audit Log
Every action is logged with the tenant ID, user ID, and guardian ID. Admins see the full global ledger. Team and client users see only their own slice — but it's the same log, not a copy.
Billing & Metering
Usage is metered per tenant. The admin sees one combined bill or per-tenant breakdown. Clients see their own usage dashboard. Stripe integration is built in. Free-tier-first applies per tenant.
SSO Ready
Authenticate via OAuth, SAML, or email link. Tenant membership is determined at login — the same email always lands in the same door. Admin can invite users with a single command.
Exportable Per Tenant
Every tenant can export their own data — orders, reports, audit log — as JSON or markdown. Admin exports everything. Client exports only what belongs to them.
Who uses multi-tenant mode.
Agency > Clients
Run one Zodyria instance for your agency. Each client gets a Client Door — they see their project status and reports, nothing else. You (Admin) see everything. No separate deployments per client, no shared credentials.
- Clients log in with their own email
- Each client sees only their guardians and tasks
- Billing is metered per client project
- Onboarding a new client is one invite
Small Business + Team
You own the Admin Door. You assign team members (employees, freelancers) to specific guardians. They get a Team Door — they can work, report, and approve operational actions. You keep the keys.
- Employees cannot change system configuration
- All team actions logged under their identity
- Add or revoke access instantly
- No shared passwords, ever
Individual + Contractors
Keep Admin for yourself. Invite a contractor as a Team member scoped to one guardian and one project. When the project ends, revoke the invitation. All their work stays in your vault.
Freelancer + Multiple Brands
Use Admin across your own brands. Each brand is a tenant with its own guardians, reports, and vault. You see everything; each brand sees only its own work. One login, multiple businesses.
No tables. Every permission is structural.
Zodyria doesn't use ACL tables. Permissions are determined by the door a user enters through — Admin, Team, or Client — and that door is enforced at the router layer before any guardian action begins.
Admin Capabilities
- Full fleet deployment and configuration
- All autonomy tiers (set A/B/C, modify)
- Billing management and tenant creation
- Full audit ledger (every tenant, every user)
- User invitation and revocation
- Skill editing and version management
Team Capabilities
- Orders to assigned guardians (all autonomy tiers, but cannot change tiers)
- Class B approvals
- Read own workspace audit log
- Export own reports
- Cannot see other team members' orders unless shared
- Cannot modify guardian configuration or skills
Client Capabilities
- View project status and completed reports
- Orders to assigned guardians (A-tier only; C-tier proposals visible but need Admin approval)
- Download deliverables
- Cannot see fleet roster or other clients
- Cannot see billing or internal operations
Invariant Rules
- No user can elevate their own door
- No user can see another tenant's data
- All actions are logged with user + tenant ID
- Class C is always human-gated (Admin or delegated team lead)
- Deleting a tenant archives its data; it never disappears
How to set up multi-tenant.
Step 1: Deploy the Stack
One deployment of the Zodyria stack on your server. The Command Center, the vault, and the guardians all run in one instance. Multi-tenancy is a configuration layer — it's always on.
Step 2: Create Tenants
From the Admin dashboard, create a tenant for your agency, your business, or each brand. Every tenant gets a unique ID, an invite link, and a default workspace. No separate deployments.
Step 3: Assign Guardians
Guardians are assigned to a tenant by default (everyone) or by specific door (Team/Client only). Assign Zythria to the "Acme Corp" tenant so their Client Door shows only recon work.
Step 4: Invite Users
Send an invite link from the dashboard. The user's email determines their door on first login. Admin gets full access; Team and Client get scoped access. Revoke any time with one click.
"Multi-tenancy at Zodyria is not a feature you turn on. It is the shape of the system — one instance, many doors, no sharing of what shouldn't be shared."