typos

Author: defnull

docs/install.rst

@@ -6,7 +6,7 @@ Installation
 
 There are several ways to deploy BBBLB:
 
-* **Docker Compose:** Run BBBLB, `Postgres <hhttps://www.postgresql.org/>`_ and `Caddy <https://caddyserver.com/docs/install#docker>`_ on a single VM with `docker compose <https://docs.docker.com/compose/>`_. This is the recommended way to get started and is suitable for most production deployments. 
+* **Docker Compose:** Run BBBLB, `Postgres <https://www.postgresql.org/>`_ and `Caddy <https://caddyserver.com/docs/install#docker>`_ on a single VM with `docker compose <https://docs.docker.com/compose/>`_. This is the recommended way to get started and is suitable for most production deployments. 
 * **Kubernetes:** Let's be honest, most deployments do not actually benefit from the added complexity of Kubernetes, but if you absolutely need redundancy or high availability, this is the way to go. If you are in that position, you probably know already how to pull this of and won't need a tutorial. Good luck! (PRs welcome)
 * **Manual:** If you hate containers and already have a Postgres database server and front-end web server up and running, you could also run BBBLB with systemd and connect the dots yourself. While not recommended, that's absolutely possible.
 * **Standalone:** BBBLB *can* run as a standalone application with an embedded HTTP(S) server (uvicorn) and database (sqlite). While this is nice for quick tests and development, it is not the recommended way to run BBBLB in production.

docs/recording.rst

@@ -2,7 +2,7 @@ Recording Internals
 ===============================
 
 In a cluster setup, recordings usually do not stay on the BBB nodes
-there were created on, but are transferred to the loadbalancer and made
+they were created on, but are transferred to the loadbalancer and made
 available via the same URL users and applications use to access the
 cluster. Here is how that works.
 
@@ -83,7 +83,7 @@ Recover from a crash
 
 The importer will pick up all tasks from the
 ``{PATH_DATA}/recordings/inbox/`` directory on startup, so even after a
-crash, the is usually no need to intervene. If you notice that some
+crash, there is usually no need to intervene. If you notice that some
 files in the inbox directory are not processed after a crash, follow
 these steps:
 
@@ -130,7 +130,7 @@ an already imported recording, delete it first.
 
 Next, the database entries for the recording and individual playback
 formats are created. If they already exists, they are not updated. The
-frontend may have already published or updated the recording, we to not
+frontend may have already published or updated the recording, we do not
 want to overwrite those changes. To actually replace an already imported
 recording, delete it first.