Skip to content

Install it ​

dqx is a single binary. It needs a backend to drive — Docker Desktop unless you have chosen otherwise — and it will tell you what else is missing rather than failing halfway.

bash
curl -fsSL https://dqx.dolphiq.nl/install.sh | bash

macOS today

Both Mac architectures are published. Linux and Windows builds exist and are tested but are not published yet — dqx self-update says so plainly rather than failing at a download.

What it checks before you start ​

The first dqx install in a project checks the machine, not just the project. A clean Mac otherwise gets through cloning, composer and npm and then fails at up with a Docker socket error, having never said the word "install".

It looks for, and offers to install:

  • the backend — Docker Desktop, or DDEV, Lerd or Herd if the project pins one
  • mkcert and its root certificate, so https:// on a local domain is green rather than a warning
  • a resolver for .test, if the project serves domains under it

It names every command before running it. Nothing is installed behind your back.

Keeping it up to date ​

bash
dqx self-update

It reads the release manifest, compares versions, and replaces the binary in place.

Per project ​

Nothing to install. In a project that already uses dqx:

bash
cd ~/projects/some-project
dqx install

That clones what is missing, generates the environment, starts it, and runs the project's own install steps. It checks it can reach every repository before it starts, so a missing SSH key fails in the first second rather than the tenth minute.

If something goes wrong ​

"dqx cannot be opened because the developer cannot be verified." The binary carries an ad-hoc signature rather than a Developer ID one — it is built and signed by the release pipeline, which has no Apple account and no way to notarise. macOS then decides by how the file arrived: fetched with curl it is not flagged, saved through a browser it gets com.apple.quarantine and Gatekeeper refuses it. Use the command at the top of this page and it never arises. If it already has:

bash
xattr -d com.apple.quarantine ~/Downloads/dqx-darwin-arm64
chmod +x ~/Downloads/dqx-darwin-arm64

Nothing about the file changes — the same binary, minus the note saying where it came from.

It installed but the shell cannot find it. The installer puts the binary in ~/.local/bin. If that is not on your PATH, add it:

bash
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc && exec zsh

self-update says your platform is not published. Linux and Windows builds exist and pass their tests, but nothing publishes them yet. Building from a checkout works everywhere: bun install && bun run link.

You are reading this on staging. The install line carries the address of the site it is on, so a staging page installs the staging build and that binary keeps reading staging's manifest. Deliberate: somebody testing a release is not silently updated back to the previous one.

You are working on dqx itself. A checkout can take over the dqx on your PATH and give it back again — see Running your checkout. dqx version --where says which of the three you are running.

Anything else — dqx doctor checks the machine as well as the project, and names what it finds rather than what it suspects.

How the Mac binaries are built ​

Cross-compiled on Linux, which is less of a trick than it sounds: bun takes the runtime for the target and appends the bundle, and the result is a Mach-O arm64 carrying the ad-hoc signature Apple Silicon requires to run anything at all. Verified by building one in the release image and running it on a Mac — config get, sites and generate all answered, embedded templates included.

dqx v1.1.0