Fix typos.

Thanks ChatGPT.

Author: rkistner

self-hosting/lifecycle-maintenance.mdx

@@ -75,7 +75,7 @@ For self-hosting, [nginx](https://nginx.org/en/) is always a good option. A basi
 ```yaml
 server {
     listen 443 ssl;
-    server_name powersync.example.prg;
+    server_name powersync.example.org;
 
     # SSL configuration here
 
@@ -108,7 +108,7 @@ If the load balancer supports health checks, it may be configured to poll the AP
 
 Occasionally, new versions of the PowerSync service image may require migrations on the underlying storage database. This is also specifically required the first time the service starts up on a new storage database.
 
-By default, migrations are run as part of the replication and API containers. In some cases, a migration may add signifant delay to the container startup.
+By default, migrations are run as part of the replication and API containers. In some cases, a migration may add significant delay to the container startup.
 
 To avoid this startup delay, the migrations may be run as a separate job on each update, before replacing the rest of the containers. To run the migrations, run the docker command `migrate up`, for example `docker run powersync migrate up`.
 

self-hosting/lifecycle-maintenance/migrating.mdx

@@ -9,6 +9,6 @@ In some cases, you may want to migrate users between PowerSync instances. This m
 
 If the PowerSync instances use the same source database and have the same basic configuration and sync rules, you can migrate users by just changing the endpoint to the new instance.
 
-To make this process easier, we recommend using an API to retrieve the PowerSync endpoint, intead of hardcoding the endpoint in the client application. If you're using custom authentication, this can be done in the same API call as getting the authentication token.
+To make this process easier, we recommend using an API to retrieve the PowerSync endpoint, instead of hardcoding the endpoint in the client application. If you're using custom authentication, this can be done in the same API call as getting the authentication token.
 
 There should be no downtime for users when switching between endpoints. The client will have to re-sync all data, but this will all happen automatically, and the client will atomically switch between the two. The main effect visible to users will be a delay in syncing new data while the client is re-syncing. All data will remain available to read on the client for the entire process.

self-hosting/lifecycle-maintenance/multiple-instances.mdx

@@ -11,7 +11,7 @@ Multiple instances are not required in most cases. See the [Overview](self-hosti
 
 When exceeding a couple thousand concurrent connections, the standard PowerSync setup may not scale sufficiently to handle the load. In this case, we recommend you [contact us](/resources/contact-us) to discuss the options. However, we give a basic overview of using multiple PowerSync instances to scale here.
 
-Each PowerSync "instance" is a single endpoint (URL), that is backend by:
+Each PowerSync "instance" is a single endpoint (URL), that is backed by:
 1. One replication container.
 2. Multiple API containers, scaling horizontally.
 3. One bucket storage database.
@@ -20,7 +20,7 @@ This setup is described in the [Overview](self-hosting/lifecycle-maintenance).
 
 To scale further, multiple copies of this setup can be run, using the same source database.
 
-## Mapping user -> PowerSync endpoint
+## Mapping users to PowerSync endpoints
 
 Since each PowerSync instance maintains its own copy of the bucket data, the exact list of operations and associated checksum will be different between them. This means the same client must connect to the same endpoint every time, otherwise they will have to re-sync all their data every time they switch. Multiple PowerSync instances cannot be load-balanced behind the same subdomain.