ZevCloud¶

1. Snapshot¶

2. Mission¶

ZevCloud is the deployment surface for developers and small teams building on top of the Zev ecosystem. A user connects a repository (or uploads a static build), the platform builds and runs it on infrastructure ZevCloud operates, and the result is reachable on a generated subdomain or on a custom domain the user manages through the same platform. The product is opinionated about closing the gap between "I have code" and "it's live in production" — billing in Naira, defaults sane for the Nigerian developer market, and a single account that already works across every other Zev product.

The longer-term reason ZevCloud exists: developers in Nigeria today who want managed deployment have to look outside the country. Almost every comparable platform is international — USD-billed, FX-exposed, with customer-support time-zones tuned to a global audience that doesn't include Lagos, and with payment rails (cards in foreign currency) that are friction for Nigerian-based builders before the first deploy even happens. The local alternatives are mostly cPanel-based shared hosting, which is fine for a basic website but isn't built to run a real application — and structurally puts each customer on a server with many strangers competing for the same CPU, memory, and PHP processes. ZevCloud is the middle ground: managed deployment with the rigour of the international platforms, Naira-billed and locally operated, with a registrar + DNS + email-forwarding layer in the same dashboard so a team doesn't have to stitch four vendors together for a normal product launch.

That middle ground is structural, not just a billing label. ZevCloud is the first Nigerian-operated platform of its kind to ship a true managed-deployment experience with full tenant isolation. Every deployed service runs in its own isolated container with its own filesystem, process namespace, and resource budget. A team scales by adding capacity to their own service — not by competing with strangers for the same machine. The dominant local model (cPanel-based shared hosting) can't make this guarantee by design; the dominant international alternative (managed-deployment platforms operated abroad) can, but bills in USD. ZevCloud is what you reach for when you want both at once.

3. Audience¶

Users of ZevCloud are people who write code and need to host the result. In practice today, that means:

• Solo developers and small builders shipping side projects, MVPs, or commercial SaaS without the overhead of cloud-platform billing in USD.
• Small Nigerian SaaS teams who want managed application + domain infrastructure under one roof, paid in Naira from a single team account.
• AI-assisted builders producing apps faster than traditional hosting workflows can keep up with — the "I generated this in an afternoon and want it live tonight" cohort.
• Indie agencies managing several client projects, each as a separate team, with billing kept distinct.
• Teams who've outgrown shared hosting — they've hit the limits of a cPanel-class environment (noisy neighbours, no real process isolation, limited language runtimes), but don't want to graduate to international platforms billed in USD.

A ZevCloud account is always a team — even a solo user has a team-of-one. Teams own services, domains, and invoices; team members are invited with scoped access. A single ZevID account can belong to many teams (e.g. one per client), and switching teams in the dashboard switches every billing and resource view to that team's scope.

4. Core capabilities¶

Each capability below is something a user can do from console.zevcloud.net today.

Deploy from Git¶

Connect a GitHub repository, point at a branch, and ZevCloud builds and runs the resulting service. The build inspects the project structure to choose sensible defaults — Node / Next.js / Python / Astro / static — but every default is overridable. Each deployment gets a generated subdomain on zevcloud.app so the running service is reachable immediately, before the user has bought or attached a custom domain. The newest deployment becomes the live one; the previous one is retained as a rollback target until superseded.

Static-site hosting¶

For a static build (Astro, Vite, Hugo, plain HTML), the team can upload the build output directly and have it served from a CDN-backed origin. No build step runs on the platform — the bytes the user uploads are what gets served, with cache-control and TLS handled automatically.

Managed databases¶

A team can provision a Postgres, MySQL, or Redis instance scoped to the team. The instance gets a connection string surfaced as an environment variable on every connected service, so a fresh service can read its database config without the user having to copy credentials around. Backups, version upgrades, and rotation are managed by ZevCloud.

WordPress hosting¶

For non-developer or hybrid teams, WordPress is a first-class deployable type — pick "WordPress" instead of "Connect a repo", choose a plan, and the platform provisions a managed PHP runtime + database. Updates to WordPress core and plugins are scheduled by the platform with admin override.

Custom domains + automatic TLS¶

