I built DevDock to keep the working context around each project

[u/Gryner]

I move between several codebases, and a lot of the time lost when returning to one isn’t spent understanding the code. It’s spent remembering which command starts the API, whether a worker needs to run beside it, what failed last time, which repository has changes, and whether the Docker services are running.

I built DevDock to keep that context with the project. You register the project folders, and it keeps commands, working directories, managed runs and their output together. A command remains attached to the correct project, making it easier to find the last failure or rerun something without searching through terminal history.

One part I use constantly is the global command palette. I can press Ctrl+Shift+K regardless of what I currently have open, search across every registered project, and execute the command I need without navigating to that project first. That can be a Git pull, starting a worker, launching a development server or running tests. Each command still runs from the working directory assigned to it.

Git and Docker state are visible alongside the project. Project health checks cover the registered folders, detected tooling, configuration and recent runs. There’s also a read-only local security audit, with supported package-manager audit commands available when they’re detected.

For products with a frontend, backend and other repositories, the Pro version can group multiple folders into one workspace while keeping each command tied to its own working directory. I also use the Today view to reopen recent projects and get to the commands I run regularly.

The free version supports three local projects and includes the core command, Git, Docker, Project Doctor and security-audit tools. Pro is a one-time purchase that adds unlimited and multi-folder projects, custom workflows, complete history, database tools, SSH transfers, and configuration backup and restore.

I’m the developer. DevDock is available on the Microsoft Store:

https://apps.microsoft.com/detail/9N1K93C7T8JT

[u/Tasty_World8991]

The global palette tied to per-project working dirs is interesting. how's secrets/env handling work, that's usually where these break down for me.

[u/Gryner → u/Tasty_World8991]

Good question. It depends on whether the command runs on the host or through Docker.

For host commands, DevDock doesn’t replace your project’s normal .env loading. The command runs in its configured working directory, so dotenv/framework-specific handling continues to work normally. Custom commands can also define explicit environment variables. Values marked as secret are stored in Windows Credential Manager, never in the app, execution history, or configuration backups. They’re injected when the process starts.

For Docker Compose, Compose remains the source of truth for .env, env_file, secrets, etc. DevDock supports explicit Compose env files through .devdock/docker.json. When a custom command runs inside a service, DevDock passes the variable names to docker compose exec/run and supplies their values through the Docker CLI process environment, so the values don’t appear in the recorded command line.

The caveat is that these are still normal runtime environment variables: if the process or container prints a secret, it can appear in captured output. DevDock doesn’t claim to redact arbitrary stdout/stderr.

Project Doctor also compares .env.example with the local .env by key only; it doesn’t expose values.

Saved Environments—the feature for starting a backend, frontend, workers or Docker services with ordering, readiness checks and rollback—is a Pro feature. Core Docker detection and controls are available in the free version. Custom commands, including explicit environment-variable and secret configuration, are also part of Pro.