Docker Config

Service-level Docker reference for current host ports, responsibilities, and persistence boundaries.

by @saifyxpro

Core stack

The Docker infrastructure lives under infra/docker.

Current core services are centered on:

| Service | Default role | Host port | Internal port | | --- | --- | --- | | PostgreSQL | persistent app state | 35432 | 5432 | | Redis | queue and crawl infrastructure | 36379 | 6379 | | API | backend HTTP and MCP | 38473 | 8000 | | Worker | queued background jobs | none exposed | none exposed | | Web | dashboard and playground | 34872 | 3000 | | HTML-to-Markdown | content extraction helper | 38081 | 8080 | | yt-engine | YouTube extraction engine | 38090 | 8090 |

What Docker is best at here

  • repeatable service boot
  • consistent infrastructure across operators
  • faster onboarding for self-hosted users
  • cleaner separation between app runtime and dependencies

What still needs attention

The full Docker stack now includes yt-engine by default, and the shared browser profile persists across restarts through the browser_profile volume.

Compose usage

The safe current compose path is:

Volumes and persistence

You should treat these as persistent:

  • PostgreSQL data
  • Redis if you depend on durable queue state
  • application-managed runtime data like browser profiles or temp artifacts, depending on your deployment policy

Important current example:

  • the Google AI Search cookie bootstrap and shared Headfox JS profile persist through the Docker browser_profile volume

Operational advice

  • use Docker for infrastructure even if you prefer local app processes
  • keep environment files outside image definitions
  • document any port changes together with NEXT_PUBLIC_API_URL, FRONTEND_URL, and service URLs
  • keep host-side ports rare, but keep container-internal ports stable for Docker networking