What dqx is

dqx runs local development environments. You describe a project once - its sites, its PHP version, its database, whatever else it needs - and dqx generates and runs the environment for it.

That description lives in .dq/config.yml, in the project's own repository. It is the only file you maintain by hand.

The problem it was written for

A development team accumulates projects, and each one arrives with its own way of being started. One has a docker-compose.yml somebody wrote three years ago; the next has a shell script that assumes a directory layout nobody uses any more; a third works only if you remember to run two commands in the right order. None of them are wrong. Together they are a tax paid every time somebody joins, changes machine, or comes back to a project after six months.

The usual answers each solve part of it. A shared compose file drifts from the project it describes. A wrapper script becomes its own dialect. A managed tool decides how your project must look.

dqx takes a narrower position: the project declares, the tool generates. Nothing is hand-written per project except the declaration, and the environment is disposable - delete it, regenerate it, get the same thing back.

What that buys you

One command, whatever the project is. dqx up starts a single-site Laravel application and a five-site WordPress project the same way. So do dqx shell, dqx composer, dqx test, dqx db.

Every project served at once. A shared reverse proxy holds ports 80 and 443, and each project gets its own domains behind it with a locally trusted certificate. Two projects running together is the normal case, not a port conflict to resolve.

A copy per task, beside the original. dqx clone and dqx agent-env write a second copy of a project on its own domains, with its own database and its own containers, while the original keeps running. A checkout can be a git worktree of the original's repository, so a commit made in the copy is in that history without pushing anything.

Docker is the stack. dqx generates the whole docker-compose stack from the declaration, which is what the dashboard, the copies and the agent environments are built on. It also adopts and runs projects on DDEV, Lerd and Herd, and dqx switch moves one between them without the repository noticing - those get the CLI, not the three features above.

The whole machine in one page. dqx dashboard lists every project with what is running, what is broken and what it holds in memory, and every button on it is a dqx command you could run yourself. dqx self-update keeps it current without closing the tab.

Agents that ask instead of guess. dqx ships an MCP server: an agent asks where a site's code lives, what to run and where the database is, and gets the same answer a developer would. Given its own copy with dqx agent-env, it can break things there without touching yours.

Pull requests reviewed with Claude. dqx review has Claude read only the changed lines of a pull request on Bitbucket or GitHub, in a throw-away worktree with no shell. You pick the findings worth posting, edit them if you like, and they land on the pull request under your name with a footer that says a model wrote them. The dashboard has a tab for it, with the findings laid out like the diff.

Next to Herd and Valet. dqx serves new projects on .dqx domains, and dqx loopback moves its router to 127.0.0.2, so Herd or Valet keep 80 and 443 on 127.0.0.1 and both run at once.

Browser tests against the real site. dqx e2e runs Playwright inside the stack, over https, against a database the suite may reset - the same URLs a person opens. The dashboard runs it from the project's card.

Answers instead of silence. The failures that cost the most are the quiet ones: a site that returns 200 while every query fails, a worker restarting in a loop behind a healthy-looking stack, a config that names a database nothing creates. dqx doctor is a list of those, each with what to do about it.

What it is not

• Not a hosting or deployment tool. It builds the environment on your machine. What runs in production is your pipeline's business.
• Not a framework. It has opinions about environments, none about your application.
• Not a replacement for Docker, DDEV or Herd. It drives them. When one of them does something better, dqx uses it rather than reimplementing it.

Where to go next

• Install it - one command, then one more per project.
• Your first project - create one from scratch, or adopt one that exists.
• Choosing a backend - what each one costs and what it cannot do.
• The shared router - how every project serves at once on 80 and 443.
• The dashboard - every project on this machine, in a browser.
• Reviewing a pull request - Claude's findings, and you decide what is posted.
• Next to Herd, Valet or Sail - running dqx beside the tools you already have.
• What dqx stores - credentials, certificates and what gets committed.