A team attaches any domain it controls to any service. TLS certificates are issued automatically (Let's Encrypt) and renewed without the user ever touching them. If the domain was registered through ZevCloud, attachment is one click — the DNS record is written for the user. If the domain is registered elsewhere, the dashboard shows the exact record the user needs to add at their existing DNS provider.

Domain registration¶

Register and renew domains directly from the platform. ZevCloud is a direct NIRA-accredited registrar for .ng and the .com.ng / .org.ng / .net.ng / .gov.ng / .edu.ng family — meaning ZevCloud holds the EPP credentials with NIRA itself, not a reseller in the chain. Non-.ng TLDs (.com, .io, .app, .dev, etc.) are handled through a global registry partner. The user sees:

• A unified search that quotes a price for any TLD ZevCloud sells, in Naira, with multi-year options and add-on selection (ID Protection, Email Forwarding) priced in line with the registration.
• A unified cart for bulk purchases — buy ten domains in one transaction with one invoice.
• An ID Protection (WHOIS privacy) toggle per domain. With it on, the registrant's name + address are replaced in the public WHOIS lookup by ZevCloud's proxy contact while the real contact stays on file privately at the registry.
• An auto-renew toggle per domain. Off by default for transparency; the user opts in and the platform handles renewal billing automatically before expiry.
• Transfer in (move a domain from another registrar to ZevCloud) and transfer out (move away) flows, with the EPP auth code surfaced in the dashboard on demand for outbound transfers, per ICANN policy.

Domain attachment without transfer¶

A separate flow lets an admin attach an externally-registered domain to a team for DNS-only management — the registration stays at the other registrar (e.g. NameSilo or GoDaddy direct), but the user's authoritative DNS lives on ZevCloud. The dashboard surfaces a banner on the attached domain encouraging the team to transfer in fully when convenient. Until they do, email forwarding and other registrar-side features stay locked because they require the registration relationship.

DNS management¶

For every zone ZevCloud manages, the team can create, edit, and delete every standard DNS record type (A, AAAA, CNAME, MX, TXT, NS, SRV, CAA) from the dashboard. Edits propagate immediately to the authoritative DNS layer. A safety mirror of every record is held in the platform database so a brief edge outage doesn't blind the dashboard. Out-of-band edits (someone deleting a record via the upstream provider's own interface, where applicable) are detected on the next reconciliation and the team is notified.

Email forwarding¶

A team can turn on inbound email forwarding for any domain it manages DNS on. When the toggle flips, the platform:

1. Provisions the domain on the email-forwarding relay backend.
2. Writes the MX, SPF, and ownership-verification TXT records on the user's DNS zone automatically.
3. Asks the relay to re-check DNS immediately so the domain becomes deliverable within seconds rather than the relay's default re-check window.

After that, the team explicitly adds each forward — sales@theirdomain.com → their existing inbox, with up to five destinations per forward and an admin-configurable cap on total forwards per domain (default 5). The platform never auto-creates a forward on the user's behalf — every alias is a user action, and the platform refuses any pre-existing alias on first toggle as a safety measure.

If the domain already routes mail to another service (Microsoft 365, Google Workspace, Zoho, etc.), the toggle refuses and asks the user to confirm replacement before any DNS change is made. The MX records that would be removed are named explicitly in the confirmation dialog so the user can't accidentally break a working mailbox setup.

Team-based access + audit¶

Teams have an owner plus member roles. Inviting a teammate sends them an email with an explicit join link. Every admin action against a customer resource (refunds, force-deletes, attach-external-domain, mark-paid) writes a row to a tamper-evident audit log. Splits in admin permission exist precisely because not every ops teammate should be able to credit money (BILLING_INVOICES_REFUND) or grant DNS rights on a domain the team hasn't bought (DOMAINS_ATTACH_EXTERNAL) — those are separate from generic management permissions.

API keys for automation¶

Each team can issue scoped programmatic-access keys for CI / external automation. Keys carry per-key scopes — a build-server key meant only to trigger deploys can't be used to delete a domain. Plaintext is shown once at creation; only a one-way hash is stored after that.

Naira billing through ZevPay¶

Every invoice, subscription, refund, and payment-method token is handled through ZevPay. A team's payment methods are added at ZevPay (cards, bank transfers via VFD, USSD) and re-used across ZevCloud purchases. Refunds can be issued either to the original payment method or as Zev Credit (see below).

Bulk domain orders bill as one invoice. A pending invoice blocks no other team operation except the one it's tied to (deploy, register, etc.) — the team can keep using their existing services while an unpaid invoice sits in the dashboard.

Zev Credit (credit-as-currency in the Zev ecosystem)¶

Every ZevID user holds a centralised, non-withdrawable spending balance called Zev Credit — earned at any Zev product, spendable at any Zev product that accepts it. ZevID owns the canonical ledger; ZevCloud participates as both an issuer and an acceptor. See the canonical model at Cross-product → Zev Credit.

ZevCloud-specific behaviour:

