Security & Maintenance

Every day-2 operation runs over a typed, scoped Admin Proxy — not SSH. This page covers the management plane, server actions, CVE and maintenance tooling, engine upgrades, and the suspend/terminate lifecycle.

1. The Admin Proxy management plane

Each server runs a scoped Admin Proxy that WHMCS reaches over HTTPS (port 9098 by default) with the server’s own secret and the WHMCS service scope. The server’s firewall admits the Admin Proxy ports only from the WHMCS server IPs set under Settings → General & Access. Requests carry the service id, a request ID, and the standard Core request headers, and every call is audited. The proxy exposes a fixed set of typed endpoints under /admin/v1/ — there is no free-form shell:

Endpoint family	Purpose
health, metrics, log/bootstrap	Health, live metrics, and the bootstrap log.
config/apply, bootstrap/apply, tls/reissue	Apply runtime config (e.g. maxmemory), re-apply the server’s bootstrap, and reissue the Admin Proxy’s TLS certificate.
service/restart|suspend|unsuspend	Restart the engine, or fence/unfence the service.
credentials/rotate|revoke	Rotate or revoke the AUTH password.
allowlist/apply	Push the current IP allowlist as firewall rules.
flush	Flush all keys.
snapshot/create|restore|delete	Create, restore, and prune snapshots.
valkey/upgrade	Swap the Valkey binaries for an engine upgrade.
tenants/…	The same operations for one tenant on a shared pool box.
security/status|apply-updates, system/reboot	Security posture, OS updates, and reboot.

SSH is break-glass only

SSH is a labelled HIGH RISK legacy/rescue path, off by default (Settings → General & Access → Break-Glass Access), and never part of a normal workflow. Config drift and reapplies go through the typed config-apply and bootstrap re-apply endpoints, not an SSH rebuild. Arbitrary shell over the Admin Proxy is forbidden.

2. Server Actions console

Operations → Server Actions is the console for typed Admin Proxy operations against a chosen server. Pick a server and an operation, add the required confirmation text for destructive actions, and run it:

Operation	Effect	Scope
Health Check	Calls the server’s health endpoint and updates the local timestamp.	Box-level
Refresh Metrics	Pulls a fresh metrics sample from the server.	Box-level
Fetch Bootstrap Log	Retrieves the server’s bootstrap log for diagnosis.	Box-level
Restart Valkey	Restarts the engine.	Per-service
Reissue TLS	Reissues the Admin Proxy’s TLS certificate (a self-signed one is regenerated and re-pinned).	Box-level
Apply Allowlist	Pushes the current IP allowlist as firewall rules.	Per-service
Create Snapshot	Takes a snapshot of the cache.	Per-service
Apply Security Updates	Applies OS security updates.	Box-level
Reboot VPS	Reboots the server (requires typing REBOOT).	Box-level
Flush Cache	Flushes all keys (requires typing FLUSH).	Per-service

Only online, degraded, suspended, offline, and provision-failed servers are eligible — in-flight builds are excluded so operations never interfere with a bootstrap mid-run. Shared pool boxes support box-level operations only; per-service operations are disabled for them. Flush and reboot are confirmation-gated, and every server action writes both a local and a Core audit entry.

3. Security posture & maintenance windows

Operations → Security and Operations → Maintenance surface ImpulseCore’s shared security and maintenance tooling for Valkey servers: tracked CVEs for the Valkey engine, maintenance-window scheduling, and deferrable patches. Security posture is read and applied over the Admin Proxy’s security/status and security/apply-updates endpoints — the same typed, audited management plane as everything else.

Customers see matching Security and Maintenance tabs on both dedicated and shared services, plus a critical-CVE banner on their overview when applicable. On a shared plan the Security tab shows that patching is handled at the host level, with no patch actions of its own.

4. Snapshots & restore

A snapshot saves the cache’s dump on the Valkey server itself — the dedicated server, or the shared pool box — and records its target, size, and expiry. The snapshot-export cron takes one every hour for each online service, and each is kept for the hourly retention (24 hours by default, under Settings → Snapshots). A snapshot the customer or you create by hand is kept for 7 days. Expired snapshots are deleted from the server by the same cron.

