diff --git a/apps/docs/content/guides/self-hosting/custom-email-templates.mdx b/apps/docs/content/guides/self-hosting/custom-email-templates.mdx index 694ab393496..12b778f6cb6 100644 --- a/apps/docs/content/guides/self-hosting/custom-email-templates.mdx +++ b/apps/docs/content/guides/self-hosting/custom-email-templates.mdx @@ -98,7 +98,7 @@ services: ### Step 3: Restart containers ```sh -docker compose up -d --force-recreate --no-deps auth templates-server +sh run.sh recreate auth templates-server ``` ## Notification email templates @@ -171,5 +171,5 @@ services: ### Step 3: Restart containers ```sh -docker compose up -d --force-recreate --no-deps auth templates-server +sh run.sh recreate auth templates-server ``` diff --git a/apps/docs/content/guides/self-hosting/docker.mdx b/apps/docs/content/guides/self-hosting/docker.mdx index d986ed6b3ae..b07fa0f9c61 100644 --- a/apps/docs/content/guides/self-hosting/docker.mdx +++ b/apps/docs/content/guides/self-hosting/docker.mdx @@ -353,10 +353,10 @@ curl http://:8000/functions/v1/hello Add new functions at `volumes/functions//index.ts`, then restart the service to pick them up: ```sh -sh run.sh recreate functions +sh run.sh restart functions ``` -This force-recreates the container (equivalent to `docker compose up -d --wait --force-recreate --no-deps functions`). A plain `docker compose restart` is not sufficient as it does not pick up configuration changes. +The main worker loads each function from disk per request, so a restart is enough to pick up new or changed function code. Use `sh run.sh recreate functions` instead when you change environment variables or secrets (for example `.env.functions` or the service's `environment:` block), since those are only applied when the container is recreated. See the [Self-hosted Edge Functions](/docs/guides/self-hosting/self-hosted-functions) guide for more details. @@ -414,18 +414,18 @@ The `config add` / `config remove` commands manage the `COMPOSE_FILE` [variable] ## Updating -We publish stable releases of the Docker Compose setup approximately once a month. The versions in each release are tested together, so they may lag behind the latest images on Docker Hub. To update, apply the latest changes from the repository and restart the services. If you want to run different versions of individual services, you can change the image tags in the Docker Compose file, but compatibility is **not guaranteed**. All Supabase images are available on [Docker Hub](https://hub.docker.com/u/supabase). +We publish stable releases of the Docker Compose setup approximately once a month. The versions in each release are tested together, so they may lag behind the latest images on Docker Hub. To update, apply the latest changes from the repository, then stop and start the services. If you want to run different versions of individual services, you can change the image tags in the Docker Compose file, but compatibility is **not guaranteed**. All Supabase images are available on [Docker Hub](https://hub.docker.com/u/supabase). To follow the changes and updates, refer to the self-hosted Supabase [changelog](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md). Make sure to also check the [GitHub Discussions](https://github.com/orgs/supabase/discussions/categories/changelog?discussions_q=is%3Aopen+category%3AChangelog+label%3Aself-hosted). -After updating the configuration, you need to restart services to pick up the changes, which may result in downtime for your applications and users. +After updating the configuration, stop and start the stack or individual services to pick up the changes. This may result in downtime for your applications and users. For example, you'd like to update or rollback the Studio image. Follow the steps below: 1. Check the [supabase/studio](https://hub.docker.com/r/supabase/studio/tags) images on [Supabase Docker Hub](https://hub.docker.com/u/supabase) 2. Find the latest version (tag) number. It looks something like `2026.04.27-sha-5f60601` 3. Update the Studio `image` configuration in the `docker-compose.yml` file. It should look like this: `image: supabase/studio:2026.04.27-sha-5f60601` -4. Run `sh run.sh pull` to pull the new image, then `sh run.sh recreate studio` to restart Studio from it without taking down the rest of the stack. +4. Run `sh run.sh pull` to pull the new image, then `sh run.sh recreate studio` to update Studio without taking down the rest of the stack. ## Uninstalling @@ -503,7 +503,7 @@ To change the database password after the initial setup, run: sh utils/db-passwd.sh ``` -The script generates a new password, updates all database roles, and modifies your `.env` file. After running it, restart the services with: +The script generates a new password, updates all database roles, and modifies your `.env` file. After running it, stop and start the services with: ```sh sh run.sh recreate diff --git a/apps/docs/content/guides/self-hosting/enable-mcp.mdx b/apps/docs/content/guides/self-hosting/enable-mcp.mdx index e2517d0624d..13b0ceb71db 100644 --- a/apps/docs/content/guides/self-hosting/enable-mcp.mdx +++ b/apps/docs/content/guides/self-hosting/enable-mcp.mdx @@ -193,7 +193,7 @@ defaultActiveId="kong" ```sh -docker compose restart kong +sh run.sh restart kong ``` @@ -201,9 +201,11 @@ docker compose restart kong ```sh -docker compose -f docker-compose.yml -f docker-compose.envoy.yml restart api-gw +sh run.sh restart api-gw ``` +This assumes the Envoy override is already active (`sh run.sh config add envoy`). + diff --git a/apps/docs/content/guides/self-hosting/postgres-upgrade-17.mdx b/apps/docs/content/guides/self-hosting/postgres-upgrade-17.mdx index fc107811f9a..61f4d058367 100644 --- a/apps/docs/content/guides/self-hosting/postgres-upgrade-17.mdx +++ b/apps/docs/content/guides/self-hosting/postgres-upgrade-17.mdx @@ -14,7 +14,7 @@ Self-hosted Supabase ships with Postgres 17 by default. This guide covers two sc Postgres 17 is the default, so a new self-hosted instance with **no existing data** starts on Postgres 17 - no override needed: ```sh -docker compose up -d +sh run.sh start ``` The rest of the setup is unchanged (see the Docker install [guide](/docs/guides/self-hosting/docker)). @@ -111,7 +111,7 @@ The script might require your confirmation at some steps (e.g., while checking f To verify that Postgres 17 is running: ```sh -docker compose -f docker-compose.yml -f docker-compose.pg17.yml exec db psql -U postgres -c "SELECT version();" +docker compose exec db psql -U postgres -c "SELECT version();" ``` The original Postgres 15 data is preserved at `./volumes/db/data.bak.pg15`. The pgsodium root key is saved as `./volumes/db/pgsodium_root.key.bak.pg15`. The upgrade binaries tarball is cached at `./volumes/db/pg17_upgrade_bin_*.tar.gz`. Once you have verified that everything works, you can reclaim disk space: @@ -136,11 +136,12 @@ If you need to revert to Postgres 15 (run the following commands as root): docker compose down && \ rm -rf ./volumes/db/data && \ mv ./volumes/db/data.bak.pg15 ./volumes/db/data && \ -docker compose -f docker-compose.yml -f docker-compose.pg15.yml run --rm db chown -R postgres:postgres /etc/postgresql-custom/ && \ -docker compose -f docker-compose.yml -f docker-compose.pg15.yml up -d +sh run.sh config add pg15 && \ +docker compose run --rm db chown -R postgres:postgres /etc/postgresql-custom/ && \ +sh run.sh start ``` -This restores the original data directory, fixes file ownership on the `db-config` volume, and starts with the old Postgres 15 image. The Postgres 15 override is required because Supabase's Postgres 15 and 17 images use different user IDs, so the `chown` and startup must run as Postgres 15. +This restores the original data directory, fixes file ownership on the `db-config` volume, and configures Supabase to use the old Postgres 15 image. Supabase's Postgres 15 and 17 images use different user IDs, so the `chown` and startup must run as Postgres 15. ### Custom Postgres configuration @@ -163,13 +164,13 @@ EOF' Restart to apply (`max_connections` requires a full restart): ```sh -docker compose -f docker-compose.yml -f docker-compose.pg17.yml restart db +sh run.sh restart db ``` Verify the new settings: ```sh -docker compose -f docker-compose.yml -f docker-compose.pg17.yml exec db psql -U postgres -c "SHOW max_connections;" +docker compose exec db psql -U postgres -c "SHOW max_connections;" ``` ### Upgrade process details @@ -218,7 +219,7 @@ Then re-run the upgrade script. Replication slots will need to be manually recre The upgrade script fixes file ownership automatically (Postgres 15 and 17 use different UIDs). If you still see permission errors, run: ```sh -docker compose -f docker-compose.yml -f docker-compose.pg17.yml run --rm db \ +docker compose run --rm db \ chown -R postgres:postgres /var/lib/postgresql/data ``` @@ -233,8 +234,7 @@ The `db-config` named volume contains the pgsodium root encryption key at `/etc/ Restart all services to pick up the new database: ```sh -docker compose -f docker-compose.yml -f docker-compose.pg17.yml down && \ -docker compose -f docker-compose.yml -f docker-compose.pg17.yml up -d +sh run.sh recreate ``` ### Disk space issues during upgrade @@ -262,9 +262,9 @@ If you are starting a **fresh** Postgres 17 deployment (not using the upgrade sc To fix, remove the old volume and let Postgres 17 initialize a clean configuration: ```sh -docker compose -f docker-compose.yml -f docker-compose.pg17.yml down && \ +sh run.sh stop && \ docker volume rm $(docker volume ls --filter "name=db-config" --format '{{.Name}}') && \ -docker compose -f docker-compose.yml -f docker-compose.pg17.yml up -d +sh run.sh start ``` @@ -280,9 +280,10 @@ If the upgrade fails and the script's built-in rollback isn't sufficient, restor Restore the data: ```sh -docker compose -f docker-compose.yml -f docker-compose.pg17.yml down && \ +docker compose down && \ rm -rf ./volumes/db/data && \ -cp -a ./volumes/db/data-manual-backup ./volumes/db/data +cp -a ./volumes/db/data-manual-backup ./volumes/db/data && \ +sh run.sh config add pg15 ``` Restore the pgsodium key to the `db-config` volume: @@ -291,13 +292,13 @@ Restore the pgsodium key to the `db-config` volume: docker compose run --rm db \ sh -c 'cat > /etc/postgresql-custom/pgsodium_root.key' < ./pgsodium_root.key.backup && \ docker compose run --rm db \ - chown postgres:postgres /etc/postgresql-custom/pgsodium_root.key && \ + chown -R postgres:postgres /etc/postgresql-custom/ && \ docker compose run --rm db \ chmod 600 /etc/postgresql-custom/pgsodium_root.key ``` -Start Postgres 15: +Start self-hosted Supabase with Postgres 15: ```sh -docker compose -f docker-compose.yml -f docker-compose.pg15.yml up -d +sh run.sh start ``` diff --git a/apps/docs/content/guides/self-hosting/remove-superuser-access.mdx b/apps/docs/content/guides/self-hosting/remove-superuser-access.mdx index a2b7c6d6d8d..3402ab4f177 100644 --- a/apps/docs/content/guides/self-hosting/remove-superuser-access.mdx +++ b/apps/docs/content/guides/self-hosting/remove-superuser-access.mdx @@ -62,7 +62,7 @@ Studio uses its own credentials to access Postgres via `postgres-meta`, so this ### Step 3: Restart Supabase ```sh -docker compose down && docker compose up -d +sh run.sh recreate ``` ## Verify roles diff --git a/apps/docs/content/guides/self-hosting/self-hosted-auth-keys.mdx b/apps/docs/content/guides/self-hosting/self-hosted-auth-keys.mdx index 5101014c539..1ced340ad25 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-auth-keys.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-auth-keys.mdx @@ -68,7 +68,7 @@ Nested variable interpolation (`${A:-${B}}`) requires `podman-compose >= 1.6.0`. Restart all services: ```sh -docker compose down && docker compose up -d +sh run.sh recreate ``` ### New API keys format @@ -156,7 +156,7 @@ sh utils/rotate-new-api-keys.sh --update-env After rotating, restart services and update your client applications with the new keys: ```sh -docker compose down && docker compose up -d +sh run.sh recreate ``` diff --git a/apps/docs/content/guides/self-hosting/self-hosted-envoy.mdx b/apps/docs/content/guides/self-hosting/self-hosted-envoy.mdx index 592bc395ed2..68b2d147aec 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-envoy.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-envoy.mdx @@ -21,14 +21,15 @@ The Envoy gateway is provided as a Docker Compose override. -If your stack is already running from the initial setup, bring it down first with `docker compose down`. +If your stack is already running from the initial setup, bring it down first with `sh run.sh stop`. -Start your self-hosted Supabase stack with both the base compose file and the Envoy override: +Enable the Envoy override, then start the stack: ```sh -docker compose -f docker-compose.yml -f docker-compose.envoy.yml up -d +sh run.sh config add envoy +sh run.sh start ``` The override disables the default Kong gateway and starts Envoy on the same port (default `8000`). It also reconfigures the Functions service to wait for Envoy via a dependency. @@ -118,7 +119,7 @@ Envoy cannot natively read environment variables inside its config. The entrypoi Configuration changes require restarting the container so the entrypoint re-renders the template: ```sh -docker compose -f docker-compose.yml -f docker-compose.envoy.yml restart api-gw +sh run.sh restart api-gw ``` @@ -263,7 +264,7 @@ All routing, filter, and cluster changes are made in the YAML files under `./vol - **Applying changes.** Envoy reads the rendered `lds.yaml` from the filesystem. Configuration changes require restarting the container so the entrypoint re-renders the template: ```sh -docker compose -f docker-compose.yml -f docker-compose.envoy.yml restart api-gw +sh run.sh restart api-gw ``` @@ -303,7 +304,7 @@ docker run --rm --network container:supabase-envoy curlimages/curl http://127.0. Envoy writes access logs and filter output to stdout. View them with: ```sh -docker compose -f docker-compose.yml -f docker-compose.envoy.yml logs api-gw +docker compose logs api-gw ``` The access log format is a standard combined log with the request method, original path, response code, and bytes sent. diff --git a/apps/docs/content/guides/self-hosting/self-hosted-functions.mdx b/apps/docs/content/guides/self-hosting/self-hosted-functions.mdx index 7ab4da3df8b..391e61ace7a 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-functions.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-functions.mdx @@ -47,7 +47,7 @@ Deno.serve(async (req: Request) => { ### Step 2: Restart the functions service to pick up the new function ```sh -docker compose restart functions --no-deps +sh run.sh restart functions ``` ### Step 3: Invoke your function @@ -94,7 +94,7 @@ Don't commit `.env.functions` to version control if it contains secrets. Add it Restart the functions service: ```sh -docker compose up -d --force-recreate --no-deps functions +sh run.sh recreate functions ``` ### Using inline environment variables @@ -178,7 +178,7 @@ scp -r ./my-function user@:/path/to/self-hosted/volumes/functions/ Then restart the functions service on the remote host: ```sh -ssh user@ 'cd /path/to/self-hosted && docker compose restart functions --no-deps' +ssh user@ 'cd /path/to/self-hosted && sh run.sh restart functions' ``` ## Copying functions from Supabase platform @@ -221,7 +221,7 @@ Common causes: syntax errors in your function code, invalid imports, or missing Restart the functions service: ```sh -docker compose restart functions --no-deps +sh run.sh restart functions ``` ### Custom env vars not available in functions @@ -233,7 +233,7 @@ docker compose restart functions --no-deps Use the following command to recreate the container: ```sh -docker compose up -d --force-recreate --no-deps functions +sh run.sh recreate functions ``` ### Memory or timeout errors diff --git a/apps/docs/content/guides/self-hosting/self-hosted-oauth.mdx b/apps/docs/content/guides/self-hosting/self-hosted-oauth.mdx index 505a4aa3f44..331c94c5f13 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-oauth.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-oauth.mdx @@ -91,7 +91,7 @@ For providers **not** pre-configured in the files (see the [full provider list]( ### Step 4: Restart the auth service ```sh -docker compose up -d --force-recreate --no-deps auth +sh run.sh recreate auth ``` ### Step 5: Verify the configuration @@ -385,7 +385,7 @@ For detailed client-side integration, see [Social Login](/docs/guides/auth/socia ### "Provider not enabled" or provider seen as false in settings - Check that `GOTRUE_EXTERNAL_*_ENABLED` is set to `true` in `docker-compose.yml` -- Verify the `.env` variable is not empty, e.g., check with `docker compose exec auth env | grep GOOGLE` +- Verify the `.env` variable is not empty, e.g., check with `sh run.sh printenv auth | grep GOOGLE` ### Variables added to the environment but provider still not working @@ -398,7 +398,7 @@ auth: GOTRUE_EXTERNAL_GOOGLE_ENABLED: ${GOOGLE_ENABLED} ``` -Run `docker compose exec auth env | grep GOTRUE_EXTERNAL` to verify the variables are reaching the container. +Run `sh run.sh printenv auth | grep GOTRUE_EXTERNAL` to verify the variables are reaching the container. ### Site URL or redirect URL errors after login diff --git a/apps/docs/content/guides/self-hosting/self-hosted-phone-mfa.mdx b/apps/docs/content/guides/self-hosting/self-hosted-phone-mfa.mdx index 5e2d658cd42..7834d4653e8 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-phone-mfa.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-phone-mfa.mdx @@ -63,13 +63,13 @@ auth: ### Step 3: Restart the auth service ```sh -docker compose up -d --force-recreate --no-deps auth +sh run.sh recreate auth ``` ### Step 4: Verify ```sh -docker compose exec auth env | grep GOTRUE_SMS +sh run.sh printenv auth | grep GOTRUE_SMS ``` Confirm your provider and credentials appear in the output. @@ -181,7 +181,7 @@ SMS_OTP_EXP=300 Ensure `GOTRUE_SMS_OTP_EXP: ${SMS_OTP_EXP}` is uncommented in `docker-compose.yml`, then restart: ```sh -docker compose up -d --force-recreate --no-deps auth +sh run.sh recreate auth ``` ### SMS not being delivered @@ -195,7 +195,7 @@ docker compose logs auth --tail 50 Verify provider credentials reach the container: ```sh -docker compose exec auth env | grep GOTRUE_SMS +sh run.sh printenv auth | grep GOTRUE_SMS ``` Common causes: @@ -209,13 +209,13 @@ Common causes: Configuration variables from `.env` are **not** automatically available inside the container unless there's a matching passthrough definition in `docker-compose.yml`. Check, e.g., for: ```sh -docker compose exec auth env | grep -E 'GOTRUE_SMS|GOTRUE_MFA' +sh run.sh printenv auth | grep -E 'GOTRUE_SMS|GOTRUE_MFA' ``` After changing the configuration environment variables, recreate the Auth service container: ```sh -docker compose up -d --force-recreate --no-deps auth +sh run.sh recreate auth ``` ### Rate limit errors diff --git a/apps/docs/content/guides/self-hosting/self-hosted-proxy-https.mdx b/apps/docs/content/guides/self-hosting/self-hosted-proxy-https.mdx index d94763573a1..12c808b46a6 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-proxy-https.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-proxy-https.mdx @@ -76,10 +76,11 @@ defaultActiveId="caddy" [Caddy](https://caddyserver.com/) automatically provisions and renews Let's Encrypt TLS certificates with zero configuration. It also handles HTTP-to-HTTPS redirects, WebSocket upgrades, and HTTP/2 and HTTP/3 out of the box. -Start Caddy by using the pre-configured `docker-compose.caddy.yml` override: +Enable the pre-configured `docker-compose.caddy.yml` override, then start the stack: ```sh -docker compose -f docker-compose.yml -f docker-compose.caddy.yml up -d +sh run.sh config add caddy +sh run.sh start ``` Caddy configuration is in `volumes/proxy/caddy/Caddyfile`. @@ -89,10 +90,11 @@ Caddy configuration is in `volumes/proxy/caddy/Caddyfile`. This option uses a third-party Nginx Docker image ([`jonasal/nginx-certbot`](https://github.com/JonasAlfredsson/docker-nginx-certbot)), which includes Certbot for automatic Let's Encrypt certificate issuance and renewal in a single container. -Start Nginx by using the pre-configured `docker-compose.nginx.yml` override: +Enable the pre-configured `docker-compose.nginx.yml` override, then start the stack: ```sh -docker compose -f docker-compose.yml -f docker-compose.nginx.yml up -d +sh run.sh config add nginx +sh run.sh start ``` Nginx configuration template is in `volumes/proxy/nginx/supabase-nginx.conf.tpl`. On container startup, `${NGINX_SERVER_NAME}` is substituted using the environment variable from the `.env` file. The [`jonasal/nginx-certbot`](https://github.com/JonasAlfredsson/docker-nginx-certbot) image reads the resolved `server_name` to determine which domain to request a Let's Encrypt certificate for. @@ -180,7 +182,7 @@ SITE_URL=https:// ### Step 4: Restart and verify ```sh -docker compose down && docker compose up -d +sh run.sh recreate ``` ```sh @@ -213,7 +215,7 @@ If OAuth redirects fail with a callback URL error: - Verify `API_EXTERNAL_URL` in `.env` is set to your HTTPS URL + `/auth/v1` - Verify the callback URL registered with your OAuth provider matches `API_EXTERNAL_URL` followed by `/callback` -- After changing `API_EXTERNAL_URL`, restart all services with `docker compose down && docker compose up -d` +- After changing `API_EXTERNAL_URL`, restart all services with `sh run.sh recreate` ### Mixed content warnings diff --git a/apps/docs/content/guides/self-hosting/self-hosted-s3.mdx b/apps/docs/content/guides/self-hosting/self-hosted-s3.mdx index 75ee55e20ad..8d9c392591c 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-s3.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-s3.mdx @@ -91,7 +91,8 @@ Depending on your setup, you may need to adjust these values - for example, to u An override `docker-compose.rustfs.yml` can be added to enable RustFS container and provide an S3-compatible API for Storage backend: ```sh -docker compose -f docker-compose.yml -f docker-compose.rustfs.yml up -d +sh run.sh config add rustfs +sh run.sh start ``` Make sure to review the Storage section in your `.env` file for related configuration options. @@ -112,7 +113,8 @@ MinIO no longer publishes open source Docker images or maintains their open sour An override `docker-compose.s3.yml` can be added to enable MinIO container and provide an S3-compatible API for Storage backend: ```sh -docker compose -f docker-compose.yml -f docker-compose.s3.yml up -d +sh run.sh config add s3 +sh run.sh start ``` Make sure to review the Storage section in your `.env` file for related configuration options. diff --git a/apps/docs/content/guides/self-hosting/self-hosted-saml-sso.mdx b/apps/docs/content/guides/self-hosting/self-hosted-saml-sso.mdx index 35749d03dd3..05993e0fbc6 100644 --- a/apps/docs/content/guides/self-hosting/self-hosted-saml-sso.mdx +++ b/apps/docs/content/guides/self-hosting/self-hosted-saml-sso.mdx @@ -115,14 +115,13 @@ auth: Apply the configuration changes: ```sh -docker compose down && \ -docker compose up -d +sh run.sh recreate ``` Verify the Auth service is healthy: ```sh -docker compose ps auth +sh run.sh status auth ``` ## Step 5: Retrieve your service provider metadata @@ -548,7 +547,7 @@ The response should include `app_metadata.provider: "sso:saml"` and any mapped a The `GOTRUE_SAML_ENABLED` variable is not set to `true`, or the Auth container did not pick up the change. Verify the env var is passed through `docker-compose.yml` and restart: ```sh -docker compose down && docker compose up -d +sh run.sh recreate ``` ### "Invalid private key" on startup @@ -569,7 +568,7 @@ base64 -w 0 -i pk_rsa1.der ### IdP cannot reach the ACS endpoint -- Verify `API_EXTERNAL_URL` is set to a URL containing `/auth/v1` the IdP can reach (not set to `localhost` unless testing locally) +- Verify `API_EXTERNAL_URL` is set to a URL containing `/auth/v1` the IdP can reach (not `localhost` unless testing locally) - Check that the API gateway routes for `/auth/v1/sso/saml/acs` and `/auth/v1/sso/saml/metadata` are configured as open (no `key-auth` plugin). - Check the Auth container logs: `docker compose logs auth`