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.
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
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.
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.
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, ... } } ```
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 failedrestoreFailed: A point-in-time restore failedverificationFailed: 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.
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 jobsverification-report: Per-tenant verification resultscompliance-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