Snapshots stay on the server

Settings → Snapshots also holds an operator S3-compatible fallback, a per-region bucket can be set on each region, and the module prefers a storage (ImpulseObjects) service in the customer’s ImpulseCore project. In this release those are only recorded as each snapshot’s target: no snapshot is copied off the server, so a snapshot doesn’t survive the loss of the server it was taken on. The Daily retention setting has no daily snapshots to apply to yet.

Restore scope differs by model

On dedicated services a snapshot still on the server can be restored in place — by the customer from the Snapshots tab, or by you from the snapshot browser under Settings → Snapshots; both ask for the word RESTORE, and restoring replaces the cache’s current contents. Shared-plan snapshots have no restore action in the client area or the addon; the client area tells the customer to open a support ticket.

5. Engine upgrades

Because Valkey holds the data, an engine upgrade is a data-migration: an in-place binary swap and restart, gated by a snapshot. The flow starts on the Infrastructure tab, where a server running behind the pinned default version offers an upgrade:

1. Request an upgrade to the target version from the server’s row or detail view.
2. Approve the request under Operations → Upgrade Requests — or, for dedicated servers, turn on auto-approve upgrade requests (HIGH RISK) under Settings → Runtime & Cache.
3. The upgrade cron picks a dedicated server’s upgrade up within the service’s maintenance window, or you click Run now in the queue. A running upgrade can’t be cancelled.

The executor takes a mandatory pre-upgrade snapshot (on a shared pool box, one for every tenant), pushes the upgrade over the Admin Proxy, re-reads the server’s reported Valkey version, and commits — or rolls back if the version gate fails.

Shared pool boxes

An upgrade on a shared pool box restarts every tenant on it: each tenant’s cache is flushed and reloaded from disk. Shared upgrades always need your approval (auto-approve is ignored) and run on the next cron tick once approved, without waiting for a maintenance window. If one fails, the rollback reinstalls the previous Valkey version but does not restore tenant data from the pre-upgrade snapshots. Validate the upgrade path against a test server before relying on it in production.

6. Suspension & termination lifecycle

Suspend fences the engine; terminate fences it too. Both start a 7-day grace window — the customer is warned 2 days before it ends — and a service still suspended or terminated when it ends is permanently deleted.

Suspend / unsuspend

Suspending stops the Valkey engine over the Admin Proxy (Valkey has no read-only mode, so the engine stop is the fence) and marks the row suspended. Unsuspend restarts the engine and returns the service to online. If the server doesn’t answer and doesn’t confirm the change, the suspend or unsuspend fails in WHMCS with the reason, so WHMCS never shows a state the server isn’t in. Shared tenants are fenced the same way — the unit is stopped, disabled, and its port closed.

Terminate

Termination is a fence, not an immediate destroy. On terminate the service is fenced exactly as suspend does, the row parks as pending_purge, and the service detaches from its Core project so dashboards stop showing it. A fence the server doesn’t confirm never blocks the termination; it is recorded in the audit log. Nothing is deleted yet — the data, credential rows, the Core connection secret, and the VPS or tenant all survive the grace window so a restore is possible.

Destruction is owned by Core

Once the grace expires, ImpulseCore’s lifecycle-purge cron runs the hard purge — server-side teardown, slot release (for shared), and secret wipe. Restoring during grace is a WHMCS unsuspend or unterminate, which unfences the service.

7. Alerts & audit

Under Settings → Alerts & Notifications, opt in per alert type and set recipients and a re-notify interval. Available alert types: oversold servers (warning and critical), server operation failures, eviction pressure, cron overdue, provision failures, license expiring, and self-signed TLS. An alert-detection cron (hourly) evaluates these and emails one digest per run, through ImpulseCore’s shared mailer configured under Settings → Email Delivery (falling back to the platform default until a provider is set). This module sends operator and admin notifications only.

Diagnostics → Activity shows the module’s audit trail — when, source, action, service, and detail — mirrored locally and into Core.