Skip to content

Access control — ZevCloud

Who can access what. The hard rules — implemented in code — are detailed below; the soft rules (employee onboarding, key rotation cadence, etc.) sit with the DPO office and platform security pages.

Customer-facing

  • Customers see only their own teams. A customer's API request must include a team header; the team-membership check runs in middleware before any controller.
  • Within a team, the team owner has every permission. Member roles (today: simple member; finer-grained roles will be added when customer demand justifies the complexity) get scoped read/write on team resources.
  • API keys carry per-key scopes — a build-server key meant only to trigger deploys can't be used to delete a domain.

Admin (engineering / ops)

  • All admin access goes through the admin panel at the admin.* host. Same ZevID OAuth flow as the customer dashboard, additionally gated by an RBAC permission list (admin-permissions.ts).
  • Each admin endpoint declares its required permission via @RequireAdminPermission(...). The decorator is the enforcement; permissions are not optional comments.
  • Sensitive billing actions (mark-paid, reverse, refund) are gated by separate permissions from the generic BILLING_MANAGE so we can give an ops teammate read+light-edit rights without giving them the ability to credit money.
  • Domain-attach (DOMAINS_ATTACH_EXTERNAL) and email-forwarding-manage (EMAIL_FORWARDING_MANAGE) are similarly separated from DOMAINS_MANAGE because they bestow elevated rights (DNS edit on a domain we don't bill for; ability to delete an alias on a customer's behalf).
  • Every admin write produces an admin_audit_logs row.

Production database

  • Direct DB access is held by the lead engineer (Daniel Arowolo) only. Day-to-day operations go through the application or admin panel, never raw SQL.
  • The application runtime connects via a scoped Postgres user with table-level grants; no superuser or CREATE/DROP rights at runtime. Migrations apply via a dedicated migration step on deploy.

Production infrastructure

  • Coolify (Hetzner Falkenstein) — host-level access held by the lead engineer. Customer containers are isolated per-service; no shared filesystem or network path between customer apps.
  • Cloudflare account — shared ecosystem account. ZevCloud manipulates only zones it has created or attached on the account. Direct console access (the CF dashboard) is held by the lead engineer.

Cross-product (ZPIP) access

  • Inbound ZPIP calls (e.g. ZevWorkspace asking ZevCloud to add a DNS record on a customer's behalf) require:
  • A valid ZPIP service+user token from ZevID
  • A user-consent grant for the requested scope (e.g. zevcloud.domains.dns.write)
  • The target resource (domain) belonging to the user named in the token
  • Outbound ZPIP webhooks ZevCloud dispatches (e.g. dns.record.deleted to ZevWorkspace) carry HMAC-SHA256 signatures; recipients verify with the shared secret negotiated at subscription time.

Reviews

Permission membership reviews are not yet on a fixed cadence — at our current size the admin headcount is one. When ops grows, the review cadence will be formalised (default candidate: quarterly).