Dograh AI can be deployed using Docker in two main configurations. Choose the option that best fits your needs:Documentation Index
Fetch the complete documentation index at: https://docs.dograh.com/llms.txt
Use this file to discover all available pages before exploring further.
- Option 1: For local development and testing on your own machine
- Option 2: For remote server deployment with HTTPS (using IP address). If you also have a custom domain, you can first deploy Dograh stack on your server using steps in this document and then proceed to the Custom Domain section.
Option 1: Local Docker Deployment
Watch the video tutorial below for a step-by-step walkthrough of setting up Dograh AI locally with Docker.
For local development and testing, you can run Dograh AI directly on your machine using Docker with a single command.
Quick Start
Run this single command to download and start Dograh AI:- Downloads the latest docker-compose.yaml
- Starts all required services including PostgreSQL, Redis, MinIO, API, and UI
- Pulls the latest images automatically
Access the Application
Once running (first startup takes 2-3 minutes), open:You can disable telemetry by setting
ENABLE_TELEMETRY=false in the command above.Troubleshooting WebRTC Connectivity
The Quick Start above relies on direct peer-to-peer WebRTC between your browser and the API container. On most single-machine setups this works without any extra configuration. If you hit any of the following, you likely need a TURN server in the path:- The call connects but no audio flows in either direction
- The browser console reports
iceConnectionState: failed - You are testing from a browser on your smartphone or another device on your LAN against the laptop running Docker
- A VPN, corporate firewall, or strict NAT sits between the browser and Docker
- Whether to enable coturn (answer
y) - 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)
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:
http://localhost:3010.
To verify that media is actually traversing TURN (and not silently falling back to a direct path), set
FORCE_TURN_RELAY=true in .env and restart the API. The browser will then only use relay ICE candidates — if TURN is misconfigured or unreachable, the call fails cleanly with ICE failed in the console instead of appearing to work. Set it back to false once you have verified connectivity.Option 2: Remote Server Deployment
Watch the video tutorial below for a step-by-step walkthrough of deploying Dograh AI to a remote server.
Deploy Dograh AI on a remote server to make it accessible from anywhere using your server’s IP address. This setup includes HTTPS support via nginx reverse proxy with self-signed certificates. We need to serve the application over HTTPS, since modern browsers only allow microphone permissions for websites being served over HTTPS.
Prerequisites
- A server with Docker and Docker Compose installed. It should have minimum of 8 GB RAM and 4 vCPUs.
- Public IP address for your server. You can also access the server using a local IP address in your VPC as long as its reachable from your browser.
- TCP Ports 80, 443, 3478, 5349 and UDP Ports 3478, 5349 and 49152:49200 reachable from Internet (Port 80 and 443 to access the UI and rest of the ports for WebRTC Signaling)
IMPORTANT: Please double check the ports on your firewall. Please refer to your server hosting provider’s documentaion on how you can open these ports in the firewall of the server.
Quick Setup
Run the automated setup script that will configure everything for you:- Your server’s public IP address
- A password for the TURN server (optional, press Enter for default)
- Deployment mode — press Enter for prebuilt (pulls official images, the recommended default) or pick build to compile images from source. Use build when you maintain a fork or want to deploy local customizations — see Building from source below.
- Number of FastAPI workers (uvicorn processes nginx will load-balance) — press Enter for the default of
4, or pick a value that suits your server’s CPU count. See Scaling for sizing guidance and how to change this on a running stack.
- Get the source —
docker-compose.yamlonly (prebuilt mode), or clone the full repo (build mode) - Download the validated remote deployment helper bundle
- Generate SSL certificates
- Create an environment file with TURN server configuration
- Validate the runtime config that
dograh-initwill render from.env - Write a
docker-compose.override.yamlwith build directives (build mode only)
Start the Application
Please ensure that Docker Compose is installed on your machine before proceeding further. You can check whether its installed by running
docker compose version command. If its not installed, please install it by following your server provider documentation.Access Your Application
Your application will be available atSince we are using a self-signed certificate, your browser will show a security warning. You can safely accept it to proceed.
Configuration Notes
- The remote deployment includes an nginx reverse proxy for HTTPS termination
- File downloads (transcripts, recordings) are automatically routed through nginx
- WebSocket connections for real-time features are properly proxied
- The setup uses self-signed certificates - browsers will show a security warning that you can safely accept for testing
- The TURN server (coturn) is configured for WebRTC NAT traversal
- For production deployments with proper SSL and domain names, see the Custom Domain documentation
Files Created
The setup script creates the following files in thedograh/ directory:
| File | Purpose |
|---|---|
docker-compose.yaml | Main Docker Compose configuration |
docker-compose.override.yaml | Build directives for api and ui (build mode only) |
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/setup_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 | Single source of truth for deployment settings (TURN secret, JWT secret, FastAPI worker count, public host/base URL) |
Building from source
If you maintain a fork or want to ship local code changes without waiting for an official image release, pick build when the setup script prompts for deployment mode. In this mode the script:- Clones the repo into
dograh/(default:dograh-hq/dograh@main; the script will ask for anowner/nameandbranchso a fork can point at its own). - If you run the script from inside an existing dograh checkout, offers to use that checkout instead of cloning.
- Generates a
docker-compose.override.yamlnext todocker-compose.yamlthat swaps theimage:directives for localbuild:directives. Docker Compose auto-loads the override file — you don’t need to pass any-fflags.
Updating after a code change
Whenever the codebase changes — agit pull, a local edit, or a submodule bump — rebuild the api and ui images and recreate the running containers so they pick up the new code.
TL;DR (rebuilds both services and restarts in one shot):
--build rebuilds any service whose build: context has changed (both api and ui are wired through the docker-compose.override.yaml written by setup_remote.sh), and up -d recreates the affected containers so they run off the new image.
Step-by-step — use this when you’re pulling fresh code from a remote, or want to be explicit:
pip install was added, or you suspect a stale layer:
CREATED column shows a recent timestamp, not minutes/hours ago:
docker-compose.override.yaml and start the stack with --pull always as in the prebuilt flow.
Build mode is for fork maintainers and self-hosters who want to deploy customized images — not for active development on the code itself. For day-to-day contributor work (fast reload, IDE/LSP integration), use the contributor setup instead.