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.

The backend is a choice, not a rewrite. The same declaration runs on Docker Compose, DDEV, Lerd or Herd. Changing your mind is dqx switch, and the project's repository does not notice.

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.