Offline Visio alternative for air-gapped networks: what the constraint requires
For a team diagramming inside a closed network, the main offline options are draw.io Desktop and the self-hosted draw.io Docker image. Both run without any outbound connection, and the Docker image is built from the same production app that runs at app.diagrams.net. The constraint itself is simple to state but has three parts: no outbound data, so diagrams and their metadata never leave the enclosure; no cloud dependency, so the editor, fonts, icon libraries and any export function must work from inside the network; and controlled file transfer, so the only way content crosses the boundary is through a defined, logged process. Each part changes what you must test before go-live, not just which tool you pick.
Start by listing the diagram sources that must enter the network, such as .vsdx files, .vssx stencils and Lucidchart exports, and confirm each one imports cleanly on the target build. Then confirm the Docker image runs with no route to the internet, that PDF export uses the browser print path because the image has no export server, and that no feature in your rollout calls a hosted service. Ask your security team how files will be scanned and approved before they move across the boundary, since the content of icon sets and templates carries separate terms from the Apache-licensed source. Visio LTSC 2024 and Visio Plan 2 are the commercial comparison: LTSC 2024 is a one-time desktop purchase, and Plan 2 is a subscription that depends on Microsoft's service. Confirm with your Microsoft representative how each handles activation and updates in a disconnected environment.
Which requirements an air-gapped diagramming tool must meet
The requirements below are general starting points, not a complete list. Your own security policy, accreditation boundary and data classification set the final list, so treat each card as a question to answer before you pick a tool. Together they cover where diagram data can go, how the app runs without a network, how existing files enter the boundary, and how software crosses the gap.
No diagram data leaving the environment
The self-hosted draw.io Docker image has no export server, so PDF export falls back to the browser's print dialog unless you configure one. That means a diagram's contents are not sent to a third-party service for conversion. draw.io's privacy policy says diagrams are saved where the user chooses, on the device or in a connected storage service, and never on draw.io's servers. Confirm this against the version you deploy, and test outbound traffic from a workstation while you export, save and share a sample diagram.
Offline operation of the application
Confirm that the editor loads, saves and exports with no route to the internet. Check whether fonts, icon libraries, templates and any scripts are served from your own server or fetched from external hosts at runtime. Also check the image's behavior at startup and when a user opens a diagram that links to an external resource. Document the result as a repeatable test, because a later upgrade can change which assets are loaded.
Controlled import of Visio and Lucidchart files
Visio files arriving from outside the boundary need a defined path. draw.io imports .vsdx directly, converts .vsd and .vst in the browser, and imports Gliffy and Lucidchart diagrams, but it does not import Visio 2003 to 2010 XML or LibreOffice Draw files. Its documentation also warns that imports can lose interactive behavior and do not bring in embedded EMF images. Decide which file types are allowed, who reviews them, and how imported content is checked before it is shared.
Verified software packages across the boundary
NERC CIP-013-2 asks utilities to set supply chain procurement processes that address verification of software integrity and authenticity for vendor software and patches. The same discipline applies to a diagramming tool carried across an isolated network. Record the source repository, release tag and checksum for the draw.io image or desktop build, verify them on the transfer side, and keep the signed record with the change ticket. Whether this control applies to you depends on your regulator and asset classification, so confirm that with compliance.
Upgrade and patch path without internet access
draw.io releases frequently, and its project does not accept outside pull requests, so your team depends on the maintainers' release cadence and your own intake process. Decide who monitors releases, how a new image is imported, and how you test it before it replaces the current one. Ask whether the vendor's release notes and Docker image can be obtained through your approved transfer method, and plan a rollback in case an upgrade changes import or export behavior.
Licensing that fits restricted networks
Confirm the license terms of each component you bring inside. draw.io's source code is Apache License 2.0, but its icon sets, stencil libraries and templates have separate terms, so review those before importing custom libraries. Many commercial alternatives keep air-gapped deployment behind paid editions, so ask vendors in writing which edition includes offline use and what support covers it. Keep the license record with the software inventory.
Where Visio LTSC and Plan 2 fit a closed network
Visio LTSC 2024 is the one-time-purchase desktop edition, and it follows Microsoft's Fixed Lifecycle Policy with mainstream support listed until October 2029, according to Microsoft's lifecycle pages for the product. That date gives a fixed horizon for a desktop purchase, but it does not settle the question for a closed network. Teams still on Visio 2019 should note that its extended end date passed in October 2025, so any machine running that version is already past vendor support. Before choosing between LTSC 2024 and a subscription, confirm the support window with Microsoft or your reseller and record it in the diagramming standard for the enclave.
The licensing decision turns on how the software is activated and updated on machines with no internet path. Ask Microsoft or your reseller how license activation works on isolated devices, whether a volume or offline activation method is available for your agreement, and how security and feature updates are delivered into a network that cannot reach Microsoft's update services. Ask whether updates arrive as media that must be imported through your change process, and who in your organization is responsible for verifying each package before it crosses the boundary. Visio Plan 2 is a subscription, so ask separately whether it can run on isolated machines at all, how often it must check in, and what happens to installed copies when a subscription lapses.
Because the commercial terms affect a closed network in ways that list prices do not show, request the activation, update and renewal mechanics in writing before you buy, and test them on one isolated workstation first. Record the answers alongside the lifecycle dates so that the audit file shows why the desktop version was chosen. If the answers show that updates or activation will be difficult to maintain, the draw.io Docker image and draw.io Desktop give a path that does not depend on a license server, which the rest of this page covers in detail.
Which open-source options meet the offline constraint
This table compares draw.io Desktop, the self-hosted draw.io Docker image and whiteboard options against the offline constraint, with the features to verify before adoption. Read each row as a check against your own network rules, and treat the trade-offs as the items to test in a pilot before standardizing.
| Option | How it meets the offline constraint | Features to check and trade-offs |
|---|---|---|
| draw.io Desktop | Runs as a local application, so diagrams can be saved to the device or an approved internal share with no hosted service in the loop | Confirm how your installer and updates are approved and carried across the boundary. Visio import differences, lost interactivity and missing embedded EMF images still apply |
| Self-hosted draw.io Docker image | Serves the editor from your own server built on Tomcat, kept current with the production app, so browsers inside the network reach only internal hosts | No export server is included, so PDF export uses the browser print dialog. Confirm the image update path and who patches the server |
| PDF export without an export server | The browser print dialog produces output locally, and no diagram data leaves the server for the export | Check page breaks, fonts and scaling on large diagrams. Test whether Visio-derived shapes print as expected before relying on it for formal records |
| Visio file import (.vsdx, .vsd, .vst) | Imports Visio files and converts older .vsd and .vst files in the browser, so conversion does not require an external service | Import differences may change appearance and interactive behavior. Embedded EMF images are not imported, so plan manual rebuilding of those diagrams |
| Excalidraw for whiteboard work | Open-source MIT-licensed whiteboard that can be hosted internally, with end-to-end encrypted collaboration | Confirm how the collaboration server is deployed and that no external relay is configured. It suits sketching more than formal engineering diagrams |
| Nextcloud Whiteboard for whiteboard work | Official Nextcloud app built on Excalidraw and licensed AGPL-3.0, so boards live in the Nextcloud instance on your servers | Requires a running Nextcloud deployment. Confirm the Nextcloud and Whiteboard versions your team will support and who applies updates |
| License and contribution model | draw.io source is Apache License 2.0, so the code can be reviewed, retained and built internally | The project does not accept pull requests, so fixes you need must be carried in your own fork or a support arrangement. Confirm this fits your change process |
How to deploy draw.io offline in a closed network
This sequence takes draw.io from a vetted release package to a working offline editor in a closed network, with the storage, export and update decisions made before users start diagramming.
Verify the source and chosen release
Confirm the draw.io source code is licensed under the Apache License 2.0 and that the maintainers do not accept pull requests, so any changes you make are your own to maintain. Pick the release you will carry across the boundary. The v32.4.1 release was published on October 8, 2026, and the GitHub releases page lists the versions that followed it. Record the version, the checksum and the date in your change log. Done when a named engineer has signed off on the chosen version and the verification record is stored with your build inventory.
Transfer and load the image into an internal registry
Obtain the official jgraph/drawio Docker image, scan it with your approved tooling, and move it across the boundary through your existing media transfer process. Push it to your internal container registry under a pinned tag rather than a floating one, so every host runs the same build. The image is based on Tomcat and is kept in step with the production app at app.diagrams.net. Confirm the transfer procedure with your security team, since NERC CIP-013-2 is the control that expects software integrity and authenticity checks for packages carried across an isolated boundary if you operate under that regime. Done when the image pulls successfully from the internal registry on a test host.
Run the Docker image on an internal host
Start the container on an internal host that no outside network can reach, and place it behind your existing internal TLS termination and access controls. Confirm that the container can be reached only from the user network segment you intend. The official deployment guidance describes running the image on your own server. Because the image has no export server, no diagram data is sent out of the container during export. Check the container's network egress rules to make sure the host cannot reach external services by accident. Done when a test user can open, edit and save a diagram from an internal browser with outbound traffic blocked.
Deploy draw.io Desktop installers to workstations
For users who need local editing, package the draw.io Desktop installers for your workstation operating systems and distribute them through your software deployment tool. Keep the installers in your internal software repository so no workstation fetches anything from the internet. Confirm the installers are the same release as the server image, so that file formats and shape libraries behave the same way for everyone. Test installation on one device of each operating system you support. Done when a standard user can install the application without network access and open a diagram stored on a local drive.
Configure storage for saved diagrams
Decide where diagrams live before anyone creates them. draw.io saves files on the device or in a connected storage service that you choose, so in a closed network this is usually a file share or an internal document system you already operate. Set permissions on that location to match the classification of the diagrams. Confirm with the owners of your storage platform that backups and retention apply to diagram files, and test a restore of one file. Note that real-time collaboration and some hosted features depend on external services, so check each feature you plan to use against your no-egress requirement. Done when a saved diagram appears in the correct share with the expected access controls.
Decide how PDF export is handled
The jgraph/drawio Docker image does not include an export server. Without one configured, PDF export uses the browser's print dialog, which keeps the diagram on the user's machine. If you want a server-side export path, confirm with the draw.io documentation whether you can configure one inside your network and what that adds to your image and support scope. Write the decision into your user guidance so users know which export route is approved and which formats are allowed for classified or controlled diagrams. Done when a test user produces an approved PDF through the chosen route and the procedure is documented.
Import and check existing Visio files
Copy a representative set of .vsdx, .vsd and .vssx or .vss files into a test folder and import them into the offline editor. The draw.io import documentation says .vsdx files import, .vsd and .vst files are converted in the browser, and stencils import as shape libraries. It also notes that Visio 2003 to 2010 XML and LibreOffice Draw files are not supported. Compare each imported diagram with the original, because the vendor warns that rendering may differ, interactive behavior may be lost and embedded EMF images are not imported. Record each result in a checklist and assign a remediation owner for any diagram that needs rebuilding. Done when the checklist is signed off for every diagram family you depend on.
Document the update procedure for future releases
Write a repeatable procedure for each new release: verify the source and version, transfer the image, push it to the internal registry, roll the container to the new tag, and update the workstation installers. Include a rollback step that keeps the previous image tag available. Name an owner who watches the GitHub releases page and triggers the procedure. Confirm your change-control process fits these steps, and store the procedure with your air-gapped operations runbook. Done when the procedure has been run once end to end on a test host and the runbook is approved by your operations lead.
Importing Visio and Lucidchart files without internet access
draw.io imports `.vsdx` files directly, and it converts .vsd and .vst files in the browser, so a closed network needs no conversion service to bring over a Visio drawing. .vssx and .vss stencils load as shape libraries, which keeps custom shapes available for reuse. Gliffy diagrams and Lucidchart diagrams also come in. The gaps matter just as much: draw.io does not import Visio 2003 to 2010 XML or LibreOffice Draw files. Before you plan a migration, inventory your file types and confirm that every format in the archive falls on the supported side of that line. Files in unsupported formats need a resave in a newer Visio version first, or a different route.
Lucidchart diagrams move by copying the whole canvas in Lucidchart with the keyboard shortcut and pasting it into the draw.io online editor. That step is the one place where the browser needs a route to the internet, so plan it on a connected workstation, then move the resulting files into the closed network through your approved transfer process. The draw.io documentation warns that imports may look different from the original and may lose interactive behavior, and that embedded EMF images are not imported. Treat every imported diagram as a draft until someone has compared it to the source.
Run a sample-based test before any bulk migration. Pick a representative set that includes your most complex diagrams, stencils, links between pages and any drawings with embedded images, then compare each one side by side with the original in Visio or Lucidchart. Record which shapes, connectors, layers and data fields survive. Use the results to decide whether a diagram needs manual rebuilding, a stored PDF or PNG copy kept alongside the native file, or a note in the register that it no longer carries its interactive content. Repeat the sample after any draw.io upgrade, since import behavior is not frozen.
Questions teams ask before deploying offline diagramming
What does it cost to run draw.io inside an air-gapped network?
The draw.io license cost is zero because the source code is Apache License 2.0, but the work around it is not free. The cost components are hosting the self-hosted Docker image on hardware or a VM you control, moving the image and any updates across the boundary, converting existing Visio and Lucidchart files, training users, and maintaining an export server if you want PDF export with embedded diagrams. Hosting and staff time recur as upgrades arrive, while planning, file conversion and first-time verification are largely one-time. Costs rise with the number of files to convert, the number of sites, and how strict your change control is. Ask any partner for a quote that lists each component separately and states which are one-time and which recur.
How long does an air-gapped draw.io deployment take?
No fixed duration applies because it depends on your network approvals, your internal registry, the size of your diagram library and how many users need access. The main variables are how quickly your security team approves the image transfer, whether a private registry already exists, and how much existing Visio content needs conversion and checking. Ask for a written scope that names each phase, its deliverables and its dependencies on your side, and agree the timeline in that document before work starts. Most DeployOpen engagements are fixed-scope, so the timeline is set in writing rather than estimated in a sales call.
What must our team provide before an offline draw.io rollout?
Your team typically provides the target infrastructure, the network change approvals for moving software into the closed environment, and an internal container registry or approved file share to hold the image. You also need storage for diagrams, either a shared network location or the local device storage that draw.io uses when you choose where to save. Name a sponsor who can approve transfers, a reviewer for the image verification steps, and users who will test converted diagrams. Confirm these responsibilities in the written scope so that delays on either side are visible early.
Can our own engineers deploy draw.io without a partner?
Yes, a capable platform team can deploy the self-hosted Docker image or the desktop app without outside help, since the project publishes deployment documentation and the software is open source. The harder parts are usually not the install itself but verifying every artifact before it crosses the boundary, keeping pace with releases, converting legacy Visio files and documenting the controls for an assessment. If your team lacks capacity or prior experience in those areas, a fixed-scope engagement can cover them. Compare the internal effort with a written scope before deciding.
How do we verify software that crosses an isolated boundary?
Verify each package, image and rule set against the source you trust before it enters the network, and record the result. This is the control area NERC CIP-013-2 addresses for vendor software and patches, and it applies in other regulated environments as well. Keep a log of what was downloaded, from where, its checksums or signatures, who approved it and when it was imported. Ask your partner to show how they handle this step and where those records are kept, because auditors will ask for them. Confirm the specific requirements that apply to your own compliance scope with your auditor.
What do we lose by using draw.io instead of Visio in a closed network?
The main losses are fidelity and some Visio-specific behavior, not the ability to draw offline. draw.io warns that Visio imports may look different from the originals, may lose interactive behavior and do not import embedded EMF images. It also does not import Visio 2003 to 2010 XML or LibreOffice Draw files. Test a representative sample of your most important diagrams after conversion and decide which ones need to be rebuilt by hand. Plan this review as part of the file conversion work instead of assuming every diagram will carry over unchanged.
What evidence should we request from a partner before signing?
Ask for a written scope with deliverables, a list of responsibilities on each side, and a description of the verification and change records they will produce. Request a sample of the documentation they would hand over, such as the deployment runbook, the image verification log and the backup and upgrade procedure. Ask how they handle draw.io upgrades given that the project does not accept pull requests and publishes frequent releases. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications, so ask which independent body would assess your environment.
Evidence assessors expect for an offline diagramming tool
An assessor reviewing a closed network wants proof that diagram data cannot leave the boundary and that every file crossing into it was checked. The six items below connect the architecture, the transfer process, the storage settings and the people who use the tool. DeployOpen prepares this evidence for your review, while independent auditors or certification bodies are the ones who issue any attestation.
Deployment architecture with no outbound path
Document which hosts run draw.io, which networks they sit on and which firewall rules block outbound traffic from them. The official Docker image has no export server, so PDF export falls back to the browser print dialog and no diagram data is sent out for export. Ask the team to show that the browser can load the editor from the internal host alone, and capture the firewall configuration as it stood at the time of testing.
Package and image verification before transfer
Every container image, desktop installer and library carried across the isolated boundary needs a record of where it came from, its version and the checksum or signature verified before import. Keep these records with the transfer log so an assessor can trace each artifact. Confirm with your own change process which verification steps your organization requires, since the source checks differ between the Docker image and the desktop app.
Storage location and privacy statement
Record where diagrams are saved, whether on a local device or a file share inside the network, and retain the vendor privacy statement that describes this behavior. The draw.io privacy statement says diagrams are saved where the user chooses and not on draw.io servers, but connected cloud storage and hosted features are separate settings. Confirm that no integration pointing to an external service is enabled in your configuration.
Access control and user list
Maintain a current list of users who can open the editor, with their roles and approval dates, and show how access is granted and removed. Because draw.io is a browser editor on your own host, access depends on the network and any authentication layer you place in front of it. Confirm with your identity team how sign-in is enforced and whether removed staff lose access on the same schedule as other internal tools.
Change records for updates
Track each upgrade with the release version, the date it was staged, the person who approved it and the test result. draw.io publishes frequent releases, so the change log should show which version runs in production at any point. Record the rollback path too, since an assessor will ask how a faulty update would be reversed inside the closed network.
Record of Visio import tests
Keep a dated test log of representative .vsdx, .vssx and Gliffy or Lucidchart files, with the result for each: shape rendering, lost interactivity and any embedded EMF images that did not import. The vendor notes that imports may differ from the original and may lose interactive behavior, so the test record shows what your teams can and cannot rely on after migration. Include the sample set, the tester and the fixes agreed for each failure.
When Visio LTSC or Plan 2 is still the right choice
Keep Visio LTSC 2024 or Visio Plan 2 where a closed network still depends on something draw.io does not reproduce exactly. The most likely cases are specialized engineering or process stencils that a team has built up over years, diagrams with embedded EMF images, and contracts or accreditation packages that name a specific Visio file format or require a specific rendering. The draw.io documentation warns that Visio imports may look different from the original, may lose interactive behavior and do not import embedded EMF images, so these are the items that need checking before any decision is made. Stencils are often the largest risk because a .vss or .vssx file imports as a shape library, but the shapes may not carry the same connection points or data fields.
Run a short test on a representative sample rather than on the whole archive. Pick diagrams that exercise each risk: one with embedded EMF content, one with custom stencils, one with data-linked shapes or macros, and one that a regulator or customer has reviewed. Open each in the draw.io build that will run on the isolated network, compare it with the original in Visio, and record every difference in a simple register with the file name, the defect and whether it blocks use. Confirm the file format requirements with the party that wrote them, because a contract clause that names .vsdx may accept a PDF export once the source is preserved. Do not assume that a successful import means the diagram is accepted.
Plan a hybrid period when the test shows gaps. Keep Visio installed on a small set of machines, freeze the files that cannot move, and move active diagrams to draw.io first so new work does not add to the backlog. The license decision follows the timeline: Visio LTSC 2024 is listed for mainstream support until October 2029 under Microsoft's Fixed Lifecycle Policy, so a one-time purchase covers the period the team needs for transition, while Visio 2019 has already reached its extended end date. Ask any integrator or licensing partner for the cost of both paths in writing, and confirm the air-gapped installation and activation steps against the current Microsoft documentation for your agreement type before you rely on them.
How DeployOpen deploys draw.io under an air-gapped constraint
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own networks, including air-gapped ones. For offline diagramming, that means building the draw.io image, desktop installs and file handling so that diagram data never depends on an outside service.
How we scope
- Inventory which teams diagram inside the closed network and which Visio files, stencils and templates they rely on.
- Confirm whether draw.io Desktop, the self-hosted Docker image or both fit each team's workflow and host platform.
- Agree in writing which PDF export path applies, since the Docker image has no export server and uses the browser print dialog.
How we build
- Prepare the container image and desktop installers on a connected staging system, then transfer them through the approved boundary process.
- Verify each imported package and image against the checksums and approval records your supply chain procedure requires.
- Convert representative .vsdx, .vsd and stencil files, then check rendering, interactivity and embedded EMF images against the originals.
How we hand over
- Deliver the written configuration, deployment runbook and the offline update procedure for future draw.io releases.
- Document where diagrams are stored, which storage connectors are enabled and how access is controlled on the network.
- Provide a file migration checklist and a short user guide covering offline saving, sharing and stencil library setup.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Upgrades can be tested on a staging copy of the air-gapped environment before the production image is replaced.
- Ask any provider, including DeployOpen, to confirm in writing how updates, backups and access reviews will be performed.