• Accepts credit on every invoice automatically. When an invoice is generated (new service plan, domain registration, renewal, add-on, etc.), the platform checks the team's spendable balance in the invoice currency and applies it before charging any payment method. If credit covers the full amount, no ZevPay invoice link is even created — the invoice is recorded as paid, the resource provisioning runs, and the team sees the credit drawn down in their next dashboard view. If credit covers only part, the shortfall is invoiced through ZevPay as normal.
• Issues credit on refunds (source: refund) when an admin chooses "refund to credit" instead of "refund to original method". Refund-to-credit is instant — the platform debits the invoice (and revenue rolls back automatically), the credit lands on the team's balance, and the team can spend it at the next eligible purchase here or at any other Zev product that accepts credit.
• Universal scope — credit ZevCloud issues is spendable across the ecosystem (not locked to ZevCloud). This is deliberate: when a customer is refunded for a cancelled domain order, the value of that refund should travel with them wherever they go next inside Zev.
• Per-team holder — Zev Credit earned through ZevCloud is held by the team (not the individual user). When team ownership transfers, the credit moves with the team. This matches how invoices are billed.

This is part of what makes a "refund" actually feel like one in Naira-billed flows. International platforms typically restrict refund destination to "original payment method only" with multi-day clearing windows; ZevCloud doesn't.

5. Architecture summary¶

• Backend — a Node.js API serving every dashboard, admin, and integration call.
• Database — a managed Postgres instance holding teams, services, deployment events, environment-variable references, domain registrations, DNS-record mirrors, billing artefacts, and the audit trail.
• Cache — in-memory cache for sessions, rate limits, idempotency keys, and queued background work.
• Container-orchestration layer — runs the customer-deployed applications themselves, isolated per-service with per-team scoping.
• Authoritative DNS — the platform owns the user-facing DNS plane on every zone it creates or manages on the user's behalf.
• Inbound email-forwarding relay — a paid integration with its own encrypted alias database; ZevCloud integrates via API + DNS, never via public DNS rules.
• Transactional outbound email — for deploy / billing / domain-lifecycle notifications.
• Edge protection — every public surface sits behind a CDN with TLS termination, HSTS, and DDoS mitigation.
• Centralised exception + log monitoring — every error and important security event is forwarded to a monitoring platform the engineering team watches.

flowchart LR
    User([User browser]) -->|TLS| Edge[Edge / CDN]
    Edge --> API[ZevCloud API]
    API --> DB[(Platform database)]
    API --> Cache[(Cache)]
    API --> Orch[Container orchestration]
    API --> DNS[Authoritative DNS]
    API --> Mail[Outbound email]
    API --> Fwd[Email forwarding relay]
    ZevID -->|identity| API
    API -->|billing| ZevPay
    Other[Other Zev products] -->|ZPIP| API

6. Key flows the user sees¶

A few flows worth understanding at the level a marketing or product person could re-tell.

Signup to first live URL¶

