Trust

Air-gapped installs

For a site whose servers have no route to the internet, or whose security team wants to be able to prove they have none that matters. A default Draughtsman makes no outbound network connection. This page says what to carry across, what can call out if an administrator switches it on, and how to check it on your own machine.

What to carry across

Fetch these on a connected machine, check them there, and move them on whatever media your site allows. Downloads are provided to licensed customers; see Licensing.

Nothing else: no .NET runtime, no Node, no package manager, no container registry and no database server. No container image is published; the one supplied with your licence is a file you carry across and load (docker load), which Overpass's guide describes and which we did not run.

Install, licence, PDF, backup and upgrade with no network

• Install. Check the checksum, unpack, and follow Install. The archive downloads nothing at first run or later: the layout runtime is inside it, SQLite is inside the executable, and the web app's fonts, scripts and styles are served from the same folder. The archives are not yet code-signed, so the first run on macOS or Windows is stopped by Gatekeeper or SmartScreen exactly as on a connected machine.
• Licence. A signed file you carry across and put in the data folder; the server re-reads it with no restart. Whether a build is covered depends on the date the build was made, never on the server's clock, so a drifting clock on an air-gapped host cannot expire anything. (No production verification key is built in yet; see Licensing.)
• PDF. The editor's File, Export PDF… draws the diagram in the browser and opens the browser's print dialog; nothing is installed and nothing is sent to the server. Server-side PDF, for scripts and agents, needs a Chrome, Chromium or Edge on the server; the server never downloads one. See PDF.
• Backups are local files: draughtsman backup writes one zip wherever you point it. See Backup, restore and upgrading.
• Upgrades are a new file carried across, then draughtsman config check with the new program, then the same procedure as anywhere. See Upgrading safely. Nothing is fetched during an upgrade.

What leaves your network, and when

No licence check, update check, usage telemetry or crash reporter. The layout process (the Node sidecar) is a child of the server that talks over a pipe and opens no socket.

Check it on your own machine

Do not take this page's word. These are the checks we ran on the current build, with their real output.

1. Scan what ships to a browser and to the layout process. Overpass's build-time checker (it runs on every release build and is not part of the archive) fails on any external host or network module in the built web app or the sidecar bundle:

   Run for real

   $ check-offline-bundles all   (Overpass's build-time check; not shipped)
   check-offline-bundles: web: no external host, no network module
   check-offline-bundles: sidecar: no external host, no network module
   [exit 0]
   

2. Look at the sockets while the server is running. One listening socket, and the layout process has none; the layout process can load only node:crypto and node:readline:

   Run for real

   $ lsof -nP -a -p <server pid> -i
   COMMAND NODE NAME 
   draughtsm TCP 127.0.0.1:58941 (LISTEN)
   $ lsof -nP -a -p <sidecar pid> -i   (the layout process, a child of the server)
   0 lines of output (no sockets)
   $ grep -oE 'require\("[^"]+"\)' sidecar.js | sort -u
   require("node:crypto")
   require("node:readline")
   

3. Read the policy that stops the browser. curl -sI http://localhost:5180/ | grep -i content-security-policy prints a policy whose connect-src is 'self', so a request to any other origin is blocked by the browser itself. We read it from the running server above, and the Security page shows the browser's own request list (every request to the server's own origin).

4. Block it and see. Put the host behind a default-deny egress firewall for a day. Nothing changes. We did not run this one.

Overpass also runs, on every build, a test that listens inside the server process to every name lookup, connection and handshake the runtime announces while it is driven through a day's work, and a run of the Docker image with --network none. We read about these in the guide and did not repeat them; they are not a substitute for the checks above on your own machine.

The software bill of materials

Every release carries a CycloneDX 1.5 list of the NuGet packages of the server, the npm packages bundled into the web app and the layout process, and the bundled Node runtime, each with its version, licence and package URL. It is inside every archive, beside the archives, and checked as not hollow by the release scripts. It is a flat list; it leaves out the .NET runtime (its notices are in each archive), the container's base layers and the optional Chromium. Overpass validated it once against CycloneDX's own schema; we did not run any SBOM consumer.

What this does not prove

• The in-process test sees the server only. The layout process and, when enabled, Chromium are other processes, covered by a static check and by being off by default, not by a packet capture.
• A default configuration. An administrator who sets an AI endpoint, a mail server or a Postgres connection has chosen to reach that host.
• Anything outside the product: the operating system's own update services, browser extensions, the build tooling, the reverse proxy.
• A connection from a default Draughtsman to anything but a client of yours is a bug. Tell us, with what lsof showed and the version from About: draughtsman@overpass.co.uk (see Reporting a vulnerability).