Admin Portal — Staff Manual

ZenexCloud WordPress Hosting

Also available as a downloadable Word document.

Introduction

The Admin Portal is the internal control panel for ZenexCloud staff — the equivalent of WHM for a traditional cPanel host. From here, staff manage every hosting account: creating, suspending, migrating, and terminating sites; DNS and SSL for the whole fleet; backups and restores; billing-platform integration; and staff access itself.

Every account here has real customers and real billing behind it. Actions like Terminate, Restore, and Reissue SSL have real, sometimes irreversible consequences. Read each confirmation dialog before clicking through it.

Roles & Permissions

Every staff member has exactly one role, controlling both sidebar visibility and what the server will actually allow — hiding a page is a convenience, the server enforces the same boundary independently.

Role	Access
Admin	Full access to everything, including staff accounts and platform-wide settings.
Support	Accounts, backups, domains, terminal — day-to-day client help. No billing/infrastructure configuration.
Operations	Servers, DNS, SSL, object storage, queue — infrastructure. No client account access.
Readonly	Can view everything. Cannot change anything, anywhere.

A deactivated staff account, or one whose role just changed, is enforced on the very next request — not just at their next login.

Signing In & Two-Factor Authentication

Sign in with your staff email and password. If 2FA is enabled, you'll be asked for a live authenticator code as a second step.

To set up 2FA: Settings → Two-factor authentication at the top of the page. Scan the QR code (or enter the manual key), then confirm with a live code to turn it on.

Overview

Fleet health at a glance, auto-refreshing every few seconds: fleet health %, active sites, pending provisioning, accounts in transition, open alerts, a live server-health table, and a recently-created feed.

Accounts

The master list of every hosting account — the single most-used page for day-to-day support.

Per-account actions (⋯ menu):

Log in as client — opens the Client Portal signed in as that account's owner.
Reset portal password… — no email sent; hand the new password to the client yourself.
Suspend / Unsuspend — actually stops/restarts the real Vultr VM.
Enable / Disable staging.
Migrate region… — new server, site copied over, then DNS repointed. Old server stays live throughout; nothing changes if it fails.
Change package… — resizes the existing server in place. Brief real downtime. Smaller-disk moves aren't supported — use Migrate region.
PHP settings… — same tier-capped limits a client can edit themselves.
Start VM / Stop VM, and Terminal.
Terminate — permanently deletes the server, block storage, and DNS record. Cannot be undone.

A stuck-provisioning account shows a dedicated Retry provisioning icon — reuses the same account row.

Creating a New Account

Accounts → New account. Bypasses the normal billing-platform order flow — for emergency ops, not routine use. Fields: client name, subdomain, optional reseller assignment, plan, region, storage (read-only, fixed per plan), Daily Backup/Staging/DDoS checkboxes, and WordPress admin email/username/password.

Packages

Read-only reference for Basic/Standard/Premium: vCPU, RAM, disk, bandwidth, staging availability, and live active-account counts per tier. High availability is shown honestly as "planned — not yet built."

Servers

One row per live Vultr instance: site, IP, region, plan, Vultr instance ID, agent version, status. Read-only.

DNS

A direct editor for the platform's own Cloudflare zone — the same zone every account's subdomain lives in.

Changes apply immediately, no staging step. Deleting the wrong record can break a live client site instantly.

Add a record: type (A/AAAA/CNAME/TXT/MX/NS), name, content, priority (MX only), and proxied (A/AAAA/CNAME only). There's no in-place edit yet — delete and re-add.

SSL

Fleet-wide, live TLS-handshake check for every domain across every account. Stat cards: verified, expiring within 30 days, cert-check failures, Cloudflare zone mode (informational only — real certs are Let's Encrypt direct-to-origin). Per-row Reissue.

Backups

Fleet-wide view. Stat cards: total backups, total storage, failures in 24h.

Per-backup actions: Restore to existing VM (active accounts only, overwrites current site), Restore to new VM… (works for active or terminated accounts, no auto-invoice), Delete backup (permanent).

Restoring provisions real, billable Vultr infrastructure. Treat as an admin-level action.

Object Storage

A bucket browser grouped by account, including terminated accounts' folders. Breadcrumb navigation, per-file Download (temporary signed link).

Database (Client Sites)

A per-account SQL console — search/pick an account, then run raw SQL directly against their site database, or Open in phpMyAdmin. A Production/Staging toggle switches environment if staging exists.

No confirmation step before running a query. A destructive query runs immediately, exactly as written.

Platform DB

Same console shape, but for the platform's own database.

Read-only by design — SELECT only. Every query is audited.

A table browser pre-fills a "SELECT * ... LIMIT 50" query. A separate Open phpMyAdmin (full read/write) button exists for when read-only genuinely isn't enough — use deliberately.

Activity

Every job every agent has ever run, across the fleet — the operational job log. Filter by status/kind. A failed job also raises a platform notification.

Queue Manager

Narrower than Activity — account lifecycle operations only (provisioning, terminate, suspend/unsuspend, VM power, migrate region, restore-to-new-VM), with live progress bars.

Audit Logs

Every mutating action platform-wide — actor, action, target, metadata, timestamp. The accountability/compliance trail, distinct from Activity.

Resellers

Promote/demote any account to reseller status, with an optional brand name. Each reseller row shows their scoped account count. A reseller can get their own scoped Provisioning Key so their billing platform only sees their own fleet.

Branding

White-labels both portals at once, even pre-login: brand name, logo, and favicon — each with its own Replace/Remove control.

Provisioning Keys

Credentials a billing platform (WHMCS today) uses to talk to the Provisioning API. New key: name, optional IP allowlist, optional reseller scope.

The secret is shown exactly once at creation. It cannot be retrieved again — copy it immediately.

Per key: edit IP allowlist, Revoke (immediate real effect, row kept for history), or Delete permanently (only once revoked).

Admin Users

New admin user: email, temporary password (10+ characters, handed to them directly — nothing emailed), and role. Per-row: reset password, activate/deactivate, delete.

A staff member can never change their own role, deactivate, or delete themselves. The platform's last active admin can't be removed by anyone.

Settings

Every integration credential, grouped by service: Platform, Vultr, Cloudflare, WHMCS, SMTP, Object Storage. Each field shows Saved/From .env/Not set plus a masked value — saved values are encrypted at rest and take priority over the server's own .env.

SMTP includes Send a test email; Object Storage includes Test connection. The Two-factor authentication panel at the top is per-admin, controlling your own account's 2FA.

Terminal

A real root shell over a live WebSocket, straight to a specific client's VM — not a curated command list. Opened per-account from the Accounts page.

This is genuine root access to a live customer's server. Use it the same way you'd SSH into any production box you don't own personally.

Common Support Workflows

A client can't remember their WordPress admin login

Accounts → the account → ⋯ → Log in as client, then use App Service's Change password form on their behalf.

A client's site is stuck "provisioning"

Check for the warning icon, then use Retry provisioning — no new order needed.

A theme/plugin import keeps timing out

Accounts → the account → ⋯ → PHP settings…, and raise the relevant limits within the shown range for their plan.

A client needs their site moved to a different region

Accounts → the account → ⋯ → Migrate region… The old server stays live throughout.

A client needs yesterday's site back

Backups → find the most recent good backup → Restore to existing VM, or Restore to new VM… to inspect first.

A new staff member is starting

Admin Users → New admin user, choosing the narrowest role that covers their actual work.

Getting Help

For anything not covered here, escalate to an Admin-role staff member or the platform's engineering contact, with the account's Service ID or subdomain and a clear description of what was attempted.