Docker
SynapseOrch ships a Docker image that bundles the Python backend and Next.js frontend into a single container. Docker Compose is also supported, with its own Postgres.
Single container (quickstart)
docker run -d \
--name synapse \
-p 3000:3000 \
-p 127.0.0.1:8765:8765 \
-v synapse-data:/data \
-v /var/run/docker.sock:/var/run/docker.sock \
synapseorchai/synapse-ai:2.0.0-rc3| Flag | Purpose |
|---|---|
-p 3000:3000 | The UI, and the external API at /api/v1 and /api/v2 |
-p 127.0.0.1:8765:8765 | The backend, on this machine only. Needed for OAuth sign-ins — Google Workspace and remote MCP servers redirect the browser to localhost:8765. Leave it out if you use neither |
-v synapse-data:/data | Persist everything: the SQLite database (agents, workflows, settings, keys), the vault and run logs, and the generated internal token and access link |
-v /var/run/docker.sock | Required for the Python sandbox and Transform steps |
Once the container is running, open the access link it prints in its log — docker logs synapse shows [entrypoint] Access link (used while login is off; …) and the http://localhost:3000/?token=… address below it. See The access link.
The image generates an internal token and an access link on first start, so neither the backend's internal routes nor the UI is left open. Don't publish port 8765 beyond 127.0.0.1, and turn on sign-in (Settings → General) before exposing port 3000 to a network.
Passing API keys
Model provider keys are not read from environment variables — -e ANTHROPIC_API_KEY=… does nothing. After startup, open Settings → Models, fill in the provider's card and click Save. Keys are stored in the database on the /data volume. See Cloud Providers.
Docker Compose
The repository's docker-compose.yml runs the backend, the frontend and a Postgres database as separate services:
# Clone the repo
git clone https://github.com/synapseorch-ai/synapse-ai.git
cd synapse-ai
# Copy the env file — the defaults work as they are
cp .env.docker .env
# Start services
docker compose up -dLeave SYNAPSE_INTERNAL_TOKEN blank in .env: the containers generate one and share it through a volume. Open the access link the backend prints in its log (docker compose logs backend).
Compose file overview
| Service | Container | What it runs | Port |
|---|---|---|---|
backend | synapse-backend | The API server (Dockerfile.backend), using the Compose Postgres as its store | 8765, bound to 127.0.0.1 |
frontend | synapse-frontend | The UI (Dockerfile.frontend), reaching the backend at http://synapse-backend:8765 | 3000 |
postgres | synapse-postgres | Postgres 16 | — |
| Volume | Holds |
|---|---|
synapse-postgres-data | The database |
synapse-blobs | The vault, run logs and caches |
synapse-secrets | The generated internal token and access link |
./backend/data (mounted at /legacy-data) | A 1.x Compose install's data, imported once on the first boot |
The backend also mounts the Docker socket, for the Python sandbox. docker compose --profile scale up -d, with REDIS_URL=redis://synapse-redis:6379/0 set in .env, adds Redis and workers — see Scale Deployment.
To reach the backend from other machines, set SYNAPSE_BACKEND_BIND=0.0.0.0 in .env — usually unnecessary, since the external API is served through port 3000.
Custom port
Change the host side of the port mappings and leave the container's own ports alone:
docker run -d \
--name synapse \
-p 4000:3000 \
-p 127.0.0.1:8765:8765 \
-v synapse-data:/data \
-v /var/run/docker.sock:/var/run/docker.sock \
synapseorchai/synapse-ai:2.0.0-rc3The UI is then at http://localhost:4000. The single-container image's frontend was built to reach its backend on port 8765 inside the container, so changing SYNAPSE_BACKEND_PORT there breaks it. Keep the backend on host port 8765 as well if you use OAuth sign-ins, whose redirect addresses name that port.
The access link in the log still says :3000; open it with your host port instead.
With Compose, set SYNAPSE_FRONTEND_PORT in .env and leave SYNAPSE_BACKEND_PORT at 8765: the backend's mapping, its health check and the frontend's address all name 8765.
Updating the image
docker pull synapseorchai/synapse-ai:2.0.0-rc3
docker stop synapse && docker rm synapse
# Re-run the docker run command aboveYour data is persisted in the synapse-data volume and is unaffected by image updates.
Upgrading from 1.x
Images before 2.0 used the same synapse-data volume at /data, so the same
docker run upgrades in place: on the first boot, the 1.x data on the volume is
imported into the new database and the old files are moved to /data/migrated/.
An internal token already on the volume is kept. The same Compose file
upgrades a 1.x Compose install: ./backend/data is imported on the first boot
and its files move to ./backend/data/migrated/. See
Upgrading to 2.0.
Python sandbox inside Docker
The Python sandbox needs the Docker socket so it can start sandbox containers. Mount /var/run/docker.sock as shown above. Without it, execute_python, Python tools and Transform steps fail; all other tools continue to work.
Available images
| Image | Description |
|---|---|
synapseorchai/synapse-ai | Combined backend + frontend — the image above |
synapseorchai/synapse-ai-api-server | The backend only |
synapseorchai/synapse-ai-worker | A scale mode worker |
Each is tagged with the release version and latest.
The images include neither the knowledge extra nor LibreOffice, so a knowledge base reads every format except images, HEIC photos and legacy Office files — see Formats and parsing.