drawio-desktop: the offline Electron build of draw.io, and how to install it

What drawio-desktop is, and who it is for

drawio-desktop is a diagramming application built on Electron that wraps the core draw.io editor. The repository describes it as the official Electron build, and the package name in package.json is simply "draw.io" with the description "draw.io desktop". It is aimed at people who want the draw.io editing surface without a browser: flowcharts, UML, network diagrams and the rest of the shape libraries that the web editor exposes.

The licensing question comes up first for most teams, and the README answers it plainly: the app is available under Apache 2.0, and if you do not change the code and accept it as provided "as-is", you can use it for any purpose. That is a permissive position, but it is paired with a support posture that is worth reading before you standardise on it. Support is offered on a reasonable business constraints basis, without anything contractually binding, and only through the repository. The README also states that buying draw.io for Confluence or Jira does not entitle you to commercial support for the desktop app. If your organisation needs an SLA, this is not the product that supplies one.

The second audience is the offline one. The app is designed to be isolated from the Internet apart from its update process, which checks github.com at startup for a newer version and downloads it from an AWS S3 bucket owned by Github. No diagram data is sent externally, and no analytics about app usage are sent externally. For engineers working on air-gapped or restricted machines, that design intent is the reason to pick this build over the web editor.

How the Electron wrapper and the update check actually work

The architecture is a thin shell around a large web application. The repository keeps the draw.io editor as a git submodule in the drawio directory, and the package entry point is src/main/electron.js, with a preload.js at the top level. The main process is JavaScript running under Electron, and the renderer is the draw.io web editor itself.

That split explains the security claims. The README states that all JavaScript files are self-contained and that the Content Security Policy forbids running remotely loaded JavaScript, restricting the application's own network connections to itself. The consequence is that the app cannot transmit your diagrams or otherwise phone home. There is one documented exception, and it is worth internalising: a diagram can reference external media, such as an image, a background or a font loaded from a URL embedded in the diagram. Those are fetched when the diagram is opened so that it renders correctly. Opening a diagram from an untrusted source may therefore trigger a request to the referenced URL, which can reveal metadata such as your IP address to that server. No diagram content is transmitted, but the request itself is observable.

The update mechanism is the only other outbound path, and it is controllable. Setting the DRAWIO_DISABLE_UPDATE environment variable to true, or passing --disable-update on launch, disables the update check entirely. The README frames this as the option for centrally-managed installs, which is the honest framing: if you push the app through configuration management, you probably also want to control when it updates.

Local data lands in the platform application data directories. On macOS that is ~/Library/Application Support/draw.io, and on Windows it is C:\Users\<USER-NAME>\AppData\Roaming\draw.io\. Local Storage and Session Storage live there, which matters for backup and for migration between machines.

Installing drawio-desktop on Windows, macOS and Linux

Built binaries are published on the releases page, and the README does not ask you to build from source for normal use. The Windows section is the most detailed because the three Windows flavours differ in a way that decides whether you can install at all.

The NSIS installer installs per-machine into Program Files and requires administrator privileges. The MSI installs per-user into the user's profile and does not require administrator privileges, which is the one to use if you lack admin rights. The portable build runs without any installation and therefore without admin rights, but file-type associations are not registered. The Microsoft Store build is also installable per-user without admin rights.

The README names the three Windows artefacts directly, so match the filename to your privileges before downloading:

draw.io-<version>-windows-installer.exe
draw.io-<version>.msi
draw.io-<version>-windows-no-installer.exe

The first is the NSIS installer, the second the per-user MSI, and the third the portable build. If you are on a locked-down machine, skip the first.

If you want to run the app from source, the editor is a submodule, so a plain clone is not enough. The README gives this example:

git clone --recursive https://github.com/jgraph/drawio-desktop.git

Then, in the root directory of the repository, install dependencies and start the app. The README lists the steps in this order, and notes that DRAWIO_ENV=dev is for internal use only when developing or debugging in dev mode.

npm install
npm start

For debugging, the README gives npm start --enable-logging. The package.json declares an engines constraint of node >=22.12.0, so an older Node will not satisfy the project. If you use a symlink to the drawio repository instead of the submodule, the README warns that you must also symlink the node_modules directory inside drawio/src/main/webapp.

On Linux, the repository ships electron-builder-linux-mac.json and electron-builder-snap.json, and the release scripts cover release-linux and release-snap. The README does not walk through Linux installation steps, so consult the releases page for the artefact that matches your distribution.

