support root and path deployments explicitly

README.md

@@ -17,6 +17,11 @@ cp config.example.toml config.toml
 docker compose up --build -d
 ```
 
+The root `docker-compose.yml` is the local-development definition and builds
+the checked-out source. `deploy/compose.production.yml` is the source-free
+server definition and pulls a versioned image; copy it to the deployment host
+as `docker-compose.yml`.
+
 The service listens on `127.0.0.1:18082` on the host. Its SQLite database is
 stored at `./data/urlshort.db` and survives container replacement.
 
@@ -51,9 +56,16 @@ ushort legacy-config.json
 | `rate_limit_window` | no | `60` | Sliding-window length in seconds. |
 | `production` | no | `false` | When true, disable embedded frontend routes for compatibility with deployments that serve static files separately. |
 
-For example, `base_url = "https://example.com/go/links"` limits routing to
-`/go/links` and produces URLs such as
-`https://example.com/go/links/aB3xYz`. Requests outside that prefix return 404.
+The same binary supports both common reverse-proxy layouts:
+
+- `base_url = "https://s.example.com"` serves the frontend, API, and short
+  codes at the subdomain root, producing `https://s.example.com/aB3xYz`.
+- `base_url = "https://example.com/go/links"` limits routing to `/go/links`
+  and produces `https://example.com/go/links/aB3xYz`. Requests outside that
+  prefix return 404.
+
+A trailing slash on `base_url` is accepted in either layout and is normalized
+when short URLs are generated.
 
 Real API keys belong only in the deployment's ignored `config.toml`, never in
 the repository or container image.
@@ -61,7 +73,9 @@ the repository or container image.
 ## API
 
 All paths below are relative to the path in `base_url`. Trailing slashes are
-accepted. Every response includes the legacy CORS and security headers.
+accepted by every frontend, API, metadata, deletion, and short-code route,
+including when a query string follows the slash. Every response includes the
+legacy CORS and security headers.
 
 ### Health and frontend
 
@@ -165,9 +179,11 @@ pagination, theme selection, URL lookup, copy/delete actions, and admin flow
 are unchanged. Compile-time embedding makes those files part of the standalone
 artifact; no bind mount or separate web root is needed.
 
-For the existing `/s` deployment, place the location blocks from `nginx.conf`
-in the public vhost. They proxy all traffic to the binary while retaining the
-current `no-store` HTML and `no-cache` asset policies.
+For a path deployment such as the existing `/s`, place the location blocks
+from `nginx.conf` in the public vhost. For a dedicated subdomain, use
+`deploy/nginx-subdomain.conf` in its `server` block. Both examples proxy the
+frontend, API, and redirects while retaining `no-store` HTML and `no-cache`
+asset policies.
 
 ## Build and test
 
@@ -184,6 +200,13 @@ Run the Rust test suite in an isolated build stage:
 docker build --target tester .
 ```
 
+Run the real HTTP trailing-slash smoke test against any disposable deployment:
+
+```bash
+sh tests/smoke.sh https://s.example.com "$API_KEY"
+sh tests/smoke.sh https://example.com/s "$API_KEY"
+```
+
 The Dockerfile builds against musl and uses `scratch` for the runtime image.
 Docker Buildx can publish both required architectures from the same source: