Skip to main content

​
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 GCP are generally available; Azure is in preview. Regions are deployed on demand based on customer requirements — the infrastructure can be deployed in any region supported by EKS (AWS), GKE (GCP), 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

Availability depends on the deployment topology you choose:
  • Single-node: lower cost; rolling updates require a brief restart
  • Multi-AZ HA: survives a single availability-zone failure with zero-downtime updates
Specific availability targets are agreed as part of your plan. Reach out to discuss SLAs for your deployment.
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.
Offboarding is a two-step teardown coordinated with Restate:
  1. Restate deprovisions the application and infrastructure layers (environments, cluster, and supporting resources) through the deployment agent.
  2. You delete the foundation stack (CloudFormation on AWS, or the equivalent on GCP/Azure), which removes the deployment agent, networking, and secrets store from your account.
Because everything runs in your account, you can independently confirm that no Restate-managed resources remain. Take any final snapshots or data exports before teardown, since object-store data in your account is removed with the foundation stack.

​
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.
Recovery behavior depends on topology:
  • Pod failure (HA): another replica takes over with no data loss (synchronous replication)
  • Zone failure (HA): the environment continues from replicas in surviving zones with no data loss
  • Full cluster loss: the environment is restored from the most recent object-store snapshot; the recovery point is the snapshot interval (configurable)
Concrete recovery objectives are agreed as part of your plan.
Cross-region replication is not currently supported in BYOC. For multi-region requirements, deploy separate environments in each region with application-level coordination.