Support www redirects in Docker install

HOW_TO_WORK_ON_SYNAPIS.md

@@ -1,11 +1,8 @@
 # How To Work On Synapsis
-
 This is the practical workflow for developing Synapsis without turning every bugfix into a full Docker release.
 
-## The Basic Rule
-
+## Basic Rule
 Use three different loops for three different jobs:
-
 1. `npm run dev` for normal feature work and bugfixes
 2. local Docker source builds when you need container parity
 3. GHCR publish only when you actually want the server to update
@@ -13,7 +10,6 @@ Use three different loops for three different jobs:
 Do **not** rebuild and push a Docker image for every tiny fix. Batch fixes together, verify them locally, then publish when the server needs the new version.
 
 ## 1. Normal Local Development
-
 Use this for most day-to-day work.
 
 ```bash
@@ -38,10 +34,7 @@ Use this loop when:
 - you do not specifically need to test the Docker runtime
 
 ## 2. Local Docker Parity Test
-
-Use this when you want to know whether the app still works inside the actual container setup.
-
-This compose file builds from your local source tree:
+Use this when you want to know whether the app still works inside the actual container setup. This compose file builds from your local source tree:
 
 ```bash
 cd docker
@@ -49,9 +42,7 @@ cp .env.example .env
 docker compose up --build
 ```
 
-That uses:
-- [docker/docker-compose.yml](/Users/christopher/Dev/Synapsis/Synapsis/docker/docker-compose.yml)
-- [docker/Dockerfile](/Users/christopher/Dev/Synapsis/Synapsis/docker/Dockerfile)
+That uses [docker/docker-compose.yml](/Users/christopher/Dev/Synapsis/Synapsis/docker/docker-compose.yml) and [docker/Dockerfile](/Users/christopher/Dev/Synapsis/Synapsis/docker/Dockerfile).
 
 Use this loop when:
 - Docker-specific startup behavior matters
@@ -59,22 +50,15 @@ Use this loop when:
 - you changed env handling, healthchecks, migrations, ports, or install flow
 
 ## 3. Production Image Publish
-
-Use this only when you want the server or end users to pull a new image.
-
-The production install uses:
-- [docker-compose.yml](/Users/christopher/Dev/Synapsis/Synapsis/docker-compose.yml)
-- image: `ghcr.io/gnosyslabs/synapsis:latest`
+Use this only when you want the server or end users to pull a new image. The production install uses [docker-compose.yml](/Users/christopher/Dev/Synapsis/Synapsis/docker-compose.yml) and `ghcr.io/gnosyslabs/synapsis:latest`.
 
 ### First-time GHCR auth on this machine
-
 ```bash
 gh auth refresh -h github.com -s read:packages -s write:packages
 gh auth token | docker login ghcr.io -u YOUR_GITHUB_USERNAME --password-stdin
 ```
 
 ### Publish the image
-
 Push code first:
 
 ```bash
@@ -101,7 +85,6 @@ That publishes:
 If you are not on a Mac/Colima setup, swap `--builder colima` for whatever local buildx builder you use.
 
 ## 4. Update The Server
-
 Once a new image is published, update the server with:
 
 ```bash
@@ -119,13 +102,10 @@ docker compose images
 ```
 
 ## 5. Which Compose File Is Which
-
 There are two main Docker compose paths in this repo.
 
 ### Local source-build compose
-
-File:
-- [docker/docker-compose.yml](/Users/christopher/Dev/Synapsis/Synapsis/docker/docker-compose.yml)
+File: [docker/docker-compose.yml](/Users/christopher/Dev/Synapsis/Synapsis/docker/docker-compose.yml)
 
 Purpose:
 - local Docker testing
@@ -133,9 +113,7 @@ Purpose:
 - no GHCR push required
 
 ### Production install compose
-
-File:
-- [docker-compose.yml](/Users/christopher/Dev/Synapsis/Synapsis/docker-compose.yml)
+File: [docker-compose.yml](/Users/christopher/Dev/Synapsis/Synapsis/docker-compose.yml)
 
 Purpose:
 - end-user install
@@ -145,9 +123,7 @@ Purpose:
 Do not confuse them.
 
 ## 6. Recommended Workflow
-
 This is the default path that makes the most sense for Synapsis:
-
 1. Make code changes locally
 2. Run `npm run type-check`
 3. Run `npm run build`
@@ -158,7 +134,6 @@ This is the default path that makes the most sense for Synapsis:
 8. Pull and restart on the server
 
 ## 7. When To Publish A New Docker Image
-
 Publish when:
 - you want the fix on the real server
 - you changed install/runtime/container behavior
@@ -169,7 +144,6 @@ Do not publish just because:
 - one small API bug was fixed and not needed on the server yet
 
 ## 8. Current Install Reality
-
 For clean servers, the normal install path is:
 
 ```bash

README.md

@@ -25,6 +25,8 @@ docker compose up -d
 Done! Your node is live at `https://your-domain.com` with automatic SSL. No build step. No dependencies. No fuss.
 Database migrations run automatically on startup and during updates.
 
+Set `DOMAIN` to the canonical host you want Synapsis to live on. If you also create a `www` DNS record, the bundled Caddy setup will redirect `www` to that canonical domain automatically.
+
 If your server already has nginx or another reverse proxy using `80/443`, use the advanced mode instead:
 
 ```bash

docker/Caddyfile

@@ -1,6 +1,10 @@
 # Caddyfile for Synapsis
 # Automatic HTTPS via Let's Encrypt
 
+www.{$DOMAIN} {
+    redir https://{$DOMAIN}{uri} permanent
+}
+
 {$DOMAIN} {
     # Reverse proxy to Synapsis app (port is set via APP_PORT env var)
     reverse_proxy app:{$APP_PORT:3000}

docker/README.md

@@ -41,6 +41,9 @@ Edit `.env` and set these required values (domain should be host only, no scheme
 | `AUTH_SECRET` | Run: `openssl rand -hex 32` |
 | `ADMIN_EMAILS` | Your email address |
 
+Use the bare/canonical host in `DOMAIN`. Example: set `DOMAIN=synapsis.example.com`, not `www.synapsis.example.com`.
+If you also want `www.synapsis.example.com` to work, create a DNS record for `www` pointing to the same server. The bundled Caddy config will redirect `www` to the canonical `DOMAIN`.
+
 Optional (advanced):
 - `NEXT_PUBLIC_NODE_DOMAIN` to override the node domain (defaults to `DOMAIN`)
 - `NEXT_PUBLIC_APP_URL` to override the public app URL used by background jobs (auto-derived from the node domain)