diff --git a/docs/byoc/faq.mdx b/docs/byoc/faq.mdx
new file mode 100644
index 00000000..a9fbd5ac
--- /dev/null
+++ b/docs/byoc/faq.mdx
@@ -0,0 +1,109 @@
+---
+title: "FAQ"
+sidebarTitle: "FAQ"
+description: "Frequently asked questions about Restate Cloud BYOC architecture, security, and operations."
+---
+
+## General
+
+
+ No. Restate never receives your cloud provider credentials. The deployment agent operates using an IAM role (AWS) or managed identity (Azure) within your account that you provision. Restate's control plane authenticates to your Kubernetes cluster using bearer tokens with limited RBAC permissions.
+
+
+
+ Not with the standard deployment model. The deployment agent requires outbound internet access to poll for jobs, and Restate's control plane requires access to your Kubernetes API. For environments with strict egress requirements, contact Restate to discuss private connectivity options (AWS PrivateLink, Azure Private Link).
+
+
+
+ Your Restate environments continue running — they are self-contained workloads. However, you will lose the ability to manage environments (create, update, delete, scale) through the Restate Cloud console. You can restore management by re-granting access.
+
+
+
+ AWS and Azure are generally available. GCP is coming soon. Regions are deployed on demand based on customer requirements — the infrastructure can be deployed in any region supported by EKS (AWS) or AKS (Azure).
+
+
+
+ Not currently. Restate's ability to offer SLAs on availability and patching relies on having complete control over the infrastructure configuration. An enterprise distribution for self-managed Kubernetes may come in the future.
+
+
+## Security
+
+
+ Multiple layers of defense:
+
+ 1. Kubernetes RBAC limits the control plane to RestateCluster CRD operations and namespace-scoped resources
+ 2. Network policies prevent pods from communicating outside their namespace
+ 3. No SSH access to nodes — all management is via the Kubernetes API
+ 4. Pod security contexts enforce non-root execution and read-only filesystems
+ 5. You retain full audit logs of all operations
+
+
+
+ Signing keys for request authentication are generated in-cluster and stored as Kubernetes Secrets within the environment's namespace. They never leave your cluster. For your own application secrets, use your existing secrets management solution (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, etc.).
+
+
+
+ Only operational metadata required for management:
+
+ - Pod health status and resource utilization metrics
+ - Environment configuration (non-sensitive)
+ - Cluster-level metrics for monitoring and alerting
+
+ Restate does **not** collect: application payloads, invocation data, stored state, customer secrets, or application logs.
+
+
+
+ Yes. You can mirror Restate images to your private registry (ECR, ACR, Artifactory) and configure the deployment to pull from there. This enables vulnerability scanning and policy enforcement through your existing container security tooling.
+
+
+
+ Restate is SOC 2 Type I certified, with a Type II audit underway.
+
+
+## Operations
+
+
+ The Restate control plane (management API) has a 99.9% uptime SLA. Customer workload availability depends on the deployment tier:
+
+ - **Single-node**: 99.9% (rolling updates require brief restart)
+ - **Multi-AZ HA**: 99.99% (survives single zone failure, zero-downtime updates)
+
+
+
+ Kubernetes upgrades are coordinated with you:
+
+ 1. Restate notifies you 30 days before your cluster's Kubernetes version reaches end-of-life
+ 2. Upgrades are scheduled during your preferred maintenance window
+ 3. Control plane upgrades first, then rolling node upgrades
+ 4. A rollback plan is documented before each upgrade
+
+
+
+ Operational metrics (containing no customer data) are sent to a metrics service managed by Restate, enabling proactive monitoring and alerting on cluster health.
+
+ Logs from Restate environments and other cluster components are stored inside the cluster. Environment logs are accessible to authenticated customers through the Restate Cloud console.
+
+
+## Disaster recovery
+
+
+ Multi-AZ configurations use:
+
+ - Synchronous replication across nodes (replication factor configurable per environment)
+ - Periodic persistent volume snapshots
+ - Periodic snapshots to cloud object storage (S3, GCS, or Azure Blob)
+
+ Single-node configurations rely on volume snapshots to cloud object storage.
+
+
+
+ | Scenario | RTO | RPO |
+ | :--- | :--- | :--- |
+ | Pod failure (HA) | < 60 seconds | 0 (synchronous replication) |
+ | Zone failure (HA) | < 60 minutes | 0 (synchronous replication) |
+ | Full cluster loss | 1-4 hours | Last object store snapshot (configurable) |
+
+
+
+ Cross-region replication is not currently supported in BYOC. For multi-region requirements, deploy separate environments in each region with application-level coordination.
+
diff --git a/docs/byoc/installation.mdx b/docs/byoc/installation.mdx
new file mode 100644
index 00000000..6747b502
--- /dev/null
+++ b/docs/byoc/installation.mdx
@@ -0,0 +1,122 @@
+---
+title: "Installation"
+sidebarTitle: "Installation"
+description: "How a Restate Cloud BYOC deployment is set up in your cloud account."
+---
+
+A BYOC region is a Restate Cloud data plane running in your cloud account. Setting one up is a collaborative process between you and Restate.
+
+## Requesting a BYOC region
+
+To get started, contact Restate with:
+
+- **Cloud provider**: AWS, Azure, or GCP
+- **Region**: the cloud provider region where you want the data plane deployed (e.g. `us-west-2`, `eu-west-1`, `eastus2`)
+
+Restate will provide:
+
+- **Foundation stack deployment instructions** — a CloudFormation quick-create URL (AWS), ARM template link (Azure), or equivalent for your provider
+- **Region secret key** — a one-time token that authenticates the deployment agent with Restate's control plane
+
+## Deploying the foundation
+
+The foundation is the only layer you deploy manually. It creates the networking, secrets store, and deployment agent in your account. The remaining layers are provisioned automatically.
+
+
+
+ Restate provides a **CloudFormation quick-create link** that pre-fills the template URL and stack name. The link looks like this:
+
+ ```
+ https://.console.aws.amazon.com/cloudformation/home
+ ?region=
+ #/stacks/quickcreate
+ ?templateUrl=
+ &stackName=restate-byoc-
+ ```
+
+ Opening this link takes you directly to the CloudFormation "Quick create stack" page.
+
+
+
+ The template URL is pre-filled. You can expand **View template** to inspect the resources that will be created.
+
+ The **stack name** is customizable — choose something meaningful to your team, such as `restate-byoc-production` or `restate-byoc-staging`.
+
+
+ 
+
+
+
+
+ Under **Application Secrets**, paste the **region secret key** provided by Restate. This key is used once to authenticate the deployment agent with Restate's control plane.
+
+ Leave the **Access Permissions** defaults as-is.
+
+
+ 
+
+
+
+
+ At the bottom of the page, check both IAM capability acknowledgement boxes. These are required because the template creates IAM roles for the deployment agent.
+
+ Click **Create stack**.
+
+
+ 
+
+
+
+
+ The stack creates:
+ - A VPC with public and private subnets across availability zones
+ - A secrets store (AWS Secrets Manager) for the region secret key
+ - The deployment agent (an EC2 Auto Scaling Group) with scoped IAM roles
+
+
+
+ Restate provides an **ARM template deployment link** that guides you through a similar process in the Azure Portal.
+
+ The template creates:
+ - A VNet with public and private subnets
+ - An Azure Key Vault for the region secret key
+ - The deployment agent (a Virtual Machine Scale Set) with scoped Azure role assignments
+
+
+ Azure installation details will be documented here as the guided onboarding flow is finalized. Reach out to Restate for current instructions.
+
+
+
+
+## Layer 2: Infrastructure
+
+Once the foundation is in place, the deployment agent automatically provisions:
+
+- A managed Kubernetes cluster (EKS on AWS, AKS on Azure)
+- A container registry for Restate component images
+- Certificate management (cert-manager with DNS validation)
+- Service mesh (Linkerd) for in-cluster mTLS
+- Network policies for workload isolation
+
+This step requires no action from you. The deployment agent pulls provisioning jobs from Restate's control plane and applies them using Terraform within your account.
+
+## Layer 3: Application
+
+After the infrastructure is ready, the following Restate data plane components are deployed into the cluster:
+
+- **Ingress proxy** — routes traffic from your services to Restate environments
+- **Tunnel** — enables connectivity between Restate and services in other VPCs or networks
+- **Restate operator** — manages Restate environment lifecycle (create, update, scale, delete)
+- **Monitoring** — metrics collection and log aggregation
+
+Once all three layers are deployed successfully, your BYOC region is activated and you can create Restate environments through the Restate Cloud console.
+
+## Ongoing updates
+
+After the initial deployment, Restate pushes updates to the infrastructure and application layers through the same deployment agent. Updates include:
+
+- Kubernetes version upgrades (coordinated with you in advance)
+- Restate component releases
+- Security patches and node OS updates (automated via drift detection)
+
+You do not need to re-deploy the foundation template for routine updates. Template updates are only needed when the foundation layer itself changes, which is rare.
diff --git a/docs/byoc/overview.mdx b/docs/byoc/overview.mdx
new file mode 100644
index 00000000..44f210fd
--- /dev/null
+++ b/docs/byoc/overview.mdx
@@ -0,0 +1,61 @@
+---
+title: "Restate Cloud BYOC"
+sidebarTitle: "Overview"
+description: "Run Restate Cloud in your own cloud account with full data sovereignty and network isolation."
+---
+
+Restate Cloud BYOC (Bring Your Own Cloud) lets you run Restate environments within your own cloud account while benefiting from Restate's managed control plane.
+Your data stays in your infrastructure, under your control.
+
+
+
+ Fully managed by Restate. No infrastructure to maintain. Best for getting started quickly.
+
+
+ Restate manages the data plane, but it runs in your cloud account. Data sovereignty, network isolation, and compliance.
+
+
+ You run and manage everything. Full control, full responsibility.
+
+
+
+## Why BYOC?
+
+BYOC is designed for organizations that need:
+
+- **Data sovereignty** — all data remains in your cloud account and chosen region
+- **Network isolation** — Restate workloads run in your VPC with no inbound access required
+- **Compliance** — meet policies that require workloads to remain within customer-controlled infrastructure
+- **Existing commitments** — use your cloud provider savings plans, reserved instances, and negotiated pricing
+
+## How it works
+
+A BYOC deployment has three layers:
+
+1. **Foundation** — You deploy a cloud-native template (CloudFormation on AWS, ARM on Azure) into your account. This creates the networking, secrets store, and a deployment agent that manages the rest of the infrastructure on Restate's behalf.
+
+2. **Infrastructure** — The deployment agent provisions a Kubernetes cluster, container registry, certificate management, and supporting infrastructure. This happens automatically after the foundation is deployed.
+
+3. **Application** — Restate data plane components are deployed into the cluster: the ingress proxy, tunnel, Restate operator, and monitoring stack. Environment creation, updates, and scaling are managed by Restate's control plane.
+
+The deployment agent uses an **egress-only polling model** — it reaches out to Restate's control plane to check for work, rather than receiving inbound commands. Restate never has direct inbound access to your infrastructure.
+
+
+For details on the security properties of each layer, see [Security Model](/byoc/security).
+
+
+## Supported cloud providers
+
+| Cloud Provider | Status |
+| :--- | :--- |
+| AWS | Generally available |
+| Azure | Generally available |
+| GCP | Coming soon |
+
+## Get started
+
+BYOC deployments are set up in collaboration with the Restate team. To get started:
+
+
+ Reach out to discuss your requirements and begin onboarding.
+
diff --git a/docs/byoc/security.mdx b/docs/byoc/security.mdx
new file mode 100644
index 00000000..7b434dbf
--- /dev/null
+++ b/docs/byoc/security.mdx
@@ -0,0 +1,170 @@
+---
+title: "Security Model"
+sidebarTitle: "Security"
+description: "How Restate Cloud BYOC secures the control channel, infrastructure, and customer data."
+---
+
+Restate Cloud BYOC is designed around three principles: **least privilege**, **egress-only connectivity**, and **customer ownership of infrastructure**. Restate never holds credentials to your cloud account.
+
+## Control channel
+
+The BYOC deployment has three network connections, all initiated from within your account:
+
+| Connection | Direction | Protocol | Purpose |
+| :--- | :--- | :--- | :--- |
+| Deployment agent → Restate control plane | Egress from your account | HTTPS (long-polling) | Pulls provisioning and management jobs |
+| Restate control plane → Kubernetes API | Inbound to cluster API endpoint | HTTPS with bearer token | Manages Restate environments (CRDs, namespaces) |
+| Metrics collector → Restate metrics store | Egress from your account | HTTPS | Ships operational metrics for monitoring and alerting |
+
+The deployment agent uses an **egress-only polling model** — it reaches out to Restate's control plane to check for work. Restate's control plane never initiates connections into your account for provisioning or management operations.
+
+Restate's control plane connects to your Kubernetes API to manage Restate environments. This connection uses a bearer token scoped to a limited Kubernetes RBAC role. You can restrict access to the Kubernetes API endpoint by IP allowlisting.
+
+### What crosses the control channel
+
+**Sent to your cluster:**
+
+| Category | Examples |
+| :--- | :--- |
+| Environment manifests | RestateCluster CRDs specifying resource limits, replicas, configuration |
+| Container image references | Image tags (pulled from registry by cluster, not transferred over control channel) |
+| Configuration | Restate server configuration (non-sensitive) |
+| Signing keys | Public keys for request authentication (stored as Kubernetes Secrets in-cluster) |
+
+**Received from your cluster:**
+
+| Category | Examples |
+| :--- | :--- |
+| Health status | Pod readiness, cluster status |
+| Resource metrics | CPU/memory usage, storage utilization |
+| Environment metadata | Version info, replica count |
+
+**What does NOT cross the control channel:**
+
+- Customer application data or invocation payloads
+- State stored in Restate
+- Customer secrets or credentials
+- Application logs (retained in your account)
+
+## Bootstrap security
+
+The foundation template is a standard CloudFormation stack (AWS) or ARM template (Azure) that you deploy yourself. It creates scoped roles for the deployment agent.
+
+
+
+ The CloudFormation template creates an IAM role for the deployment agent with the following permissions, scoped to the install's resources:
+
+ | Permission | Scope | Purpose |
+ | :--- | :--- | :--- |
+ | Resource management | Install resources | Create and manage EKS, VPC, S3, and supporting resources |
+ | EKS cluster admin | Install's EKS cluster | Deploy Helm charts and Kubernetes manifests via the Kubernetes API |
+ | Resource provider registration | Subscription (AWS account) | Register required AWS service providers |
+
+ All IAM roles follow least-privilege principles and are scoped to the resources created by the stack.
+
+
+
+ The ARM template creates a managed identity for the deployment agent (a Virtual Machine Scale Set) with the following role assignments:
+
+ | Role | Scope | Purpose |
+ | :--- | :--- | :--- |
+ | Contributor | Resource group | Create and manage AKS, VNet, storage, and supporting resources |
+ | Role Based Access Control Administrator | Resource group | Create downstream role assignments (Key Vault access, network, DNS) |
+ | Azure Kubernetes Service RBAC Cluster Admin | Resource group | Deploy Helm charts and Kubernetes manifests via Azure RBAC |
+ | Custom: resource provider registration | Subscription | Register required Azure resource providers (`*/register/action` only) |
+
+ The "Role Based Access Control Administrator" role is required because the deployment agent creates these downstream role assignments during infrastructure provisioning:
+
+ | Downstream role | Assigned to | Purpose |
+ | :--- | :--- | :--- |
+ | Key Vault Secrets User | AKS Secrets Store CSI driver | Mount the Restate region secret key from Key Vault into pods |
+ | Network Contributor | AKS cluster identity | Manage load balancers and network resources |
+ | DNS Zone Contributor | cert-manager identity | Create DNS records for TLS certificate validation |
+
+ All roles are scoped to the install's resource group, except the resource provider registration role which is subscription-scoped but limited to `*/register/action`.
+
+
+ "Role Based Access Control Administrator" is narrower than "Owner" — it can only manage role assignments, not create or delete resources. It is the minimum privilege required to create the downstream assignments listed above.
+
+
+
+
+## Infrastructure security
+
+### Compute
+
+Kubernetes clusters run on dedicated cloud-managed virtual machines:
+
+| Layer | AWS | Azure |
+| :--- | :--- | :--- |
+| Compute | EC2 instances (Nitro hypervisor) | Azure VMs (Hyper-V isolated) |
+| Container runtime | containerd | containerd |
+| Kubernetes | Amazon EKS (managed control plane) | Azure AKS (managed control plane) |
+| Architecture | ARM64 (Graviton / Ampere) | ARM64 (Ampere) |
+
+Instance security features include IMDSv2 enforcement (AWS), encrypted storage at rest (AES-256), and no local ephemeral storage (all data on network-attached volumes).
+
+### Patching
+
+| Component | Method | Frequency |
+| :--- | :--- | :--- |
+| Node OS | Automated drift detection | Within 24-48 hours of new AMI/image release |
+| Kubernetes | Managed cloud provider upgrades | Per provider schedule, coordinated with customer |
+| Restate components | Rolling deployment | As releases are published |
+| Container images | Image updates | As vulnerabilities are patched |
+
+Vulnerability response targets:
+
+| Severity | Response time | Resolution target |
+| :--- | :--- | :--- |
+| Critical (CVSS 9.0+) | 8 hours | 24 hours |
+| High (CVSS 7.0-8.9) | 24 hours | 7 days |
+| Medium (CVSS 4.0-6.9) | 72 hours | 14 days |
+| Low (CVSS < 4.0) | Best effort | Next maintenance window |
+
+## Network isolation
+
+Each BYOC deployment runs in its own VPC with private subnets across multiple availability zones. Restate environments are isolated via Kubernetes NetworkPolicies:
+
+- **Ingress**: only the ingress proxy and metrics collector can reach environment pods
+- **Egress**: DNS, peer nodes in the same namespace, allowlisted VPC endpoints, tunnel, and the public internet
+- **Cross-namespace**: blocked by default
+
+All in-cluster traffic between components is encrypted with mTLS via a service mesh.
+
+### Service connectivity
+
+Restate environments invoke your service handlers over HTTP. Supported connectivity patterns:
+
+| Pattern | How it works |
+| :--- | :--- |
+| VPC services | Private IP or internal load balancer via VPC endpoints. All traffic stays within the VPC. |
+| FaaS (Lambda) | Invoked via VPC endpoints with IAM authentication. No public internet traversal. |
+| Tunnel | For services in other VPCs or networks. Tunnel clients connect to the BYOC VPC via a VPC endpoint. |
+
+## Data sovereignty
+
+All customer data remains in your cloud account:
+
+- Invocation payloads, stored state, and snapshots never leave your account
+- Application logs are retained in-cluster and accessible to you
+- Restate collects only operational metadata (health, resource utilization, environment configuration) for monitoring and management
+
+### Audit
+
+| Log type | Location | Retention |
+| :--- | :--- | :--- |
+| Kubernetes audit logs | Your CloudWatch / Azure Monitor | Customer-controlled |
+| VPC flow logs | Your S3 / Azure Storage | Customer-controlled |
+| Application logs | In-cluster | Customer-controlled |
+| Control plane operations | Restate audit trail | Per Restate retention policy |
+
+## Customer controls
+
+| Action | Available? | Process |
+| :--- | :--- | :--- |
+| Revoke Restate access | Yes | Remove the Kubernetes bearer token; environments continue running but management is disabled |
+| IP-restrict cluster API | Yes | Configure Kubernetes API server allowlist |
+| Audit management operations | Yes | Kubernetes audit logs capture all control plane actions |
+| Request emergency patching | Yes | File a priority support ticket; Restate SLA applies |
+| Force node replacement | Yes | File a support ticket; completed within SLA |
diff --git a/docs/docs.json b/docs/docs.json
index 3b816827..c5051cda 100644
--- a/docs/docs.json
+++ b/docs/docs.json
@@ -220,6 +220,15 @@
"cloud/connecting-services"
]
},
+ {
+ "group": "Restate BYOC",
+ "pages": [
+ "byoc/overview",
+ "byoc/installation",
+ "byoc/security",
+ "byoc/faq"
+ ]
+ },
{
"group": "Self-hosted Restate",
"pages": [
diff --git a/docs/img/byoc/aws-quick-create-capabilities.png b/docs/img/byoc/aws-quick-create-capabilities.png
new file mode 100644
index 00000000..53f571d6
Binary files /dev/null and b/docs/img/byoc/aws-quick-create-capabilities.png differ
diff --git a/docs/img/byoc/aws-quick-create-params.png b/docs/img/byoc/aws-quick-create-params.png
new file mode 100644
index 00000000..7e3c03ee
Binary files /dev/null and b/docs/img/byoc/aws-quick-create-params.png differ
diff --git a/docs/img/byoc/aws-quick-create-start.png b/docs/img/byoc/aws-quick-create-start.png
new file mode 100644
index 00000000..a826f9de
Binary files /dev/null and b/docs/img/byoc/aws-quick-create-start.png differ