ReferenceAsk
Remy Reference/Architecture/Architecture/Topology
01Architecture

Topology

The platform's tiers, its components, and the connections between them.

This is the overview; every other chapter details one part of it, so read it first. The diagram brief at the end collects every component and connection into one figure.

Remy is one platform image running as a set of roles on a trusted Kubernetes cluster, in front of a managed data plane, with app code running in microVMs on a second, untrusted cluster in a second VPC. Cloudflare is the edge for everything a browser touches. Every AI model call, every database query, and every managed capability an app uses is a call back into the platform.


#The Tiers

The edge. Cloudflare Workers terminate every request for a deployed app, the editor, and the public sites. One Worker resolves the hostname to an app and reverse-proxies to the platform; another fronts dev-box previews; others rewrite hosts for the API, WebSocket, git, files, image and video CDNs. Custom domains arrive through Cloudflare for SaaS with TLS issued automatically. Public assets are cached at the edge.

The platform. One container image, started with a --role flag, deployed as separate Kubernetes Deployments on the trusted cluster: the HTTP API, the WebSocket server, the general and bulk worker fleets, the git server, the app-database service, the inbound mail server, the sandbox proxy, the provisioner, and the sandbox orchestrator. The voice worker is its own image. An internet-facing Application Load Balancer with a TLS 1.3 FIPS policy fronts the HTTP, WebSocket, git, and sandbox-proxy roles; a Network Load Balancer fronts SMTP.

The data plane. Aurora PostgreSQL through RDS Proxy as the system of record. Valkey for cache, pub/sub, and coordination. S3 in four regions for app databases, files, git mirrors, build artifacts, and workspace snapshots. Qdrant for vector retrieval, shared and dedicated. A Kinesis Firehose stream into an Object-Locked S3 bucket for the audit log. KMS for every key.

The execution islands. A second VPC and a second EKS cluster where all app code runs. Three node groups, one per island: release sandboxes serving deployed apps, job runners compiling releases, and dev boxes leased to people in the editor. Every sandbox is a Kata microVM. The sandbox orchestrator on the trusted cluster creates and watches these pods across a VPC peering that admits exactly three ports.

The model layer. Every model call leaves through the platform's model service. First-party providers are reached over the internet through the NAT gateways. Amazon Bedrock is reached over a PrivateLink interface endpoint so inference traffic never leaves the AWS network. Tuned models serve from a vLLM pool on a GPU node group in the trusted cluster.

Outbound services. Amazon SES for outbound email with a tenant per app. LiveKit and Telnyx for voice. OAuth providers and third-party APIs, each declared in the counterparty registry with its hosts and data boundary.

Observability. New Relic APM, Sentry, and OpenTelemetry from every role. CloudWatch Container Insights on the untrusted cluster. GuardDuty with EKS runtime monitoring, CloudTrail, VPC flow logs, pgaudit on the database, and S3 access logs on private buckets.

The full inventory of these components, with where each runs, what it talks to, and where it is defined, is in the Component Inventory appendix. Every connection between them, with its protocol and direction, is in the Connection Matrix appendix.

What This Gives an App
Its code runs in its own microVM, in a different VPC and cluster from the platform.
Its data lives in its own database file, in the region its workspace chose.
Every capability it uses passes through the platform, where it is authorized, metered, and logged.
Its users reach it through a global edge, on the platform's apex or its own domain.
DiagramFIG. 01.1 — THE SYSTEM
USERSEDGETRUSTED VPCUNTRUSTED VPCEXTERNALBrowserCLIExternal senderswebhooks · email · phoneCloudflare Workersproxies · frontendsCloudflare for SaaSIngressALB · HTTPS TLS1.3 · NLB SMTPEKS workloads17 servicesHTTP · WS · Workers · Git · Sandbox-proxyProvisioner · Orchestrator · Voice · InspectionQdrant · Model-serving · Trainer (GPU)Data planeAurora←RDS Proxy · Valkey · S3 ×4 · CloudFront ×4SQS ×6 · Firehose→Object-Lock S3 · KMSVPC endpointsS3 gateway · Bedrock PrivateLinkEKS · Kata nodeskata_appsrelease sbxkata_jobsjob runnerskata_devdev boxesBedrockvia PrivateLinkFirst-party providersSES · LiveKit · TelnyxOAuth · CounterpartiesONE-WAY TRUST BOUNDARY (VPC PEERED)3 ports · one-waydetail → Fig 01.2egress → internet only
request flowtrust boundary · one-way crossingegress (internet only)VPC / trust zone
The platform in five tiers. Groups show counts, not full component lists; the full inventory is in the Component Inventory appendix. Fig 01.2 details the trust boundary between the two VPCs and its three one-way crossings.
DiagramFIG. 01.2 — THE TRUST BOUNDARY
TRUSTED VPCUNTRUSTED VPCSandbox orchestratorEKS workloadHTTPrelease launcherSandbox-proxydev-box brokerALBpublic front doorHTTPS · TLS 1.3Untrusted K8s APIcontrol planeRelease sandboxkata_appsDev boxkata_devJob runnerskata_jobs · via K8s APIONE-WAY TRUST BOUNDARY (VPC PEERED)PEERING443 · k8s apiworker portdev-box portegress: internet only · private ranges deniedcallbacks (db · hooks · models) re-enter via public HTTPS at the ALB, never across the boundary
The boundary, blown up. Three ports cross it, all one-way from the trusted side. The untrusted VPC has no inbound path and no return across the peering link; even a sandbox’s callbacks leave to the internet and re-enter through the public front door like any external client.

Lanes, left to right: Users | Edge | Trusted VPC | Untrusted VPC | External Users: Browser, CLI, external senders (webhooks, email, phone) Edge: Cloudflare Workers (agent-subdomain-proxy, sandbox-preview-proxy, host-rewrite Workers, frontends), Cloudflare for SaaS Trusted VPC: ALB (HTTPS, TLS 1.3 FIPS) and NLB (SMTP) EKS: HTTP · WS · Worker (general) · Worker (bulk) · Git · App-db · Mail-inbound · Sandbox-proxy · Provisioner · Sandbox-orchestrator · Voice worker · Content inspection · Qdrant (shared, dedicated) · Model serving (GPU) · Trainer (GPU) Data: Aurora PostgreSQL ← RDS Proxy · Valkey · S3 ×4 regions · CloudFront ×4 · Firehose → Object-Locked S3 · SQS ×6 · KMS Endpoints: S3 gateway, Bedrock PrivateLink Untrusted VPC: EKS with three Kata node groups: kata_apps (release sandboxes) · kata_jobs (job runners) · kata_dev (dev boxes) Egress: internet only, all internal ranges denied External: Bedrock (via PrivateLink) · first-party model providers · SES · LiveKit · Telnyx · OAuth providers · registered counterparties Arrows (label each with protocol): Browser → Edge → ALB → HTTP/WS/Git/Sandbox-proxy HTTP → Sandbox-orchestrator → Untrusted K8s API (443, over peering) HTTP → Release sandbox (worker port, over peering) Release sandbox → HTTP callback origin (HTTPS): db query, hooks, models Sandbox-proxy → Dev box (dev-box port, over peering) Roles → Aurora/Valkey/S3/SQS/Firehose Model service → Bedrock (PrivateLink) · → providers (NAT) Worker → SES · Internet → NLB → Mail-inbound S3 → SNS → SQS (file scan) → Worker → Content inspection Trust boundary: a heavy line between the two VPCs, crossed by exactly three ports.