Multi-tenant model
Synthetiq provisions shared cloud infrastructure that hosts apps across organizations. Apps share certain platform-level components (the compute cluster and network) but are isolated at the resource, access policy, and data layers. Access between app resources is governed by AWS IAM — the same identity and access management layer that underpins all AWS services and separates every AWS customer’s resources from one another. IAM is the foundation of AWS compliance certifications including SOC 2, ISO 27001, FedRAMP, and HIPAA, and is continuously audited by third parties.Isolation summary
| Resource | Isolation | Details |
|---|---|---|
| Compute | Dedicated | Firecracker microVMs with hypervisor-level isolation — dedicated kernel, CPU, and memory per app |
| Database | Dedicated | Separate database instance per app with unique credentials |
| Data storage | Dedicated | Separate storage per app, access restricted by IAM |
| Credentials and secrets | Dedicated | Separate credential store per app containing database connections, OAuth config, and encryption keys |
| Logs | Dedicated | Separate log stream per app, access restricted by IAM |
| Builds and deployments | Dedicated | Untrusted steps run in ephemeral VMs with dedicated, narrowly scoped roles per app |
| Container registry | Scoped | Shared registry with per-app image tagging; push access scoped by IAM |
| Artifact storage | Scoped | Shared storage with per-app path isolation enforced by IAM |
| Metrics API | Scoped | Shared metrics endpoint with per-app namespace scoping enforced by IAM |
| Load balancer | Scoped | Shared load balancer with per-app routing rules; traffic routed to each app’s dedicated and physically isolated backend targets |
| Compute cluster | Shared | All apps run on the same managed cluster |
| Network | Shared | All apps share the same private network |
Dedicated per app
Each of these resources is provisioned separately for every app. Access is enforced by IAM policies scoped to that app’s resources.Compute
Each app runs inside dedicated Firecracker microVMs — lightweight virtual machines that provide hypervisor-level isolation with a dedicated kernel per app. Unlike traditional container isolation where workloads share a host kernel, each app gets its own kernel, CPU allocation, and memory. Even in the event of a container escape, the workload remains confined to its own microVM. Each app’s microVMs run under a dedicated IAM role that restricts access to only that app’s storage, credentials, log streams, and metrics namespace. Worker containers (for background workflows) are similarly isolated in their own dedicated microVMs with their own IAM roles.Database
Each app gets its own database instance with unique credentials:- Each app gets a separate database project with its own connection strings
- Credentials are stored in a dedicated credential store per app, accessible only to that app’s containers and build pipeline
Data and credentials
- Data storage: Each app gets a separate storage resource. IAM policies ensure only that app’s containers and build roles can read or write to it.
- Credentials: Database connections, OAuth client credentials, and a per-app AES-256-GCM encryption key are stored in a dedicated credential store, accessible only to that app.
- Logs: Each app writes to its own log stream. Application logs, worker logs, and build logs are all separated per app.
Builds and deployments
Any deployment step that executes app code is treated as untrusted. These steps run in their own ephemeral VMs with dedicated, narrowly scoped roles that can only access that app’s artifacts, credentials, and infrastructure. Build environments are provisioned fresh for each deployment and destroyed after completion — no build state persists between deployments.Shared with scoped access
These are shared platform components where IAM policies restrict each app to its own slice of the resource.- Container registry: All apps share the same registry. Images are tagged per app, and IAM restricts push access to each app’s own image tags.
- Artifact storage: Build and deployment artifacts are stored in shared storage. IAM policies restrict each app to its own path prefix.
- Metrics: A shared metrics endpoint serves all apps, but IAM enforces that each app can only query its own metrics namespace.
- Load balancer: A single load balancer routes traffic using subdomain-based rules. Each app’s subdomain maps to that app’s dedicated and physically isolated backend targets — there is no cross-app routing.
Shared infrastructure
These platform-level components are shared across all apps:- Compute cluster: All apps run on the same managed cluster. Resource allocation (CPU, memory) is enforced per app via container-level limits.
- Network: All apps share the same private network. Containers run in private subnets with outbound internet access.
Network-level isolation between app containers is not enforced. Security between apps relies on IAM policies, resource separation, and hypervisor boundaries rather than network segmentation. If your requirements mandate network-level tenant isolation, contact us to provision a private environment for your organization, or consider a Bring Your Own Infrastructure deployment where your organization uses your existing cloud account.
Traffic protection
All inbound traffic to Synthetiq-hosted apps is protected by application-layer firewall rules, providing:- DDoS protection
- Bot detection and mitigation
- Rate limiting
- Common web exploit filtering (SQL injection, cross-site scripting, etc.)
Encryption and credential management
Data encryption
- At rest: All stored data — including databases, credentials, artifacts, and logs — is encrypted at rest using AES-256.
- In transit: External traffic is encrypted via TLS 1.2 or higher. Internal traffic between the load balancer and application containers travels over a private network within the VPC.