Getting Started with Aeion Platform

Configure platform plans, manage subscriptions, set up VPS provisioning, configure Aegis point-in-time restore, set up backup verification, and configure tenant notifications — all in Aeion OS.

1

Define Platform Plans

Navigate: Platform → Plans → New Plan

Plans define what tenants get at each tier. Entitlements are the key — they control which modules are active, what rate limits apply, and what real-time tiers are available:

json { "name": "Business", "slug": "business", "tier": "business", "monthlyPrice": 299, "annualPrice": 2691, "billingCycle": "monthly", "entitlements": [ { "extensionId": "crm", "maxRecords": 50000 }, { "extensionId": "collab", "realtime": { "maxCallMinutes": 5000, "autoUpgradeThreshold": 0.8 } }, { "extensionId": "baas", "active": true }, { "extensionId": "platform", "backupRetentionDays": 90 } ] }

Entitlements control:

  • Module activation (crm, collab, baas, spatial, etc.)
  • Record limits per collection
  • Real-time tier (maxCallMinutes, autoUpgradeToPlan)
  • Backup retention windows (7/30/90+ days)
  • API rate limits

Plan hierarchy:

Starter → Professional → Business → Enterprise (see /plans for pricing) 1,000 records 10,000 records 50,000 records unlimited 500 call mins 2,000 call mins 5,000 call mins custom 30-day backup 30-day backup 90-day backup 90+ day backup

2

Configure VPS Providers

Navigate: Platform → Provisioning → VPS Providers

VPS provisioning is provider-pluggable — each supported host (Hetzner, Contabo, DigitalOcean, Vultr) implements the same create/suspend/resume/delete/status contract, so tenant provisioning behaves identically regardless of which host a tenant's server runs on.

Hetzner configuration:

json { "provider": "hetzner", "apiKey": "{{HETZNER_API_KEY}}", "defaultRegion": "us-east", "defaultPlan": "cx22", "sshKeyIds": ["key-123"] }

Contabo configuration:

json { "provider": "contabo", "apiKey": "{{CONTABO_API_KEY}}", "defaultRegion": "us-east", "defaultPlan": "vps-s" }

Add a new provider: Additional VPS hosts (Linode, AWS, and others) can be added behind the same provider contract — new hosts plug in without changing how plans, tenants, or provisioning jobs work.

3

Set Up Backup Configuration

Navigate: Platform → Backup → Configure

Backup policy, scheduling, and job execution are managed per tenant via a backupConfig:

json { "tenantId": "tenant_01J8X", "schedule": "daily", "time": "02:00", "timezone": "UTC", "retention": { "daily": 7, "weekly": 4, "monthly": 12 }, "storage": { "backend": "s3", "region": "us-east-1", "bucket": "aeion-backups-prod", "prefix": "tenant_01J8X/" }, "verifyWeekly": true, "complianceMode": "soc2" }

Storage backends: S3 (AWS), GCS (Google Cloud), Azure Blob, local.

Compliance mode: soc2 or iso27001 — affects which compliance report artifacts are generated and how they're formatted.

4

Configure Aegis Point-in-Time Restore

Navigate: Platform → Aegis → Configure

Aegis is the point-in-time recovery system. It goes beyond simple backup restore — you can restore to any second between your oldest backup and now.

pgbackrest setup (standard SaaS):

```bash # 1. Install pgbackrest on the DB server # 2. Create stanza pgbackrest stanza-create --stanza=aeion \ --pg1-path=/var/lib/postgresql/data

# 3. Configure in Platform AEGIS_PITR_ENABLED=true AEGIS_PITR_STANZA=aeion AEGIS_PITR_ADAPTER=pgbackrest # default ```

External Postgres setup (customer-managed):

bash # When customer manages their own Postgres AEGIS_PITR_ADAPTER=external # The external adapter defers to your own PITR tooling for the actual # point-in-time recovery, while Aegis still tracks status and orchestrates # the restore workflow around it.

