Start here

Who this is written for

dqx is written at Dolphiq, for our own fleet and for the developers of partners who work on projects that use it. The examples are our own container images and domains, and both are public: the images are on Docker Hub and *.local.dolphiq.eu resolves to 127.0.0.1 for anybody.

If you are not at Dolphiq, one page covers the differences - it is short.

I want to...

Get a project runningInstall dqx, then create or adopt your first projectSee everything on this machineThe dashboard in a browser, or dqx list in a terminalWork out why something is brokenStart with dqx doctor: what is wrong here, and what to do about itChange a domainHow a name resolves, what answers on 443, and the gear that renames oneReach the database or the mailService names inside the container, a port of the project's own outside itRun a copy beside the originalA second copy of a project, on its own URLs, at the same timePut an older project on dqxAdopt what exists rather than rewriting itCreate a project from a recipeScaffolds create the application, not only the environmentUnderstand what runs whereThe shared router, and single against multi layoutLet an agent read my environmentThe MCP server, and what it will not doHave Claude review a pull requestPick the findings worth posting, from a terminal or the dashboardGit and reviewRepositories, branches, hooks, copies and pull request reviews in one placeRun the browser testsPlaywright in the stack, against the real site over httpsKeep Herd or Valet runningdqx beside them, on its own address and its own domainsLook up a key or a commandEvery config key from the schema, every command from the CLITake dqx off this machineThe binary, its state, and the two things it asks of your system

The five commands that cover most days

dqx up            # start this project, and the shared router if it is not running
dqx down          # stop it
dqx shell         # a shell in the site you are standing in
dqx db --url      # the database URL, for a GUI client
dqx doctor        # what is broken here, and what to do about it

Every command works from anywhere inside a project: dqx walks up to find .dq/config.yml, the way git finds a repository, and the directory you are standing in picks the site.

If you have never seen dqx before

What dqx is is the two-minute version: a project declares what it needs, dqx generates and runs the environment for it, and the backend is a choice rather than a rewrite.

Words that mean something specific here

site	One domain and one docroot. A project can serve several
checkout	A directory holding one repository's code. Several sites can be served from one
client key	The short name that prefixes container names and the default schema, from client.key
layout	Whether the application repository is the project (single) or a wrapper holds checkouts under www/ (multi). See layouts
the router	One Traefik container owning ports 80 and 443, so every project serves at once. See the shared router
backend	What actually runs the project: docker, DDEV, Lerd or Herd. See choosing one
scaffold	A named recipe that creates an application, not just the environment around it
adopt	Read a project that already exists and write its declaration, rather than rewriting the project
pre-router	A project whose own stack publishes fixed ports, served through an override that lasts only while it runs
not adopted	A directory with a stack and no usable dqx config. dqx shows it and runs docker compose for it
the gate	bun run test:gate - the build, the tests and the coverage floor that CI runs