Aeion OS Platform — Enterprise Multi-Tenant Infrastructure

In a normal SaaS ecosystem, when one company's system needs to notify another's, someone builds webhooks (Zapier/Make) or a custom API integration. Aeion replaces that with Digital Alliances: two tenants sign a data contract, and approved events flow directly between their real-time event streams — instantly, with no integration code on either side.

What it looks like:

• Autonomous supply chain — a manufacturer updates a wholesale price; the commerce.product.updated event crosses the alliance and triggers the retailer's workflow to re-price their storefront. No nightly sync, no API polling.
• Franchise network — corporate hits "DEFCON 2"; the crisis.defcon.escalated event broadcasts to 500 franchisee tenants at once, locking down each local system — without 500 API calls.
• Agency ↔ client — an agency uploads a campaign asset; the vault.document.created event refreshes the live-preview panel in the client's separate workspace in real time.

How it stays safe (the zero-trust airlock): federation requires an active, signed contract that names the provider, the consumer, and an explicit allowedEvents whitelist (exact or wildcard, e.g. logistics.shipment.*). When an event qualifies, the payload is deep-cloned to sever all references to the provider's objects, re-stamped with the consumer's tenant ID, and tagged federatedFrom so its origin is traceable. Three guarantees are structural, not configurable: federated events are read-only signals (the provider can never write to the consumer's data — the consumer's own workflows decide what to do), reflection loops are impossible (a federatedFrom event is never re-federated), and system.* / platform.* / cron.* events are hard-blocked at the router even if someone tries to whitelist them.

Upgrading: the moment a customer confirms an upgrade, their new plan's entitlements are granted immediately — no waiting for the next billing cycle to unlock a feature they just paid for. The change is logged and propagates instantly to every module that checks entitlements.

Cancelling: by default, a cancelling customer keeps full access through the end of the period they already paid for, then suspends cleanly — never cut off mid-cycle for something they paid for. An immediate-cancellation option is available too, for cases where a customer wants access to stop right away.

Reactivating: un-cancelling restores active status and resumes anything that was suspended in one step — no manual cleanup required.

Payment webhooks: successful renewal payments extend the billing period automatically; a failed payment moves the account to past-due, fires a notification, and kicks off a dunning sequence — so a declined card starts a recovery flow instead of silently lapsing.

The problem Aegis solves: Before Aegis, database restore was a blunt instrument — you could restore a full backup or nothing. If a bug corrupted 5 minutes of data across 3 tables at 2:47 AM, you had to choose between losing a full backup's worth of data or keeping the corruption.

Aegis solution: Point-in-time recovery. Restore to any second between the oldest full backup and now — not just the nearest nightly snapshot — with a selective, table-level extract path available when a full restore is more than what's needed.

Bulk undo: an event-store-based safety net that stays read-only until an operator explicitly confirms the action — nothing changes as a side effect of just reviewing what would be undone.

Honest by design: if point-in-time recovery isn't configured yet on a given deployment, the system says so plainly rather than pretending a restore worked. No silent failures, no false green checkmarks.

Spinning up a new tenant — server, domain, entitlements — runs as a background job with automatic retry: up to 3 attempts recover from transient failures before anything is flagged for manual attention. Provisioning covers the full lifecycle: creating the tenant, provisioning the server, setting up the domain, granting entitlements, and handling suspend/resume/upgrade transitions as they happen.

VPS providers: Hetzner Cloud, Contabo, DigitalOcean, and Vultr today, through a provider-agnostic interface designed to add more without disrupting existing tenants.

Self-healing on stuck instances: instances that get stuck mid-provision are automatically polled and flipped to active the moment the underlying provider confirms they're actually up — nobody has to babysit a deploy — checking up to 100 at a time.

Instance lifecycle: every instance moves cleanly through pending → provisioning → active, with suspend, upgrade, and downgrade all resuming back to active from a consistent state — no dead ends.

The problem: A tenant on a Professional real-time plan has 2,000 call minutes/month. They run a long all-hands meeting that uses 1,900 minutes. Without auto-upgrade, the remaining 100 minutes lasts about 10 more minutes — then the meeting gets cut off mid-sentence.

The fix: usage is monitored continuously against the plan's allowance. The moment a live session threatens to exceed it, the tenant is upgraded to the next tier automatically — mid-meeting, without interrupting the call — and notified afterward by email, Slack, or webhook. Bill shock happens after the fact in an invoice, never mid-sentence in a live call.

Configurable per plan: each tier defines its own call-minute allowance and the exact usage threshold (e.g. 80%) that triggers the auto-upgrade, plus which tier it upgrades to — so the safety margin can be tuned per plan rather than being one-size-fits-all.