A first real use is unremarkable by design: open the app, create a diagram, and save it as a .drawio file on local disk. The point of the exercise is that no network request is needed for that workflow.

Where drawio-desktop is the wrong tool

The most concrete limitation is contributions. The README has a section titled "Not open-contribution" and states that draw.io is closed to contributions unless a maintainer permits it, which it calls extremely rare. The stated reason is that the project's complexity means even simple changes can break many other moving parts, and that the amount of testing required is far more than it first seems. Bug reports and feature requests are welcome; patches are not. If your team's adoption criteria include the ability to patch a bug locally and upstream it, this project fails that test by policy rather than by accident.

The second limitation is the external media fetch described above. An app marketed on isolation still makes outbound requests when a diagram references a remote image, background or font. That is a rendering requirement, not a leak, but it means "offline" is a property of the app's own behaviour, not a guarantee about the files you open. Treat diagrams from untrusted sources the way you would treat any document with embedded remote references.

The third is support. Reasonable business constraints, no contract, no private ticketing for non-paying users, and no carry-over from a Confluence or Jira purchase. A team that needs a named contact when a release breaks will not find one here.

Finally, the update path is a network connection by design. If your environment forbids it, you must disable it explicitly and then own the upgrade cadence yourself.

drawio-desktop versus the web editor and versus building your own fork

The obvious alternative is the draw.io web editor at diagrams.net, which the homepage points to. The difference is not the editing surface, since the desktop app wraps the same core editor. The difference is where the code runs and what the network boundary looks like. In the browser, the page is served over the network and the app's isolation guarantees are the browser's, not the desktop wrapper's. In the desktop build, the Content Security Policy restricts the application's own connections to itself, and the only documented outbound paths are the update check and any external media referenced by a diagram. For a machine that should not reach the internet at all, that is a materially different starting point.

The second alternative is forking. The README points to doc/BUILDING_FOR_PERSONAL_USE.md for making your own changes and building an unsigned app for personal use. That is the sanctioned path for local modification, and it is explicitly scoped to personal use. It is not a route to upstreaming, and an unsigned build carries its own distribution problems.

The third is the Microsoft Store build, which the README lists alongside the installers. It installs per-user without admin rights, which makes it the least friction option on managed Windows machines where the Store is permitted. It is not a different product, just a different delivery channel, and the README does not describe any functional divergence between it and the direct downloads.

Maintenance, release cadence and licence implications

The repository is not archived, and the last push was on 2026-08-22, which is recent enough that the project is being maintained. The release history supports that: v31.3.2 on 2026-08-22, v31.3.1 on 2026-08-21, and v31.1.8 on 2026-08-07. Three releases in a month is a fast cadence, and it is worth planning for. If you disable the update check for a managed fleet, you are choosing to track that cadence manually, and the gap between v31.1.8 and v31.3.2 shows how quickly the version numbers move.

Upgrade cost is mostly operational rather than technical. The app is a packaged binary, so upgrades are installer replacements, not dependency bumps in your own code. The wrinkle is the version skew between the package.json version (31.4.5) and the most recent published release (v31.3.2). The development branch can be ahead of what has shipped, which is normal for this kind of project but means you should read release notes rather than assume the repository state equals the downloadable artefact.

On licensing, the README states Apache 2.0 and adds a plain-language gloss: if you do not change the code and accept it as provided "as-is", you can use it for any purpose. Apache 2.0 is a permissive licence with a patent grant, and redistribution and modification are generally allowed under its terms. This is not legal advice, and the interaction between the Apache 2.0 grant and any bundled third-party components is something your own review would need to establish. What the README does make clear is the boundary of the free grant: it is conditioned on not changing the code and on accepting the as-is provision. Forking and redistributing is a different situation, and doc/BUILDING_FOR_PERSONAL_USE.md scopes its guidance to personal use.

One more operational detail: the repository ships a sync.cjs script and an npm run sync entry in package.json. The README's release process implies that script is how the submodule state is kept in step. If you build from source, that script is part of the workflow you inherit.

Editorial conclusion

Adopt drawio-desktop if you need to author diagrams on a machine that should not talk to external services, or if you want the draw.io editor without a browser tab. Do not adopt it if you need to contribute patches (the README states the project is closed to contributions) or if you need collaborative editing, which the desktop app does not provide. Before rolling it out, verify which Windows flavour matches your privileges: the NSIS installer requires administrator rights, the MSI and the portable build do not. Then confirm your update policy by launching once with --disable-update and checking that the app still starts and opens a local .drawio file.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes