Architecture
How FalconCloud™ works
A thin control plane on edge workers orchestrates self-hosted Supabase stacks on your VM. Your data never touches our servers.
Layer diagram
┌─────────────────────────────────────────────────────────────┐
│ FalconCloud™ control plane │
│ (edge workers, this site) │
│ - Org/tenant/RBAC management │
│ - Provisioning worker (systemd, every 30s) │
│ - AI assistant (Mika) │
│ - Audit log + analytics │
└─────────────────────────────────────────────────────────────┘
│ HTTPS
▼
┌─────────────────────────────────────────────────────────────┐
│ Your VM (your data plane) │
│ Orchestrator (1 container) → runs Supabase stacks │
│ Each stack: Postgres + GoTrue + PostgREST + Storage │
│ + Realtime + Studio + Edge Functions │
│ Encrypted backups → S3-compatible store (your bucket) │
└─────────────────────────────────────────────────────────────┘
Control plane and data plane are separate. Your VM holds your data.
Provisioning flow
[UI: Create App]
│
▼
[provisioning_jobs INSERT]
│
▼
[systemd worker every 30s]
│
├── Orchestrator API: create stack (Postgres+Auth+Storage+Realtime)
├── Wait for healthchecks
├── Store secrets in vault (AES-256-GCM, per-stack HMAC)
└── Update app_environments.status = 'running'
Every app/environment goes through the same provisioning job queue.
Multi-tenant isolation
Every product row carries tenant_id.
RLS policy: tenant_id = current_setting('app.tenant_id')::uuid
Set by JWT claim on every request. No shared queries across tenants.
Row-level tenant_id enforced through RLS at every read.