On the head-office LAN, deployment traffic is invisible. Across a branch link it is arithmetic: one installer, times every PC, over a pipe the branch also uses for its actual work. This guide does that arithmetic honestly and lays out the working patterns — local file copies, waves and night windows.
First, the fact that drives everything: PDQ Deploy copies the package files to each target — there is no built-in peer-to-peer sharing where one branch PC fetches the installer and neighbours copy it from there. So a 1 GB package to 40 branch PCs is 40 GB across the link unless you change where the files live. Everything below follows from accepting that reality instead of hoping around it.
The highest-value move: put the installer files on a server or share at the branch itself and point the package step's file path at that local UNC path. The big file crosses the WAN once (or arrives on a drive), and every target copies it at LAN speed. You can keep per-branch copies of big packages in PDQ, or schedule the cross-WAN copy for the night before the deployment window. This is a manual pattern, not a magic feature — and it is the one real offices actually use.
Even with files staged locally, forty simultaneous installs strain a small branch server and its switches less politely than ten at a time. Split branch targets into waves an hour apart with schedules, and run the heavy jobs in the evening window the branch agrees to. Sequencing is boring, free, and effective — most bandwidth pain in deployment is concurrency pain wearing a disguise.
PDQ Deploy is a LAN-first, agentless tool. It does not offer the peer-distribution or cloud-relay behaviour of agent-based cloud systems — for a fleet that lives on the internet rather than on reachable networks, PDQ's own answer is PDQ Connect, a different product with a different architecture. Knowing this boundary before you design a multi-branch system saves an expensive discovery later; within reachable networks, the staging and wave patterns above carry deployments much further than most offices expect.
Before redesigning anything, time one deployment of the real package to one branch PC and watch where the minutes go — file copy or install. If the copy is fast but the install crawls, your problem is the target hardware, not the WAN, and waves will not fix it. Two minutes of measurement keeps the whole project aimed at the constraint that actually exists.
Watch the video for the deployment mechanics, then apply the staging pattern to your heaviest package first — that is where the hours come back.
▶️ Watch Full VideoPDQ Deploy's model is per-target file copies from the console or repository, and offices manage WAN load with staging, waves and scheduling rather than a single throttle switch. Whatever the current version offers, confirm it in PDQ's own documentation for your edition before designing around it — the patterns in this guide work regardless.
Not through a built-in peer-to-peer feature. The practical equivalent is the staged-share pattern: the installer sits on a branch-local server or share, and each target copies from there at LAN speed. The effect on the WAN is the same — one crossing instead of forty.
Where most of its targets are. A console at head office deploying mostly to head-office PCs is right; if the fleet is split across sites with a serious share at one branch, a second console or a staged repository there earns its keep. Let the traffic arithmetic, not habit, decide.