Fix typos. (#570)

docs/pages/concepts/clusters.mdx

@@ -15,7 +15,7 @@ This allows you to run each cluster on a different network or VPC.
 
 Clusters are identified by the hostname through which they will be accessed.
 
-For example, when drones beloning to the cluster `c1.mysite.com` run backends, those backends will
+For example, when drones belonging to the cluster `c1.mysite.com` run backends, those backends will
 be accessible through URLs that begin with `https://c1.mysite.com/...`.
 
 Plane proxies associated with the `c1.mysite.com` will expect inbound traffic to have the `Host`

docs/pages/concepts/session-backends.mdx

@@ -9,7 +9,7 @@ Typically, an application will start a session backend in response to some user
 away from that document, or closes the browser tab.
 
 Unlike a traditional web backend server, session backends are not expected to be stateless
-or interchangable. Instead, session backends provide a way to guarantee that every
+or interchangeable. Instead, session backends provide a way to guarantee that every
 request from a particular user (or group of users) is handled by the same process, and
 no other requests are.
 

docs/pages/deploy-to-prod.mdx

@@ -50,7 +50,7 @@ machine.
 If you are exposing the controller to the public internet, you should configure a reverse proxy to restrict traffic to the `/pub/*`
 path prefix.
 
-Here’s an example of what this could look like if you use nginx as a revese proxy:
+Here’s an example of what this could look like if you use nginx as a reverse proxy:
 
 ```text filename="nginx.conf"
 http {
@@ -102,7 +102,7 @@ configuration that allows them to connect to arbitrary ports on the drones in th
 Proxies also need to be able to accept incoming connections from the public internet on port 443, and forward them to the drones.
 If a network is called `c1.mysite.com`, either the `A` record or an equivalent `CNAME` record for `c1.mysite.com` should point to
 the proxy. Additionally, if subdomains are used, the `A` record or `CNAME` record for `*.c1.mysite.com` should also point to the
-proxys for that cluster.
+proxies for that cluster.
 
 The way you will configure this depends on whether you have more than one proxy, and whether you are using a managed load balancer.
 

docs/pages/developing/keys.mdx

@@ -11,7 +11,7 @@ A **key configuration** (`KeyConfig`) consists of:
 
 Namespaces and (especially) tags are advanced features; for most users, supplying **only the name** is sufficient.
 
-Tags are useful for sharing a key space between non-interchangable backends. For example, if you have two different programs that read from the same blob store, you can give each a different tag to ensure that a connect request for one does not return the other.
+Tags are useful for sharing a key space between non-interchangeable backends. For example, if you have two different programs that read from the same blob store, you can give each a different tag to ensure that a connect request for one does not return the other.
 
 ## Key Semantics
 
@@ -66,4 +66,4 @@ The drone is responsible for asking the controller to renew its key before its e
 
 ## Revocation
 
-If, when attempting to start a backend, its key has already expired, Plane will revoke the key by deleting it from the database (`KeysDatabase::remove_key`).
+If, when attempting to start a backend, its key has already expired, Plane will revoke the key by deleting it from the database (`KeysDatabase::remove_key`).

docs/pages/index.mdx

@@ -13,7 +13,7 @@ import Logo from '../components/logo'
     <a href="https://github.com/drifting-in-space/plane"><img src="https://img.shields.io/github/stars/drifting-in-space/plane?style=social" alt="Plane GitHub Repo" /></a>
 </div>
 
-Plane is a distributed system for **running stateful WebSocket backends at scale**. Plane is heavily inspired by [Figma’s mulitplayer infrastructure](https://www.figma.com/blog/rust-in-production-at-figma/), which dynamically spawns a process for each active document.
+Plane is a distributed system for **running stateful WebSocket backends at scale**. Plane is heavily inspired by [Figma’s multiplayer infrastructure](https://www.figma.com/blog/rust-in-production-at-figma/), which dynamically spawns a process for each active document.
 
 Use cases include:
 - Scaling up [authoritative multiplayer backends](https://driftingin.space/posts/you-might-not-need-a-crdt).

docs/pages/plane-api.mdx

@@ -57,7 +57,7 @@ The connect request is a `POST` request that takes a JSON body. An example paylo
   (forcing a new backend to start).
 - `spawn_config`: Optional configuration that is used to start a new backend if necessary.
 - `user`: Optional string to associate with the user on whose behalf this request is being made.
-- `auth`: Optional key-value map of unforgable data (such as claims) that you would like to pass to the
+- `auth`: Optional key-value map of unforgeable data (such as claims) that you would like to pass to the
   backend about this user.
 
 At least one of `key` or `spawn_config` must be provided. If only `spawn_config` is provided, the connect call

docs/pages/quickstart-guide.mdx

@@ -64,7 +64,7 @@ Here’s a breakdown of the command above:
   returning.
 
 <Callout type="info">
-  At least one of `--key` or `--image` must be provided, but it is not neccesary to include both.
+  At least one of `--key` or `--image` must be provided, but it is not necessary to include both.
 
   If you **only** want to connect to an existing backend, you can provide `--key` only. If a
   backend with the given key is not running, Plane will return an error.