Version 31.4.5 puts the draw.io editor in a local desktop shell
draw.io Desktop 31.4.5 wraps the separate draw.io web editor in Electron and packages it for Windows, macOS, and Linux. The main reason to choose it is local work: diagrams live in files, the application requires no account, and diagram content is not sent to an analytics or storage service. It is the familiar draw.io editor with desktop file handling, native packaging, command-line export, and operating-system integration around it.
The repository division matters to anyone reading or changing the code. The Electron shell lives here, while the editor is the jgraph/drawio submodule. A normal clone therefore misses a large part of the application; the README requires a recursive clone. Our measured checkout included that source and contained 3,554 files, about 501,546 lines of source, and 169.6 MB before npm dependencies were installed.
Version 31.4.5 stays offline unless updates or remote media intervene
Version 31.4.5 ships its JavaScript inside the application and uses a Content Security Policy that blocks remotely loaded scripts. The README says the app sends no diagram data and no usage analytics. Its intended network exception is the update process, which checks GitHub at startup and downloads releases from GitHub-owned S3 storage. Administrators can turn that check off with DRAWIO_DISABLE_UPDATE=true or the --disable-update launch flag.
A diagram may still contain an image, background, or font referenced by URL. Opening that file fetches the external resource and can expose metadata such as the viewer's IP address to its server. No diagram body is sent, according to the project, but the request itself matters in a sensitive environment. For a strict offline workflow, disable updates and inspect or strip remote references before opening diagrams received from someone else.
What happened when we ran it
Our sandbox installed 323 npm packages in 11 seconds, and the dependency tree occupied 145 MB. The repository exposes no generic build script or target, so our harness skipped the build step rather than substituting a release command. We tested commit f5cc222 inside an unprivileged container with 3 CPUs and 8 GB of RAM. Installation completed without an error in that environment.
The Node test command finished in 5 seconds with 158 passed and 0 failed out of 158. Npm audit reported 0 known vulnerabilities: 0 critical, 0 high, 0 moderate, and 0 low. The repository scan found 7 CI workflow files, no Dockerfile, and no tests directory, although the package script points directly to test files under src/test. These results cover repository checks, not a graphical launch on all 3 supported operating systems.
The missing generic build target is worth reading literally. Package scripts exist for Windows, Linux, Snap, and other release jobs, but those commands are platform packaging and may publish artifacts. The personal-build guide tells fork owners to invoke electron-builder with a platform config and --publish never. Our lab correctly avoided treating a release script as an ordinary source build.
Windows offers three packages, while AppImageLauncher needs version 3.0
Windows users get 3 main downloads: an administrator-only machine installer, a per-user MSI, and a portable executable without file associations. A Microsoft Store package is another per-user route. Native ARM64 installer and portable builds support Windows 11 on Arm; version 31.4.5 enables auto-update there after older ARM64 releases shipped with it disabled. Existing ARM64 users must install the newer build manually once.
Linux has deb, rpm, and AppImage choices. Since version 31.4.2, the AppImage uses a static runtime and no longer needs the obsolete libfuse2. That change breaks AppImageLauncher 2.2.0, whose last stable release cannot load the static runtime. The README tells users to install a 3.0 beta build of AppImageLauncher or remove the launcher, which is unnecessary for running the AppImage directly.
Node 22.12 forks are unsigned, and upstream contributions are closed
Source work requires Node.js 22.12 or later, npm, and the editor submodule. npm start launches the app without packaging, provided another draw.io instance is not already running. The single-instance behavior can fool a developer by opening a window in the official app instead of the modified copy. Packaging adds platform-specific steps, including disabling auto-update so an official release does not overwrite the customized build.
Official binaries use private Apple and Microsoft signing infrastructure that a fork cannot access. Personal packages require an explicit unsigned-build setting, and macOS Gatekeeper or Windows SmartScreen may warn or block them. The maintainers also close the upstream code path: bug reports and feature requests are welcome, but outside code contributions are refused except in rare cases. Apache-2.0 permits a fork; maintenance and distribution remain the fork owner's responsibility.
Three open issues sit beside a same-day 31.4.5 release
GitHub showed 63,000 stars, 3 open issues, and a last push on September 8, 2026. Release 31.4.5 arrived later that same day. The 5 most recent releases span August 21 through September 8, so release activity is current. The small open count is especially notable for a desktop application used across 3 operating systems, though a closed contribution policy also limits how work enters the repository.
One of those 3 issues identifies a concrete version 31.4.5 fault: file watching registers nothing when no window is focused and can send events to the wrong window when several are open. Another asks the maintainers to research mass deployment because current guidance for MDM, silent installation, policy locking, and controlled updates is thin. draw.io Desktop is a dependable personal diagram editor by the evidence we saw. Company rollout and background file workflows deserve their own acceptance checks.