Deploy
PDQ runs as a set of Docker containers. That is the whole deployment model — there is no PDQ-specific runtime, orchestrator or appliance underneath it. Anything that can run containers can run the platform: a cloud provider, your own hypervisor, or a single prepared VM.
What varies between installations is where each component sits relative to the data it touches, and how access to the platform is fronted and authenticated.
In this section
| Infrastructure & security | The architectural constraints behind the deployment: what depends on what, the systemd dependency chain, Caddyserver and Azure AD access, and how upgrades are handled. |
| Installing the components | The procedure: host requirements, disk and Docker preparation, and the startup sequence for AME, INGEST, DLS and DWA. |
The components you deploy
| Component | Role |
|---|---|
| AME (Active Metadata Engine) | Central metadata repository and API hub. Everything else reads its configuration from here. |
| INGEST | Extraction agents, one container per source connection. Placed close to the source system. |
| DLS (Data Lake Service) | Archives, standardises, profiles and publishes delivered files. |
| DWA (Data Warehouse Automation) | Generates SQL and orchestrates loading into the integrated model. |
| Developer UI | Web interface for configuring the above. |
| Caddyserver | TLS termination and authenticated access to the platform. |
Startup order matters
AME holds the metadata every other component reads at start-up. It must be running and reachable before INGEST, DLS or DWA are started. The full sequence is in Installing the components.