v4.0.0.1

DEPLOYMENT.md

@@ -8,17 +8,19 @@ container, routed by Host header at nginx:
 | Hostname                    | Purpose                                    |
 |-----------------------------|--------------------------------------------|
 | `goodwalk.co.nz` / `www.…`  | Public marketing site                      |
-| `onboarding.goodwalk.co.nz` | New-client onboarding flow                 |
-| `admin.goodwalk.co.nz`      | Owner admin dashboard (Aless only)         |
+| `clients.goodwalk.co.nz`    | New-client onboarding + contract portal    |
+| `cp.goodwalk.co.nz`         | Owner admin dashboard (Aless only)         |
 
-The admin host needs its own TLS certificate at
-`/etc/letsencrypt/live/admin.goodwalk.co.nz/`. Issue it once before the first
-nginx reload, e.g.:
-
-```bash
-docker compose -p nginx -f /docker/nginx/docker-compose.yml exec nginx \
-  certbot certonly --webroot -w /var/www/certbot -d admin.goodwalk.co.nz
-```
+The shared nginx container reads TLS material from its host bind mount at
+`/docker/certbot/conf`, exposed inside the container as `/etc/letsencrypt`.
+The deploy scripts now auto-bootstrap any missing certificates referenced by
+the shared nginx config, including `clients.goodwalk.co.nz`,
+`cp.goodwalk.co.nz`, and the legacy HTTPS redirect aliases
+`onboarding.goodwalk.co.nz` and `admin.goodwalk.co.nz`. They do that by
+temporarily loading an HTTP-only nginx config and running `certbot/certbot`
+against the mounted ACME webroot. The only prerequisite is that each
+hostname's DNS A record already points at the droplet and port `80` is
+reachable.
 
 The dashboard's data (`client_profiles`, `allowed_emails`, `drafts`) lives in
 the shared postgres database alongside the marketing site content, in a single
@@ -47,7 +49,7 @@ The production server currently runs multiple separate Docker Compose projects:
 - Main public site WordPress stack:
   - project: `goodwalkconz`
   - path: `/docker/wordpress/goodwalk.co.nz`
-- Onboarding WordPress stack:
+- Legacy onboarding WordPress stack:
   - project: `onboardinggoodwalkconz`
   - path: `/docker/wordpress/onboarding.goodwalk.co.nz`
 - Shared nginx:
@@ -92,7 +94,7 @@ containers untouched.
   - Repo-local SSH config used by the deployment script.
 - [nginx/goodwalk.co.nz.svelte.conf.example](nginx/goodwalk.co.nz.svelte.conf.example)
   - Example shared-nginx config for routing the main public site to the new
-    Svelte app and mail API, including the onboarding subdomain.
+    Svelte app and mail API, including the `clients` and `cp` subdomains.
 
 ## First-time server preparation
 
@@ -113,7 +115,7 @@ mkdir -p /docker/goodwalk-svelte
 It is created from [deploy.env.template](deploy.env.template). Current template contents:
 
 ```env
-APP_VERSION=4.0.0
+APP_VERSION=4.0.1
 ENABLE_GENERAL_ENQUIRIES=false
 PUBLIC_ENABLE_MOBILE_CTA_BUTTON=false
 PUBLIC_ENABLE_ENHANCED_CONTENT_IMAGES=false
@@ -126,6 +128,8 @@ POSTGRES_PASSWORD_URLENCODED=gw_Pg_7Jm9%21Qx4%23Ld2%40Vr8
 
 RESEND_API_KEY=replace-me
 OWNER_EMAIL=replace-me
+SECONDARY_CP_EMAIL=
+SECONDARY_CP_EMAILS=
 FROM_EMAIL=GoodWalk <bookings@goodwalk.co.nz>
 REPLY_TO=aless@goodwalk.co.nz
 MAIL_API_DATA_DIR=/app/data
@@ -136,6 +140,7 @@ RATE_LIMIT_WINDOW_SECONDS=900
 RATE_LIMIT_MAX_PER_IP=5
 RATE_LIMIT_MAX_PER_EMAIL=3
 RATE_LIMIT_MIN_INTERVAL_SECONDS=20
+EMAIL_SEND_TIMEOUT_SECONDS=20
 ```
 
 After the first deploy, edit `/docker/goodwalk-svelte/.env` on the server and replace:
@@ -143,6 +148,14 @@ After the first deploy, edit `/docker/goodwalk-svelte/.env` on the server and re
 - `RESEND_API_KEY=replace-me`
 - `OWNER_EMAIL=replace-me`
 
+Optional CP dashboard admins:
+
+- `SECONDARY_CP_EMAIL=person@example.com`
+- `SECONDARY_CP_EMAILS=bob@smith.com;bobsmith2@smith.com`
+
+`OWNER_EMAIL` always keeps CP access. The secondary values are optional and may be
+semicolon-, comma-, or whitespace-separated.
+
 Frontend flags:
 
 - `PUBLIC_ENABLE_MOBILE_CTA_BUTTON=false` keeps the sticky mobile booking CTA hidden.
@@ -157,6 +170,17 @@ docker network ls | grep webnet
 
 Your server already uses `webnet`, so this should already be present.
 
+5. Confirm the shared nginx compose mounts still point at the host certbot
+   paths expected by the deploy scripts:
+
+```yaml
+- /docker/certbot/conf:/etc/letsencrypt:ro
+- /docker/certbot/www:/var/www/certbot:ro
+```
+
+The scripts inspect the running `nginx` container to derive those host paths
+before checking or issuing certificates.
+
 ## First deploy
 
 From Windows PowerShell in the repo root:
@@ -293,8 +317,10 @@ nginx/goodwalk.co.nz.svelte.conf.example
 Important:
 - `deploy.ps1` now copies the repo nginx config to `/docker/nginx/conf.d/goodwalk.co.nz.conf` and reloads the shared nginx container as part of deployment.
 - The repo nginx config uses Docker's internal resolver so future app/mail container rebuilds will not leave nginx pinned to stale upstream IPs.
-- The same nginx config now also routes `onboarding.goodwalk.co.nz` to the Svelte app and `/api/onboarding-submit` to the shared mail API.
-- Before cutover, confirm the server has a valid certificate for `onboarding.goodwalk.co.nz`, or adjust the onboarding certificate paths in the nginx config to match your cert layout.
+- The same nginx config now also routes `clients.goodwalk.co.nz` to the Svelte app and `/api/onboarding-submit` to the shared mail API.
+- The owner dashboard is now served on `cp.goodwalk.co.nz`.
+- `onboarding.goodwalk.co.nz` and `admin.goodwalk.co.nz` should be kept only as redirect aliases once their DNS and TLS are in place.
+- The deploy script will attempt to issue any missing certificates for `clients.goodwalk.co.nz`, `cp.goodwalk.co.nz`, and `onboarding.goodwalk.co.nz` before the final nginx reload.
 
 Manual nginx commands, if you ever need them: