avoid creating unnecessary conf files

docs/deployment/custom-domain.mdx

@@ -76,7 +76,7 @@ It will automatically:
 - Install Certbot
 - Generate Let's Encrypt SSL certificates
 - Update the canonical public host/base URL settings in `.env`
-- Re-render `nginx.conf` and `turnserver.conf` from the shared templates
+- Validate the runtime config that `dograh-init` will render from `.env`
 - Configure automatic certificate renewal
 - Restart Dograh services through the validated startup wrapper
 
@@ -163,7 +163,7 @@ PUBLIC_BASE_URL=https://voice.yourcompany.com
 
 ### Start Dograh Services
 
-Start Dograh through the validated startup wrapper so the generated nginx and coturn configs are refreshed before Docker starts:
+Start Dograh through the validated startup wrapper so `dograh-init` regenerates nginx and coturn runtime config before Docker starts:
 
 ```bash
 cd dograh
@@ -231,7 +231,7 @@ If Certbot fails to generate certificates:
 If you see SSL errors after setup:
 
 1. Verify the certificates were copied correctly: `ls -la dograh/certs/`
-2. Run `./remote_up.sh --preflight-only` in `dograh/` to verify the regenerated remote config matches `.env`
+2. Run `./remote_up.sh --preflight-only` in `dograh/` to verify the `dograh-init` runtime render matches `.env`
 3. Restart the nginx container: `sudo docker compose --profile remote restart nginx`
 
 ### WebRTC Connection Issues

docs/deployment/docker.mdx

@@ -66,7 +66,7 @@ The script will prompt you for:
 - The host browsers should use to reach TURN (press Enter for `127.0.0.1`; use your LAN IP if testing from another device on the same network)
 - A shared secret for the TURN server (press Enter to generate a random one)
 
-It creates `docker-compose.yaml`, `turnserver.conf`, and a `.env` file with TURN credentials. Start the stack with the `local-turn` profile so coturn comes up alongside the other services:
+It creates `docker-compose.yaml`, a `.env` file with TURN credentials, and the small helper bundle that `dograh-init` uses to render coturn config at startup. Start the stack with the `local-turn` profile so coturn comes up alongside the other services:
 
 ```bash
 docker compose --profile local-turn up --pull always
@@ -121,7 +121,7 @@ It will automatically:
 - Download the validated remote deployment helper bundle
 - Generate SSL certificates
 - Create an environment file with TURN server configuration
-- Render `nginx.conf` and `turnserver.conf` from shared templates
+- Validate the runtime config that `dograh-init` will render from `.env`
 - Write a `docker-compose.override.yaml` with build directives (build mode only)
 
 ### Start the Application
@@ -175,12 +175,14 @@ The setup script creates the following files in the `dograh/` directory:
 |------|---------|
 | `docker-compose.yaml` | Main Docker Compose configuration |
 | `docker-compose.override.yaml` | Build directives for `api` and `ui` (**build mode only**) |
-| `turnserver.conf` | Configuration for TURN server |
-| `nginx.conf` | nginx reverse proxy configuration with your IP |
+| `remote_up.sh` | Validated startup wrapper for the remote stack |
+| `scripts/run_dograh_init.sh` | One-shot init renderer/validator used by Docker Compose |
+| `scripts/lib/remote_common.sh` | Shared deployment helper library |
+| `deploy/templates/` | nginx and coturn runtime config templates |
 | `generate_certificate.sh` | Script to regenerate SSL certificates |
 | `certs/local.crt` | Self-signed SSL certificate |
 | `certs/local.key` | SSL private key |
-| `.env` | Environment variables (TURN secret, JWT secret, FastAPI worker count) |
+| `.env` | Single source of truth for deployment settings (TURN secret, JWT secret, FastAPI worker count, public host/base URL) |
 
 ### Building from source
 

docs/deployment/scaling.mdx

@@ -8,7 +8,7 @@ By default, the Dograh API container runs a single uvicorn worker. For productio
 This page covers how the multi-worker setup works, how to choose a worker count at install time, and how to change it on a running stack.
 
 <Warning>
-Multi-worker support requires **Dograh v1.29.0 or newer**. Earlier releases used `uvicorn --workers` and ship a different `setup_remote.sh` / `start_services_docker.sh` / `nginx.conf` layout — the steps below will not work on them. If your stack is older, [update first](/deployment/update) and then come back to this page.
+Multi-worker support requires **Dograh v1.29.0 or newer**. Earlier releases used `uvicorn --workers` and a different remote deployment layout. If your stack is older, [update first](/deployment/update) and then come back to this page.
 </Warning>
 
 ## How it works
@@ -58,11 +58,11 @@ Press Enter for the default (`4`) or enter a different positive integer. Non-int
 SERVER_IP=... TURN_SECRET=... FASTAPI_WORKERS=8 ./setup_remote.sh
 ```
 
-The script stores the value in **`.env`** (`FASTAPI_WORKERS=N`). The supported startup path (`./remote_up.sh`) re-renders `nginx.conf` from that value before every remote start, so nginx and the API worker count stay aligned.
+The script stores the value in **`.env`** (`FASTAPI_WORKERS=N`). The supported startup path (`./remote_up.sh`) preflights the `dograh-init` render from that value before every remote start, so nginx and the API worker count stay aligned.
 
 ## Changing the worker count on a running stack
 
-Once Dograh is running, increasing or decreasing the worker count is a one-file edit plus a restart. Change `.env`, then start through `./remote_up.sh` so the generated `nginx.conf` is refreshed before Docker starts the stack.
+Once Dograh is running, increasing or decreasing the worker count is a one-file edit plus a restart. Change `.env`, then start through `./remote_up.sh` so `dograh-init` regenerates nginx runtime config before Docker starts the stack.
 
 ### Steps
 
@@ -90,7 +90,7 @@ If you want to avoid downtime and your stack is healthy, you can recreate only t
 ./remote_up.sh -- api nginx
 ```
 
-`remote_up.sh` re-renders `nginx.conf`, validates that it matches `.env`, runs `docker compose config -q`, and then starts the requested services.
+`remote_up.sh` validates `.env`, runs the same `dograh-init` render that Compose will use at startup, runs `docker compose config -q`, and then starts the requested services.
 
 **3. Verify.** Confirm the right number of uvicorn processes are running. The API image is slim and doesn't include `ps`, so use Docker's host-side view instead:
 

docs/deployment/update.mdx

@@ -38,7 +38,7 @@ Always update **`dograh-api`** and **`dograh-ui`** to the **same tag**. The two
 - Asks for a target version (defaults to the latest release tag on GitHub).
 - Pulls `docker-compose.yaml` at that version and pins both `api` and `ui` images to it.
 - Refreshes the remote helper bundle (`remote_up.sh` plus shared templates/helpers).
-- Synchronizes the canonical remote keys in `.env` and re-renders `nginx.conf` and `turnserver.conf` from the shared templates.
+- Synchronizes the canonical remote keys in `.env` and validates the runtime config that `dograh-init` will render from it.
 - Backs up every file it changes with a `.bak.<timestamp>` suffix.
 
 From your install directory:
@@ -62,7 +62,7 @@ After the script finishes, apply the update through the validated startup wrappe
 ```
 
 <Note>
-The script overwrites `docker-compose.yaml`, `remote_up.sh`, `nginx.conf`, and `turnserver.conf` from the shared upstream deployment bundle. If you've made local edits to any of these, check the `.bak.<timestamp>` files after the update and re-apply your edits.
+The script overwrites `docker-compose.yaml` and the remote helper bundle (`remote_up.sh`, `scripts/run_dograh_init.sh`, `scripts/lib/remote_common.sh`, and `deploy/templates/*`) from the shared upstream deployment bundle. If you've made local edits to any of these, check the `.bak.<timestamp>` files after the update and re-apply your edits.
 </Note>
 
 ## Local deployment
@@ -99,11 +99,10 @@ curl http://localhost:8000/api/v1/health           # local
 
 ```bash
 cd dograh
-for f in docker-compose.yaml nginx.conf turnserver.conf .env; do
+for f in docker-compose.yaml nginx.conf turnserver.conf .env remote_up.sh scripts/run_dograh_init.sh scripts/lib/remote_common.sh deploy/templates/nginx.remote.conf.template deploy/templates/turnserver.remote.conf.template; do
     [[ -f "$f.bak.<timestamp>" ]] && cp "$f.bak.<timestamp>" "$f"
 done
-sudo docker compose --profile remote down
-sudo docker compose --profile remote up -d
+./remote_up.sh
 ```
 
 Your Postgres data volume persists across `down`/`up` cycles, so agents and call history are preserved.
@@ -137,6 +136,6 @@ sudo docker compose --profile remote up -d
 If you update the `pipecat` submodule, you **must** run `git submodule update --init --recursive` before rebuilding, or the Docker build will not pick up `pipecat` changes.
 </Warning>
 
-If you maintain a fork with local customizations on top of upstream, merging conflicts in `docker-compose.yaml`, `nginx.conf`, `turnserver.conf`, or `setup_remote.sh` is up to you — resolve them as you would any other git merge. Leave `OSS_JWT_SECRET` and `TURN_SECRET` in `.env` unchanged across updates to preserve sessions and WebRTC auth.
+If you maintain a fork with local customizations on top of upstream, merging conflicts in `docker-compose.yaml`, `remote_up.sh`, `scripts/run_dograh_init.sh`, `deploy/templates/*`, or `setup_remote.sh` is up to you — resolve them as you would any other git merge. Leave `OSS_JWT_SECRET` and `TURN_SECRET` in `.env` unchanged across updates to preserve sessions and WebRTC auth.
 
 The same migration warning above applies: rolling back across a schema change can leave the DB in a state the older API can't read.