1. User signs in to console.zevcloud.net with their ZevID account (signs up via ZevID if they don't have one).
2. The platform creates a default team (named after the user's first name) and lands them on the empty services list.
3. They click New service → connect their GitHub repo → pick the branch → click Deploy.
4. The platform builds (logs streamed live), boots a container, and assigns a generated *.zevcloud.app subdomain. TLS is already in place on *.zevcloud.app, so the URL works the moment the build finishes.

At any point after that, they can attach a custom domain — buy one inside the dashboard or attach an existing one — and the live URL switches over without downtime.

Buy a domain end-to-end¶

1. User searches the domain they want. Availability is checked live against the registry. Price is quoted in Naira, with multi-year options visible inline.
2. They opt-in/out of ID Protection and Email Forwarding for that domain at the cart stage.
3. They confirm the registrant contact (re-used from previous purchases when applicable, prompting only for missing fields).
4. The cart turns into a single invoice; payment goes through ZevPay; on payment, the platform registers the domain at the relevant registry, provisions a DNS zone, sets the platform's nameservers, and presents the team with a populated DNS-management view.

A pending invoice is held for 24 hours (configurable) — if not paid, the domain reservation is released and the customer is free to retry.

Enable email forwarding on a custom domain¶

1. User opens the domain's manage page, clicks Settings → Email Forwarding → Enable.
2. If the domain has DNS managed by ZevCloud (whether transferred-in fully or just attached for DNS), the toggle proceeds. Otherwise the user is told they need to point nameservers at ZevCloud first.
3. Before any DNS write, the platform scans the zone's existing MX records. If any point at a third-party mail service (Microsoft 365, Google Workspace, etc.), the toggle pauses and asks for explicit "yes, replace this setup" confirmation that names the service being replaced.
4. On confirm, the platform writes the relay's MX records + SPF + verification TXT, then immediately pings the relay to re-check DNS. The domain becomes deliverable in seconds.
5. The user adds forwards through the Email tab — sales@theirdomain.com → me@gmail.com (up to five destinations per forward, up to five forwards per domain by default). They can edit or remove forwards at any time. The platform never adds a forward on the user's behalf.

Refund a paid invoice¶

1. Admin opens the invoice from the admin dashboard.
2. Two refund options are offered — to the original payment method or to the team's Zev Credit balance.
3. To-Credit refunds are instant: the platform debits an internal accounting row and the credit appears on the team's next eligible invoice (here or at another Zev product). To-Original refunds route back through ZevPay and follow the original payment channel's clearing window.
4. The invoice is annotated with the refund (full or partial), and revenue queries net the refund out automatically so reporting isn't misleading.

This is one of the places the Naira-billed positioning pays off — refunds work cleanly because the same entity owns the billing rail, the credit ledger, and the product.

7. Data the product handles¶

For the full data inventory with field-level encryption notes and retention specifics, see compliance docs → ZevCloud data inventory.

8. Security posture¶

For the full security record, see compliance docs → ZevCloud security.

9. Compliance posture¶

• Nigeria Data Protection Act (NDPA), 2023 — primary obligation. ZevCloud is the controller for its account holders, team members, billing contacts, and domain registrants. For the data customer-deployed applications themselves process (the customer's users), ZevCloud is a processor — the customer is the controller and decides the purpose. The distinction matters when end-user subject-rights requests reach the platform: they're routed to the deploying customer, not handled by ZevCloud directly.
• NDPC General Application and Implementation Directive (GAID), 2025 — implementing rules including 72-hour breach notification, DPO designation, RoPA. DPO designated: Izunna Ikewete (dpo@zevop.com).
• ICANN / NIRA registrar obligations — as a direct NIRA-accredited registrar for .ng and a registrar partner for other TLDs, ZevCloud submits the required registrant contact set to each registry per ICANN / NIRA policy. WHOIS visibility is governed by the per-domain ID Protection setting.
• Cross-border transfer posture — primary data store and application backend are located in the United States; the customer-workload tier (the apps customers deploy) runs out of Europe today and will diversify as the platform expands. Sub-processor detail and DPA records are maintained at compliance.zevop.com.

For the detailed compliance record (RoPA, third-party DPAs, retention table, subject-rights procedure, breach-response runbook), see compliance docs → ZevCloud.

10. Integrations¶

Zev products this depends on¶

• ZevID — every authentication call, every cross-product permission check, every enrollment write goes through ZevID. ZevCloud holds no identity data of its own; it addresses every user by the accountId ZevID issues. MFA enforcement, the user's security settings, and the Connected Apps screen (where a user revokes permissions ZevCloud holds against another product) all live on accounts.zevop.com.
• ZevPay — every invoice and recurring subscription is billed through ZevPay; payment-method tokens are minted at ZevPay, never at ZevCloud. Refunds-to-credit hit ZevID's central Zev Credit ledger.

Zev products that depend on ZevCloud¶

• ZevWorkspace — calls ZevCloud over ZPIP to provision DNS records on a domain the user manages here. The typical case is a user setting up a custom email domain at ZevWorkspace whose DNS lives at ZevCloud — ZevWorkspace asks ZevCloud to write the DKIM + verification TXT records on the user's behalf. Each call is gated by an explicit user consent screen on accounts.zevop.com, with the user's accountId baked into the token so ZevCloud can scope the operation to domains they actually own.

When records added by another Zev product are later removed on the user's behalf (either by the user via the dashboard or by an out-of-band sweep), ZevCloud dispatches a dns.record.deleted webhook back to the originating product so they can update their own state.

11. Roadmap signals¶

• This quarter — Self-service data-export from the account-settings page (mirroring ZevID's privacy work, scoped to ZevCloud-owned data). Sets the precedent for an end-user-readable export.
• This quarter — A WordPress one-click marketplace for plugins / themes vetted by the platform, so non-developer teams can extend a managed WordPress without falling off the supported path.
• This year — Additional customer-workload regions, so a customer's deployed app can be pinned to a region closer to their end users; today every workload runs from a single region.
• This year — Programmatic-API parity with the dashboard, so the same operations a user can do in the UI are exposed through stable APIs for CI / external automation.
• This year — Per-service custom metrics dashboards (memory, request rate, error rate) so a developer doesn't have to bring their own monitoring stack to ship something to production.

12. Contacts¶

• Product owner: Daniel Arowolo — (email)
• Security: security@zevop.com
• DPO: Izunna Ikewete — dpo@zevop.com

13. Change history¶

• 2026-05-20 — Initial profile published. Captures: deployment flows, domain registration as direct .ng registrar, ID Protection, Email Forwarding (with protective gates against auto-creating forwards and against replacing existing third-party mail setups), team-based access + audit, ZPIP integration with ZevWorkspace for DNS provisioning, Zev Credit participation (issues on refund, accepts on every invoice). Positioning: first Nigerian-operated managed-deployment platform with full tenant isolation, sitting between the local cPanel-shared-hosting model and the international managed-deployment platforms billed in USD.