Dreamer Docs

Dreamer is a self-hosted PaaS that runs entirely on one box you own — GitHub import, automatic framework detection, a real build pipeline, and two independent deployment runtimes (static files on a MinIO object store, server-rendered apps as Docker containers), all fronted by a routing-aware reverse proxy behind nginx.

This isn't a marketing site. It's the same documentation style you'd expect from Vite, Next.js, or Vercel's own docs — how each piece actually works, why it's built the way it is, and enough detail that you could rebuild it yourself from these pages alone.

Start here

If you're new to this system, read these in order:

  1. Architecture Overview — the whole system in one page: every container, how they talk to each other, and the full lifecycle of a request from git push to a live URL.
  2. Authentication — the single-admin model, the one-time setup endpoint, JWT access tokens, rotating refresh tokens, session management.
  3. Projects & the Import Wizard — turning a GitHub repo into a Project row: slugs, ownership, settings.
  4. Framework Detection — how a repo gets turned into a build config: lazy directory fetching, the preset table, the detection algorithm, and how you override what was auto-detected.
  5. Deployments — the shared pipeline both deployment types run through, then split into two from-scratch deep dives:
  6. reverse-proxy — the single ingress point for every deployed app, request by request.

Other references

  • Self-Hosting Guide — installing and operating the whole stack on your own VPS, from install.sh to day-2 operations.

The nine containers, at a glance

ServiceWhat it doesReachable from
nginxTLS termination for deployed apps + custom domainsThe internet, *.yourdomain.com only
frontendThe dashboard — Next.js127.0.0.1:3000 on the box only
api-serverREST API + realtime gateway; owns the Docker build/run engine127.0.0.1:8000 on the box only
build-workerDequeues build jobs, launches build-engine containersNothing external
build-engineNot a long-running service — launched fresh per build, exits when doneNothing external
reverse-proxyRoutes every deployed app's traffic to MinIO or to its app containerNothing external (nginx proxies to it)
postgresEvery Project, Deployment, User rowNothing external
redisBuild queue, log pub/sub, routing cacheNothing external
minioObject storage for static deployment outputNothing external

The dashboard being loopback-only — reachable via an SSH tunnel, not a public hostname — is deliberate, not an oversight. See the Architecture Overview for why each surface of the system gets exactly the network exposure it needs and no more.