Self-Host Dory

Self-hosting Dory is useful when your team wants to control the deployment environment, access boundaries, database credentials, AI provider configuration, and application data persistence. The public repository currently supports a Docker-first deployment path.

Dory has two different database concepts:

This page is about the first one: where Dory stores its own application data.

Who Should Self-Host

• Teams running Dory in a private network or cloud environment.
• Teams managing their own database credentials and AI keys.
• Teams that need a shared browser-accessible workspace.
• Teams connecting to private, cloud, staging, or production databases.

Recommended Architecture

1. Dory Docker container.
2. Persistent application data storage.
3. Reverse proxy with HTTPS.
4. Secret-managed .env values.
5. Network access to target databases.
6. Email and OAuth providers when needed.

Persistence Options

Choose one application database mode before production rollout.

Do not run a long-lived Dory container without persistent storage. If the container writes to its internal filesystem only, Dory workspace data can be lost when the container is removed or recreated.

Option 1: PGlite with Docker Persistent Storage

PGlite is Dory's default application storage mode. In Docker, the default PGlite path is /app/data/dory, so you should mount /app/data to durable disk storage.

Use a named Docker volume:

docker volume create dory-data

docker run -d --name dory \
  -p 3000:3000 \
  --env-file .env \
  -e DB_TYPE=pglite \
  -v dory-data:/app/data \
  dorylab/dory:latest

Or use a host directory when you want the files to live in a known server path:

mkdir -p /srv/dory/data

docker run -d --name dory \
  -p 3000:3000 \
  --env-file .env \
  -e DB_TYPE=pglite \
  -v /srv/dory/data:/app/data \
  dorylab/dory:latest

You can override the PGlite file path with PGLITE_DB_PATH, but keep the path inside a mounted directory:

DB_TYPE=pglite
PGLITE_DB_PATH=/app/data/dory

Back up the mounted directory or Docker volume before upgrades.

Option 2: Postgres for Production

For production environments, Dory can use Postgres as its application database. This is useful when your team already has managed Postgres, centralized backup policies, monitoring, and restore workflows.

Example .env:

DB_TYPE=postgres
DATABASE_URL=postgres://dory:strong_password@postgres.example.com:5432/dory
POSTGRES_SSL=true
POSTGRES_SSL_REJECT_UNAUTHORIZED=true
POSTGRES_MAX_CONNECTIONS=10

Then run Dory with the same application secrets and public URL settings:

docker run -d --name dory \
  -p 3000:3000 \
  --env-file .env \
  dorylab/dory:latest

Use a dedicated Postgres database and a dedicated Dory database user. The user should be able to connect, create and update Dory application tables, and run migrations for the Dory schema.

PGlite vs Postgres

Preflight Checklist

Rollout Steps

1. Prepare .env.
2. Choose PGlite or Postgres for Dory application storage.
3. Configure persistent storage:
   • PGlite: mount /app/data to a Docker volume or host disk.
   • Postgres: create the Dory database and set DATABASE_URL.
4. Start the Docker container.
5. Configure HTTPS reverse proxy.
6. Sign in with the initialized user.
7. Change credentials or configure team login.
8. Add a test database.
9. Validate SQL Console, Explorer, AI Chat, and Saved Queries.
10. Add production databases with readonly accounts first.

Production Advice

• Use readonly database accounts for production analysis.
• Create dedicated database users for Dory.
• Allowlist the Dory server egress IP for cloud databases.
• Use SSH tunnels for private databases when needed.
• Mount SQLite and DuckDB files through Docker volumes.
• Keep AI keys and database credentials out of Git and images.

Database Connection Security

Use separate database credentials for Dory, prefer readonly users for production, document who owns each connection, and rotate shared credentials when team access changes.

Backup and Restore

For PGlite:

• Back up the Docker volume or host directory mounted at /app/data.
• Stop the container before taking a file-level backup when possible.
• Restore by mounting the recovered directory back to /app/data and starting the same or newer compatible Dory image.

For Postgres:

• Use your managed Postgres snapshots, point-in-time recovery, or pg_dump.
• Back up before Dory upgrades.
• Test restore into a staging Dory deployment before relying on the backup plan.

AI Data Boundary

Dory AI sends necessary context to the configured AI provider. Before rollout, decide which provider is allowed, whether schema or result summaries may be sent, and how keys are rotated.

Upgrade Checklist

Back up persistent data and .env, record the current image, test the new image, then verify login, connections, SQL Console, AI, Saved Queries, MCP tokens, and team access after deployment.

Practices to Avoid

• Do not expose an unconfigured instance directly to the public internet.
• Do not use shared admin database credentials for all users.
• Do not rely on local container storage without backups.
• Do not enable AI providers without understanding data boundaries.

Related Docs

• Docker
• Environment Variables
• Auth / SSO
• Cloud Databases