Deployment concept

app/authzed/concepts/deployments/page.mdx

@@ -0,0 +1,51 @@
+---
+title: "Deployments"
+description: "A single, independently-scaled SpiceDB cluster that serves a Permission System from one region."
+---
+
+import { Callout } from "nextra/components";
+
+# Deployments
+
+A Deployment is a single running SpiceDB cluster that serves a Permission System from one region.
+
+Every Permission System is made up of one or more Deployments, each sharing the same underlying [Datastore].
+In the simplest case, a Permission System has exactly one Deployment running in one region.
+Adding more Deployments lets the same Permission System serve traffic from additional regions at once — see [Multi-Region Deployments].
+
+[Datastore]: ../../spicedb/concepts/datastores
+[Multi-Region Deployments]: multi-region
+
+## Deployments vs. Permission Systems
+
+A Permission System is the logical authorization system: its schema, its relationships, and the datastore that stores them.
+A Deployment is the compute that actually serves requests for that Permission System from a specific region.
+
+This split is why a single Permission System can run in multiple regions without duplicating data: each Deployment is a separate SpiceDB cluster, but all of a Permission System's Deployments read from and write to the same datastore.
+
+## What you configure per Deployment
+
+When you add a Deployment to a Permission System, you choose:
+
+- **Name** — how the Deployment is identified in the Management Dashboard.
+- **Region** — where the SpiceDB cluster runs.
+- **vCPUs** — the amount of compute allocated to each replica.
+- **Replicas** — how many SpiceDB instances serve the Deployment. More replicas increase availability and read throughput.
+
+<Callout type="info">
+  The vCPUs and replicas you configure here are for **SpiceDB's compute** — the layer that serves Check, LookupResources, and other API requests.
+  They are separate from the compute provisioned for your [Datastore], which scales independently based on data volume and read/write load.
+
+If requests are slow or timing out, check which side is the bottleneck before resizing: high SpiceDB CPU or request queuing points to under-provisioned Deployment vCPUs, while slow query latency at the datastore points to the datastore needing more resources instead.
+
+</Callout>
+
+Each Deployment exposes its own endpoint.
+There is no global endpoint that automatically routes requests to the nearest Deployment — your workloads should connect to the endpoint of the Deployment closest to them to minimize latency.
+
+## Workload isolation
+
+Deployments on AuthZed Dedicated and Cloud run on hardware dedicated to your organization, separate from the shared control plane services (such as the Management Dashboard and observability tooling).
+See [Workload Isolation] for details.
+
+[Workload Isolation]: workload-isolation

app/authzed/concepts/multi-region/page.mdx

@@ -5,8 +5,9 @@ description: "A collection of SpiceDB deployments located in different regions w
 
 # Multi-Region Deployments
 
-Multi-Region Deployments are a collection of SpiceDB deployments that can be located in various regions across the world, but that all share a single [Datastore].
+Multi-Region Deployments are a collection of [Deployments] that can be located in various regions across the world, but that all share a single [Datastore].
 
+[Deployments]: deployments
 [Datastore]: ../../spicedb/concepts/datastores
 
 ## Connecting to a region

app/authzed/guides/cloud/page.mdx

@@ -30,6 +30,12 @@ Sign in to [AuthZed Cloud](https://app.authzed.cloud) and click on the **+Create
   - Choose the number of vCPUs for your deployment. The recommendation is to start with 2 vCPUs and then monitor the Metrics and change it based on your workload.
   - Choose the number of replicas to deploy SpiceDB with primarily read workloads. The recommendation is 3 but will depend on your latency requirements.
 
+<Callout type="info">
+  These vCPUs provision **SpiceDB's compute**, not your datastore's. See [What you configure per
+  Deployment](/authzed/concepts/deployments#what-you-configure-per-deployment) for how the two scale
+  independently.
+</Callout>
+
 ## Configuring Access
 
 Before using the Permissions System, let's configure access to it.

lib/changed-pages.json

@@ -1,44 +1,11 @@
 {
-  "/materialize/api/client-sdks": {
-    "status": "updated"
-  },
-  "/materialize/api/download-permission-sets": {
-    "status": "new"
-  },
-  "/materialize/api/lookup-permission-sets": {
-    "status": "updated"
-  },
-  "/materialize/api/watch-permission-sets": {
-    "status": "updated"
-  },
-  "/materialize/concepts/hydration": {
-    "status": "new"
-  },
-  "/materialize/concepts/managing-client-state": {
-    "status": "updated"
-  },
-  "/materialize/concepts/permission-set-lifecycle": {
-    "status": "updated"
-  },
-  "/materialize/concepts/permission-sets": {
-    "status": "updated"
-  },
-  "/materialize/concepts/snapshots": {
-    "status": "updated"
-  },
-  "/materialize/concepts/watched-permissions": {
+  "/authzed/concepts/deployments": {
     "status": "new"
   },
-  "/materialize/getting-started/limitations": {
-    "status": "updated"
-  },
-  "/materialize/getting-started/overview": {
-    "status": "updated"
-  },
-  "/materialize/guides/recommended-architecture": {
+  "/authzed/concepts/multi-region": {
     "status": "updated"
   },
-  "/materialize/guides/relational-database": {
+  "/authzed/guides/cloud": {
     "status": "updated"
   }
 }