Skip to content

Cloud Platform Architecture ​

Scope: This section covers the Phony Cloud platform — Database Sync, Snapshots, Mock API, and packages. For the core data generation system (PGDL, generators, N-gram), see Data Generation Architecture.

Implementation status

Everything in this section is target design — nothing cloud-side is built yet. The Rust engine, CLI, and PGDL are the built parts; the control plane, agent orchestration, and hosted services described here do not exist.

The Defining Idea: Local-First ​

Phony Cloud is split into a thin, hosted control plane and a data plane that runs entirely inside the customer's infrastructure. The control plane sees only metadata — schemas, column classifications, job status, report artifacts. Production row data never reaches Phony's servers.

┌─────────────────────────────────────────────────────────────────────────┐
│                 CONTROL PLANE / DATA PLANE ARCHITECTURE                  │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  PHONY CLOUD (control plane — hosted)                                    │
│  ┌─────────────────────────────────────────────────────────────────────┐│
│  │  Dashboard · Orchestration & scheduling · Job state                 ││
│  │  PII inventory · Audit log · Compliance reports (KVKK/GDPR)         ││
│  │  Team / RBAC / SSO · Notifications · Snapshot catalog (metadata)    ││
│  │                                                                     ││
│  │  Sees: schemas, column classifications, job status, reports.        ││
│  │  Never sees: row data, credentials, trained models, snapshots.      ││
│  └──────────────────────────────▲──────────────────────────────────────┘│
│                                 │ outbound-only gRPC/HTTPS               │
│                                 │ (no inbound tunnels into customer      │
│                                 │  infrastructure — ever)                │
│  CUSTOMER INFRASTRUCTURE (data plane)                                    │
│  ┌──────────────────────────────┴──────────────────────────────────────┐│
│  │                     PHONY AGENT (Rust binary)                        ││
│  │                                                                     ││
│  │  Schema introspection · PII detection · Anonymization/synthesis     ││
│  │  (local engine + locally trained models) · Writes to target DBs     ││
│  │  Snapshots → CUSTOMER storage (local disk / their S3-GCS)           ││
│  │                                                                     ││
│  │  ┌──────────┐   ┌──────────┐   ┌───────────────────────────┐        ││
│  │  │ Prod DB  │   │Staging DB│   │ Customer S3/GCS/disk      │        ││
│  │  │ (PII)    │   │ (no PII) │   │ (snapshots, models)       │        ││
│  │  └──────────┘   └──────────┘   └───────────────────────────┘        ││
│  └─────────────────────────────────────────────────────────────────────┘│
│                                                                          │
│  HOSTED EXCEPTION: the Mock API serves SYNTHETIC data only, so it is     │
│  safe to host on Phony's edge — no customer row data is involved.        │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Why local-first ​

  • Trust as the selling point. The blocker in every anonymization deal is "send us your production database." Phony never asks: the data plane runs where the data already lives, so the KVKK/GDPR posture is structural, not contractual.
  • No hosted-infra COGS for data work. Generation and sync compute run on customer machines, so the free tier carries essentially no infrastructure cost and gross margin sits around 92–93%.
  • Models stay home. N-gram models trained on customer data are trained by the agent and stored in customer infrastructure; the cloud sees only their name and hash.
  • Enterprise is the same architecture, extended. Air-gapped Enterprise = a fully self-hosted control plane. No special fork — just move the thin metadata layer inside too.

Pricing follows the architecture: the value metric is connected data sources; generation, users, agents, and environments are never metered. See Pricing.

The Four Pillars ​

PillarWhere it runsDocumentation
Database SyncData plane — the agent reads, anonymizes, and writes inside your network; the cloud orchestrates and receives metadataDatabase Sync
SnapshotsData plane, BYO storage — snapshot data in your disk/S3/GCS; the cloud keeps the catalog (ids, hashes, lineage)Snapshots
Mock APIHosted — the one cloud-served surface, safe because it serves synthetic data only (plus a free local phony mock start)Mock API
PackagesGit-based, decentralized — the hosted registry design is supersededPackage Manager

Note on packages: the original Package Registry design (a centralized hosted registry) has been superseded by the git-based package manager — packages are plain git repos, fetched directly, with no registry infrastructure to run.

What the Control Plane Actually Sells ​

The data plane is where the work happens; the control plane is what the paid tiers sell:

CapabilityWhat it is
OrchestrationScheduling, triggers, job chains across agents
VisibilityPII inventory across all connected sources, job history, audit trail
Compliance artifactKVKK/GDPR report packs — the thing an engineering leader shows their boss
TeamRBAC, SSO, notifications

Security Model ​

  1. Structural privacy — row data cannot leak from the cloud because it is never there; the boundary is architectural, not policy.
  2. Outbound-only agent — the agent dials out to the control plane; no inbound ports, tunnels, or peering into customer networks.
  3. Metadata encryption — TLS in transit; schemas, classifications, and report artifacts encrypted at rest (AES-256).
  4. Credentials stay local — database and storage credentials are agent-side configuration; the cloud never holds them.
  5. Audit — complete audit trail of control-plane actions for compliance (SOC2, GDPR/KVKK).

Phony Cloud — Documentation & Specification