Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
109 changes: 109 additions & 0 deletions docs/byoc/faq.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,109 @@
---
title: "FAQ"
sidebarTitle: "FAQ"
description: "Frequently asked questions about Restate Cloud BYOC architecture, security, and operations."
---

## General

<Accordion title="Does Restate have access to my AWS/Azure credentials?">
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.
</Accordion>

<Accordion title="Can I run BYOC in an air-gapped environment?">
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).
</Accordion>

<Accordion title="What happens if I revoke Restate's access?">
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.
</Accordion>

<Accordion title="What cloud providers and regions are supported?">
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).
</Accordion>

<Accordion title="Can I bring my own Kubernetes cluster?">
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.
</Accordion>

## Security

<Accordion title="How do you prevent lateral movement if the control plane is compromised?">
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
</Accordion>

<Accordion title="How are secrets managed?">
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.).
</Accordion>

<Accordion title="What data does Restate collect from my environments?">
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.
</Accordion>

<Accordion title="Can I use my own container registry?">
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.
</Accordion>

<Accordion title="Do you have SOC 2 certification?">
Restate is SOC 2 Type I certified, with a Type II audit underway.
</Accordion>

## Operations

<Accordion title="What uptime can be achieved?">
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)
</Accordion>

<Accordion title="How are Kubernetes version upgrades handled?">
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
</Accordion>

<Accordion title="What monitoring is included?">
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.
</Accordion>

## Disaster recovery

<Accordion title="How is data backed up?">
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.
</Accordion>

<Accordion title="What is the RTO/RPO for disaster recovery?">
| 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) |
</Accordion>

<Accordion title="Can I replicate across regions?">
Cross-region replication is not currently supported in BYOC. For multi-region requirements, deploy separate environments in each region with application-level coordination.
</Accordion>
122 changes: 122 additions & 0 deletions docs/byoc/installation.mdx
Original file line number Diff line number Diff line change
@@ -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.

<Tabs>
<Tab title="AWS">
Restate provides a **CloudFormation quick-create link** that pre-fills the template URL and stack name. The link looks like this:

```
https://<region>.console.aws.amazon.com/cloudformation/home
?region=<region>
#/stacks/quickcreate
?templateUrl=<template-url>
&stackName=restate-byoc-<your-name>
```

Opening this link takes you directly to the CloudFormation "Quick create stack" page.

<Steps>
<Step title="Review the template">
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`.

<Frame>
<img src="/img/byoc/aws-quick-create-start.png" alt="CloudFormation Quick create stack form showing the pre-filled template URL and stack name" />
</Frame>
</Step>

<Step title="Enter the region secret key">
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.

<Frame>
<img src="/img/byoc/aws-quick-create-params.png" alt="CloudFormation parameters showing the region token input and access permission defaults" />
</Frame>
</Step>

<Step title="Acknowledge capabilities and create">
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**.

<Frame>
<img src="/img/byoc/aws-quick-create-capabilities.png" alt="CloudFormation capabilities checkboxes and Create stack button" />
</Frame>
</Step>
</Steps>

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
</Tab>

<Tab title="Azure">
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

<Info>
Azure installation details will be documented here as the guided onboarding flow is finalized. Reach out to Restate for current instructions.
</Info>
</Tab>
</Tabs>

## 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.
61 changes: 61 additions & 0 deletions docs/byoc/overview.mdx
Original file line number Diff line number Diff line change
@@ -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.

<CardGroup cols={3}>
<Card title="Restate Cloud" icon="cloud">
Fully managed by Restate. No infrastructure to maintain. Best for getting started quickly.
</Card>
<Card title="BYOC" icon="cloud-arrow-down">
Restate manages the data plane, but it runs in your cloud account. Data sovereignty, network isolation, and compliance.
</Card>
<Card title="Self-hosted" icon="server">
You run and manage everything. Full control, full responsibility.
</Card>
</CardGroup>

## 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.

<Info>
For details on the security properties of each layer, see [Security Model](/byoc/security).
</Info>

## 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:

<Card title="Contact Restate" icon="envelope" href="https://restate.dev/contact">
Reach out to discuss your requirements and begin onboarding.
</Card>
Loading
Loading