Skip to main content
Harmanpreet Singh
All work

Independent project: Developer tool

myDocker: a launch dashboard for local Docker projects

A local control plane that finds every project in a folder, gives each one its own non-colliding host ports, and starts, stops and rebuilds them through Docker Compose from one page and one terminal, instead of a dozen compose files fighting over port 3000.

What it is

Every project I build ships its own compose file with the same ports hard-coded, so two of them cannot run together. myDocker reads the projects folder, assigns each published port the next free number in a range for its role (frontends from 3000, backends from 4000, everything else from 5000), and remembers the choice in a committed registry file so a project keeps its ports across restarts.

It does this without editing the projects it manages unless asked. On every compose call it writes an env file and a compose override under a git-ignored folder, so the project's own .env files are never touched. An Adopt action shows a diff and then rewrites only the ports lines of a compose file, and Generate Docker writes a Dockerfile and compose file for a Node project that has none, without overwriting anything that exists.

Day to day it is a widget per project (status, ports, git branch and changes, memory, and a hint when code is newer than the image) plus a terminal: select a project, then type up, stop, restart, logs, open, rebuild or run a task from a dashboard.json file in the project. It deliberately has no start-all, since building many stacks at once can freeze a machine, and it builds at most two images in parallel.

My part

I designed and built the dashboard, the port allocator, the compose handling and the terminal.

Independent project, written for my own machine. It controls the local Docker engine and binds to 127.0.0.1 in production mode.

Stack

  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind CSS 4
  • dockerode
  • Docker Compose
  • Vitest

What is inside

A Next.js app that discovers projects on disk, talks to Docker through dockerode for status and logs, and runs Docker Compose through execFile for everything that changes state.

  1. 01

    Discovery

    Compose files are looked for in the project root and then in infra, infrastructure and deploy. Production, test and thread variants are ignored, and a project whose compose config fails is shown with its error while the rest keep working.

  2. 02

    Port registry

    Each published port gets the next free number in its role's range, skipping numbers already bound on the host. The registry is a committed JSON file that can also be edited from a card.

  3. 03

    Generated overrides

    Compose variables a project already reads are supplied through a generated env file, and services that hard-code a host port get a generated override using the Compose ports override tag, which needs Compose 2.24 or later.

  4. 04

    Streaming terminal

    Commands run as streamed jobs, so build output appears as it happens. Only one build runs at a time and a second action on a busy project waits.

  5. 05

    Tasks

    A project's dashboard.json maps names to shell commands that run on the host in the project folder. The exact command is printed first, and tasks work for projects with no Docker setup.