Selective table restore: Restore just the tables you need at a specific point in time — instead of the whole database — via a sidecar Postgres process that extracts and merges only what you ask for:

typescript // Restore specific tables to their state at a specific timestamp await aeion.api.post("/platform/aegis/pitr/restore", { mode: "selective", targetTime: "2026-05-11T02:47:00Z", tables: [ { schema: "public", name: "crm_contacts" }, { schema: "public", name: "crm_deals" }, ], });

Full restore workflow:

```typescript // Start a point-in-time restore (in-place — brings the whole tenant DB // back to the target time; this causes brief downtime) await aeion.api.post("/platform/aegis/pitr/restore", { mode: "in_place", targetTime: "2026-05-11T02:47:00Z", });

// A pre-restore safety snapshot is always taken automatically first, // so you can roll back if something goes wrong.

// Check PITR status const status = await aeion.api.get("/platform/aegis/pitr/status"); // { data: { enabled: true, lastBaseBackupAt: "...", streaming: true, ... } } ```

5

Set Up Tenant Notifications

Navigate: Platform → Tenants → [Tenant] → Notifications

Failure events fan out to email, Slack, or webhook based on tenant.config.notifications.aegis.*:

json { "notifications": { "aegis": { "backupFailed": { "email": true, "slack": true, "webhook": "https://hooks.slack.com/services/xxx/yyy/zzz" }, "restoreFailed": { "email": true, "slack": true, "webhook": null }, "verificationFailed": { "email": true, "slack": false, "webhook": null } } } }

What gets notified:

  • backupFailed: A scheduled backup didn't run or failed
  • restoreFailed: A point-in-time restore failed
  • verificationFailed: Weekly restore-and-verify test failed

Honest no-op: If no destinations are configured, no pages are sent. Silent notification failure is the mode this closes.

6

Set Up Compliance Reporting

Navigate: Platform → Compliance → Monthly Reports

Each month, Platform generates a SOC2/ISO27001 evidence package per tenant:

typescript // Monthly rollup { "month": "2026-04", "tenantId": "tenant_01J8X", "backupCount": 30, "verificationCount": 4, "verificationPassRate": 1.0, "totalBackupSizeGb": 847, "retentionCompliance": true, "artifacts": [ { "type": "backup-log", "url": "s3://...", "generatedAt": "2026-05-01T00:00:00Z" }, { "type": "verification-report", "url": "s3://...", "generatedAt": "2026-05-01T00:30:00Z" }, { "type": "compliance-summary", "url": "s3://...", "generatedAt": "2026-05-01T01:00:00Z" } ] }

Artifacts uploaded to: Same S3 bucket as backups (BYOB). Auditors get access via pre-signed URLs.

Report types:

  • backup-log: Chronological list of all backup jobs
  • verification-report: Per-tenant verification results
  • compliance-summary: Executive summary of backup health

Provisioning Flow — How a New Tenant Gets Created

Calling `POST /platform/tenants` kicks off the full creation pipeline:

POST /platform/tenants { name, slug, planId, region, domain } ↓ 1. Tenant record created (status: "provisioning") ↓ 2. Provisioning jobs queued, in order: - create_tenant - provision_server (region + plan from the request) - setup_domain (domain from the request) - grant_entitlements (from the selected plan) ↓ 3. 202 Accepted returned immediately — jobs run asynchronously ↓ 4. A daily sweep processes pending jobs in order. A failed job retries up to 3 times before being marked "failed" and surfaced to the tenant + platform operators.

Real-time auto-upgrade flow:

Tenant on "Professional" plan (2,000 call minutes/mo) → Usage monitored every 5 minutes → Usage hits 80% threshold (1,600 minutes) → Auto-upgrade to "Business" (5,000 call minutes) triggered → Tenant notified: email + slack + webhook → platform.subscription.auto_upgraded event emitted

Enterprise Infrastructure — From Plan to Provisioned Tenant