[Feature Request] Official Docker Image for Self-Hosted Outerbase Studio

[zero8d]

Feature Request: Official Docker Image for Self-Hosted Outerbase Studio

Summary

Provide an official Docker image for outerbase/studio so anyone can spin up their own instance in a self-hosted environment, keeping all credentials and data on their own infrastructure.

Motivation

• Self-Hosting & Data Sovereignty
  Many organizations and individuals need to keep database credentials and sensitive data entirely within their private networks—rather than in a cloud-hosted control plane.

• Ease of Deployment
  A Docker image lets users launch a full Studio stack with a single command, without having to build or configure services by hand.

• Isolation & Compliance
  Containerizing the application enforces clear boundaries between Studio and other services, aiding regulatory compliance and reducing risk.

Proposed Solution

1. Dockerfile

   • Base on a minimal image (e.g. node:alpine).
   • Build the production UI and backend.
   • Expose the application port (default 3000).

2. Publish to Docker Hub

   • Under outerbase/studio, tagged by version (e.g. v1.2.3) and with a floating latest tag.

3. Comprehensive README

   • Show how to pull and run:

     docker run -d \
       -p 3000:3000 \
       -e STUDIO_USER=admin \
       -e STUDIO_PASSWORD=secret123 \
       -e DB_HOST=mydb.local \
       -e DB_PORT=5432 \
       -e DB_USER=dbuser \
       -e DB_PASSWORD=dbpass \
       --name outerbase-studio \
       outerbase/studio:latest

   • Explain how to persist Studio-specific data (via volumes) and how to connect to any external or self-hosted database.

Security & Credentials Management

• Local Environment Variables Only

  • Database credentials (DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, etc.) are supplied via Docker environment variables, so they never leave your host.
  • The container will fail fast if any required DB variables are missing or blank—preventing startup with missing credentials.

• App-Level Authentication

  • Require STUDIO_USER and STUDIO_PASSWORD as env vars for the web UI.
  • Container will refuse to start without them, logging no defaults.

• Isolation Recommendations

  • Bind the service to localhost only (-p 127.0.0.1:3000:3000) when exposing behind a secured reverse proxy (e.g., with TLS).
  • Use Docker restart policies (--restart unless-stopped) for high availability.

Example Deployment

docker run -d \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v outerbase-data:/data \
  -e STUDIO_USER=admin \
  -e STUDIO_PASSWORD=$(openssl rand -base64 16) \
  -e DB_HOST=127.0.0.1 \
  -e DB_PORT=5432 \
  -e DB_USER=studio_user \
  -e DB_PASSWORD=$(openssl rand -base64 24) \
  --name outerbase-studio \
  outerbase/studio:latest

Benefits

• Full control over where credentials live—on your own servers or network.
• Simplified setup with no cloud-hosted dependency.
• Best-practice security via container isolation and explicit credential management.

---

Thank you for considering this feature request. Dockerizing Outerbase Studio will empower users to self-host securely, keeping all credentials and data under their own control.