Gliffy Zero Egress vs self-hosted draw.io for regulated teams

Why regulated teams look at Gliffy Zero Egress and self-hosted draw.io

A regulated team whose diagrams show architecture, network segments or data flows needs to know where that detail sits at all times. Zero Egress keeps Gliffy content inside Atlassian Cloud, while self-hosted draw.io keeps diagram data on infrastructure the organization controls. Both can address a data location requirement, but they draw the boundary in different places, so the decision starts with defining that boundary.

Write the boundary down before comparing products. If the rule is that diagram content stays within the Atlassian Cloud tenant, Zero Egress is the option to examine, and you should confirm in writing which data it covers and how Atlassian processes it. If the rule is that diagram data stays on servers or desktops your team runs, draw.io fits that boundary. Its draw.io trust page says diagrams are saved where the user chooses, on the device or a connected storage service, and never on draw.io's servers. Teams that use hosted features such as hosted export or real-time collaboration should note that these pass diagrams through servers run by Cloudflare temporarily.

This page sets out where each option keeps diagram data, which data paths you need to map, and what assessors typically ask about storage, backup and export. It does not decide the outcome for you. Before choosing, confirm the scope of Zero Egress with Atlassian and map your applicable obligations with your assessor or compliance lead, so the chosen design matches the boundary you actually have to defend.

What a data residency or no-egress requirement actually asks for

A residency or no-egress rule usually turns on a small set of questions: where diagram content sits, which third parties touch it, how files leave the boundary, and how changes are recorded. Each card below is a point where Gliffy Zero Egress and self-hosted draw.io differ in architecture, so each is a point to verify against your own policy before you decide.

Where diagram content is stored

Ask whether the diagram data itself, not just the wiki page that embeds it, stays in a location you choose. draw.io's privacy statement says diagrams are saved where the user chooses, on the device or in a connected storage service, and never on draw.io's servers. For a self-hosted draw.io deployment, the storage target is your own file system or storage service, so auditors will ask for the storage location, its access controls and its backups.

Which processors touch content

A residency rule covers every processor that handles diagram data, not only the primary store. The draw.io trust page states that hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare. Teams that disable those features on a self-hosted instance remove that processor from the data path, so the question for each deployment is which features are switched on and which third parties each one reaches.

How exports leave the boundary

Exports are a common gap in no-egress designs. The jgraph/drawio Docker image does not include an export server, so PDF export uses the browser print dialog unless you configure an export server, and no diagram data leaves the server for an export. Confirm which export paths your users can reach, whether the browser print dialog or a local printer or PDF driver sends data elsewhere, and whether the export format keeps embedded content you must control.

How changes are traced

Auditors often ask who changed a diagram, when, and whether the prior version can be recovered. Gliffy and draw.io keep this history in different places: Atlassian Cloud controls it for Gliffy inside Confluence, while a self-hosted draw.io deployment depends on the wiki, repository or storage service that holds the files. Ask for the audit log, version retention and restore procedure for whichever system stores the diagram, and confirm they meet your records policy.

Software and image provenance

A self-hosted draw.io deployment adds components you must source and verify: the Docker image, the Tomcat base, and any export or storage integrations. Checking software integrity and authenticity before a package crosses into a controlled environment is the kind of supply chain control NERC CIP-013-2 addresses for vendor software. Record which image version you pulled, how you verified it, and who approves updates, since the project publishes frequent releases.

Who holds access and approvals

Residency rules also depend on who can see, copy or share diagrams. Gliffy access follows the Confluence and Jira permissions in Atlassian Cloud, while a self-hosted draw.io deployment follows the controls of its host wiki, file share or identity provider. Document which groups can view, edit and export diagrams, how external collaborators are handled, and how access is reviewed on a schedule.

Where diagram data goes in each setup

Gliffy Zero Egress is the Gliffy option positioned for teams that want diagram data kept inside their Atlassian environment. Diagrams are stored with the Confluence or Jira content they belong to, so the storage location follows the Atlassian Cloud tenant and the region that tenant is hosted in. Because only general facts are available here, the exact data flows must come from the vendors, not from this page.

Storage: Ask Atlassian and Perforce where diagram definitions, previews and attachments are stored, and whether any copy exists outside the tenant.
Transient processing: Ask which services render, export or index diagrams, and whether any of them run outside the Atlassian Cloud region.
Subprocessors: Request the current subprocessor list for both Atlassian and Perforce, and the dates on which it last changed.
Egress boundary: Confirm in writing what "zero egress" covers, including exports, links, add-ons and support access.
Control evidence: Ask which configuration settings, logs and contract terms show the claim, and which of them an auditor can sample.

Before relying on this setup, get the data flow in writing from both vendors and check it against your own data classification policy.

Which open-source options meet a no-egress constraint, and at what trade-off

This table compares self-hosted draw.io, Excalidraw, Nextcloud Whiteboard and Penpot on where diagram data sits, their licenses and the trade-offs a regulated team must accept. Read each row against your own no-egress rule, then confirm the open items with the project or your own testing before you commit.

Option	Where diagram data stays	License	Trade-offs to plan for
Self-hosted draw.io (Docker image)	On your own server, using the official jgraph/drawio image. Diagrams save where the user chooses, and the image has no export server, so PDF export uses the browser print dialog.	Apache License 2.0 for the source code, with icon sets and templates under separate terms	No pull requests are accepted, so fixes come from the core team. Confirm how you will track releases and test updates.
Self-hosted draw.io (Desktop)	On the user's device or a storage location you control. Nothing needs a hosted service for basic editing.	Apache License 2.0 for the source code, with icon sets and templates under separate terms	Desktop installs must be managed and patched on each machine. Confirm your software deployment and update process.
Excalidraw (self-hosted)	On your own server. Collaboration sessions use end-to-end encryption, so the hosting party cannot read board content.	MIT	Built for freeform whiteboard sketches, not formal architecture diagrams. Confirm its fit for the diagram types your auditors review.
Nextcloud Whiteboard	Inside your Nextcloud instance, so boards are stored with your other files under your access controls.	AGPL-3.0	Depends on a Nextcloud deployment. Confirm the Excalidraw-based feature set and the AGPL obligations for any modified version.
Penpot (interface design)	On your own servers, so design files and their history remain in your environment.	Mozilla Public License 2.0	Aimed at interface design and prototyping, not general diagramming. Use it for design files, and keep draw.io for diagrams.
Visio imports into draw.io	Imported files are processed in the editor you run, so the source files never need to leave your network.	Covered by draw.io's Apache License 2.0	Visio imports may look different, may lose interactive behavior and do not bring in embedded EMF images. Check each migrated diagram.

How to deploy self-hosted draw.io under a residency constraint

This sequence takes draw.io from a scoped boundary decision to a running, verified, self-hosted instance whose diagram data stays on infrastructure the organization controls.

Confirm the boundary and data classes
The security or compliance lead and the diagram owners agree which networks, storage locations and user groups are in scope, and which diagram classes (architecture, network topology, process maps, OT or safety-related diagrams) may be stored and where. Record the decision in the system description so each later step can be checked against it. Done means a signed scope note that names the hosting location, the storage targets and the people allowed to change them. Ask your auditor which evidence they expect for this boundary before the build starts, because it shapes what you log later.
Build or pull the image into an internal registry
The platform team pulls the official jgraph/drawio Docker image, which is based on Tomcat and kept current with the production app, then copies it into the organization's internal container registry. Pin the image to a specific tag and record its digest rather than running a floating tag. Where the team prefers to build from source, it should document the exact repository revision used, since the project does not accept outside pull requests. Done means the registry holds the pinned image and a record of its digest, and the production hosts pull only from that registry.
Configure storage to an approved location
Because draw.io saves diagrams where the user chooses, the decision is about the storage target: local device, an on-premises file store, or a connected system such as Nextcloud or a file share inside the boundary. Set up that target in the approved location, restrict access by group, and confirm that no default cloud storage connector is enabled for users in scope. Test with a sample diagram created by a user in scope and confirm the file lands only in the approved target. Done means a test file is found in the approved location and nowhere else.
Decide how exports will be handled
The Docker image does not include an export server, so PDF export uses the browser's print dialog unless you configure one. Choose between the print dialog, which keeps processing in the user's browser, and a self-hosted export server inside the boundary, which the team must install, patch and monitor. Document the choice, because it determines what logs exist and who maintains the component. Done means a written export decision and, if an export server is used, a test export that completes without any outbound request to an external host.
Connect integrations inside the boundary
Enable only the integrations the scope note allows, such as Nextcloud, GitLab, XWiki or your existing wiki, and point each one at internal endpoints. Disable any integration that reaches a public service the data class does not permit. Check each connector's credentials, which should be service accounts with the smallest rights needed. Confirm the outcome by opening a diagram from each connected system and verifying that its traffic stays on internal addresses. Done means a short test record per integration showing the endpoint used and the account that connected.
Carry packages across an isolated boundary
On disconnected networks, the image, its base layers, the wiki or storage connector packages and any export server components must be transferred by approved media or a one-way transfer process. Before each import, verify the artifacts against published checksums or signatures, and record who approved the transfer and when. This control maps to the supply chain expectation in NERC CIP-013-2 for verifying software integrity and authenticity, and comparable expectations appear in other frameworks. Done means each transferred artifact has a logged checksum match and an approval record before it is loaded into the internal registry.
Set an update routine that tracks upstream
Assign an owner to watch the jgraph/drawio release line and schedule a review of each new version, pinning the tested tag and rebuilding the internal image after validation in a test environment. Keep a changelog that links each deployed version to its approval and to the verification record from the transfer. Because the project publishes frequent releases, decide in advance how quickly security-relevant versions move to production. Done means a documented routine, a named owner, and a dated record of the current production version and its verification.
Test, record and hand over evidence
Run a final test that covers user sign-in, diagram creation, storage location, export path and each integration, then compare the results against the scope note. Collect the configuration, registry records, transfer approvals, access lists and test results into one evidence folder for the assessor. DeployOpen can prepare these records as part of an implementation, but independent auditors decide whether they satisfy a given requirement. Done means a signed test report that matches the scope note and an evidence index that an assessor can follow.

What changes for editors, admins and the security team

The first change editors notice is where diagrams live. With Gliffy Zero Egress, diagrams stay inside the Atlassian tenant but are still edited through Confluence and Jira, so the save, version and share habits people already have carry over. With self-hosted draw.io, a diagram is saved where the user chooses, such as a file on a laptop or a connected storage service, and the wiki only embeds or links it. Editors should be told that sharing becomes a deliberate choice of storage location, and that the team must agree on one shared location for diagrams that several people maintain. Confirm in your own environment whether your wiki or file store offers version history for the diagram files you choose, because draw.io itself does not keep a server-side history.

For admins, the practical question is what happens to existing Gliffy content. Gliffy macros on Confluence pages are tied to the Gliffy app, so before any change, inventory the pages that contain them and export the source diagrams. Converted diagrams should be reviewed by the owners of the most important pages, since import can change layout and styling. On the access side, permissions that Atlassian enforces today through space and page restrictions must be rebuilt in the organization's identity provider and the storage location's permission model. Plan group mapping, offboarding and the removal of stale shares as explicit tasks, and confirm how your identity provider integrates with the storage service and wiki you select. Support also changes. Gliffy support runs through Atlassian, while draw.io support comes from the team that runs your self-hosted instance or from a support contract you agree in writing.

The security team should treat the move as a change in the data path. Under Zero Egress, the audit question is whether Atlassian's controls and region commitments cover diagram data, which your Atlassian contract and documentation will answer. Under self-hosted draw.io, the questions shift to the container image, the host, the storage backend and any export or collaboration features you enable, because those determine where data is processed. Confirm which draw.io features are enabled in your deployment, record the image version you run and your patch process, and document the storage and backup location for diagram files. Expect auditors to ask who can read, change and delete diagrams, how that is logged and how it is reviewed. Those answers are evidence your team produces, not something a tool supplies on its own.

What auditors ask for when diagrams hold sensitive architecture

Diagrams of production architecture often reveal network layouts, system names and trust boundaries, so they fall inside the scope of an assessment. The cards below cover the evidence an assessor will usually request for either Gliffy Zero Egress or a self-hosted draw.io deployment, and what your team should be ready to show.

Data flow of the tool itself

Auditors want a diagram of where diagram data travels: the browser, your web server, your storage and any export or collaboration path. For self-hosted draw.io, the official Docker image does not include an export server, so PDF export runs through the browser print dialog and no diagram data leaves your server for an export. For Gliffy Zero Egress, document where Atlassian processes and stores the data. Check each hop against your own boundary and record the result.

Storage location and access records

Assessors ask where each diagram file is saved, who can open it and how access is granted and removed. draw.io's privacy policy says diagrams are saved where the user chooses, on the device or a connected storage service, and never on draw.io's servers. Keep a register of storage targets, the groups with read and write rights, and the logs that show access. Confirm the same for any Confluence or Jira space that holds diagrams.

Processors and sub-processors list

A documented list of every party that processes diagram data is a standard request. For draw.io, the privacy policy states that hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare, so that path must appear in your register if you use those features. For Gliffy, ask Atlassian for its current sub-processor documentation and the data residency options that apply to your plan. Record the date you checked each list.

Change and patch log for the self-hosted image

When you run draw.io yourself, the assessor will expect a record of which image version is deployed, when it changed and who approved the change. The jgraph/drawio project publishes releases frequently, and its Docker image tracks the production app, so the log should capture each pull and redeploy. Store the image digest alongside the version tag. For Gliffy Zero Egress, the equivalent evidence sits with Atlassian and your Confluence change records.

Supplier and software integrity checks

Where software crosses into an isolated boundary, NERC CIP-013-2 expects procurement processes that verify the integrity and authenticity of vendor software and patches. For draw.io, this means checking the image signature or digest, confirming the source of the repository and recording how each package was validated before it entered the network. Draw.io's source is Apache License 2.0 and the project does not accept pull requests, so your review should focus on the artifacts you deploy, not on contributing changes upstream.

Retention and backup procedures

Auditors will ask how long diagram versions are kept, how they are backed up and how a restore is tested. Self-hosted draw.io stores files where you point it, so backup scope follows your storage target, whether that is a file share, a wiki attachment store or a local drive. Gliffy diagrams sit inside Confluence backups. Document the retention period, the restore test date and the owner of each control. NIST SP 800-82 Rev. 3 offers useful context when diagrams describe operational technology.

Questions regulated teams ask before choosing Zero Egress or self-hosted draw.io

Does Gliffy Zero Egress meet our data residency requirement?

Only Atlassian and your own auditor can confirm that, so get the answer in writing before you rely on it. Ask Atlassian which data stays in the region you choose, and which parts sit outside it, including diagram content, comments, file metadata, search indexes, logs and any AI features. Ask which subprocessors touch the data and whether that statement can be cited in a contract schedule. Then give those answers to the people who own the obligation, because the requirement comes from your regulator, contract or internal policy. If your rule covers network layouts or system names, check that it also covers exports and attachments.

What does self-hosting draw.io cost, component by component?

The core draw.io application has no per-user license fee, because its source code is licensed under the Apache License 2.0, but self-hosting still carries recurring costs. The main components are a server or container host, storage and backups, staff time to deploy, patch and monitor the Docker image, identity and network integration, and outside support if you buy it. Icon sets, stencil libraries and templates have separate terms, so review those too. Staff time is often the largest line for an internal team, and it recurs with every upgrade. Ask any provider for a quote that lists each component, who is paid for it, which items are one-time, which recur, and what sets the hours for upgrades and incidents. Include the cost of any Confluence or wiki app, since those are sold through the Atlassian Marketplace.

How long does a draw.io migration take, and what drives the time?

Duration depends on scope, so ask for a timeline tied to a written plan instead of a generic figure. The biggest drivers are the number of diagrams, how old they are, and how many of them depend on features that do not convert cleanly, such as Visio files with interactive behavior or embedded EMF images. The amount of checking after conversion matters as much as the conversion itself. Other drivers include whether Confluence or your wiki is also moving, how many people need training, how long your change approvals take for a new server, and how much identity integration you require before go-live. A sample migration of a few representative diagrams is a practical way to measure the effort before you commit to a full scope.

What must our team provide for a self-hosted draw.io deployment?

Your team supplies the decisions and access that an outside provider cannot make alone. The essentials are:

A named owner who is accountable for the service, its upgrades and its incidents
Network access from user networks to the host, plus the certificate and DNS records for it
Identity integration with your single sign-on provider, if access must be restricted to staff
A decision on where diagrams are stored, whether on the server, on a file share or in a connected storage service
Backup and restore targets, tested on a schedule your change policy allows
Change windows for upgrades, and approval for the software and image you deploy

Can our own engineers run self-hosted draw.io without an outside provider?

Yes, if one or two people can own it over the long term. The official jgraph/drawio Docker image is based on Tomcat and is kept up to date with the production app, so the first deployment is mostly a container and configuration task. Ongoing work is patching, watching release notes, testing upgrades and handling access changes. The project does not accept pull requests, so your team cannot contribute fixes upstream and must plan around the maintainers' release schedule. Confirm internally that you can staff an on-call rota for the service. Many teams start with their own staff and buy an outside retainer for upgrades and testing, while fixed-scope work covers the initial setup. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and quotes follow from a written scope.

Does draw.io Desktop remove the need for a server?

For diagram storage, yes. draw.io Desktop runs on the user's device, and the draw.io privacy statement says diagrams are saved where the user chooses, on the device or in a connected storage service, and never on draw.io's servers. Shared review, embedding in a wiki and central control usually need a server or a connected storage service, so confirm which workflows your teams depend on. Desktop installs also need software approval, update control and endpoint management, which a server would otherwise cover centrally. Check that the Desktop version and update channel meet your change policy before you roll it out to managed devices.

How do Visio and Gliffy diagrams import into draw.io?

Visio .vsdx files and Gliffy diagrams import into draw.io, and .vsd and .vst files are converted in the browser. Visio .vssx and .vss stencils import as shape libraries. Lucidchart diagrams move by copying everything in Lucidchart and pasting into the draw.io online editor. The import does not cover Visio 2003 to 2010 XML or LibreOffice Draw files. Expect differences: draw.io warns that Visio imports may look different from the original, may lose interactive behavior and do not import embedded EMF images. Keep the original files, convert a representative sample first, and have diagram owners sign off on each converted set before you retire the source.

Do diagrams leave our environment when self-hosted draw.io exports or collaborates?

For a self-hosted deployment, no diagram data leaves your server for an export, because the Docker image does not include an export server. PDF export uses the browser's print dialog unless you configure an export server, so confirm where any export server you add would run. The hosted app at app.diagrams.net is different. The draw.io trust and privacy page says hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare. Auditors will likely ask for a data flow diagram that shows which of these paths your users can reach, so document each one and block the hosted app if your policy requires it.

When Zero Egress is enough and when self-hosting is the better fit

Stay with Gliffy Zero Egress when the constraint your auditors care about is already met by controls Atlassian operates, and your team runs Confluence in Atlassian Cloud without a requirement to hold diagram data inside a boundary you control. In that case, the cost of migrating diagrams, retraining authors and rebuilding templates may outweigh the residency gain the existing contract already provides. Before you decide, ask Perforce and Atlassian in writing which data Zero Egress keeps out of Atlassian's processing path, which subprocessors touch diagram content, where it is stored, how retention and deletion work, and whether rendering, export or preview thumbnails leave your tenant. Record those answers in your risk register before the renewal date.

Move to self-hosted draw.io when the boundary has to sit in your own infrastructure, when diagrams must be edited offline or on an air-gapped network, or when licensing and vendor lock-in carry weight in the decision. The jgraph/drawio Docker image runs on Tomcat and tracks the production app, so you host the editor on your own server and choose where diagram files are stored. The image includes no export server, so PDF export uses the browser print dialog and no diagram data leaves your server for an export. The source is Apache 2.0, but the project does not accept pull requests, so fixes and features depend on upstream releases. You become responsible for tracking releases, testing upgrades and patching your deployment, which is ongoing work for an internal team or a retainer.

Whichever path you choose, the audit question is the same: where diagram content goes, who can reach it and what evidence shows it. The hosted app at app.diagrams.net is a different case from your own image. draw.io's trust page says diagrams are saved where the user chooses and never on its servers, but hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare, so a self-hosted deployment should block that path at the network layer and document the decision. Ask Atlassian and Perforce for the equivalent data flow for Zero Egress, and ask your auditor which evidence they will accept, such as configuration exports, access logs and network policy records. DeployOpen can prepare these controls and evidence, but independent auditors issue the assessment outcome.

How DeployOpen deploys draw.io inside your boundary

DeployOpen plans and implements self-hosted draw.io inside your own cloud accounts, data centers or air-gapped networks, so diagram data stays where your controls already apply. Each engagement starts from a written scope that names the storage, hosting and access decisions your auditors will ask about.

How we scope

We confirm which teams, diagram types and storage locations the written scope covers before any work starts.
We record where diagrams will be saved, whether on devices, file shares or a connected storage service you control.
Engagements are fixed-scope, with deliverables and timelines agreed in writing, and ongoing support available as a retainer.

How we build

We deploy the official jgraph/drawio Docker image or draw.io Desktop inside your own infrastructure, as your architecture requires.
We configure integrations with your wiki or storage, and decide how PDF export works without sending diagram data out.
We test imports of existing Gliffy, Visio and Lucidchart files and document where converted diagrams need manual review.

How we hand over

We deliver architecture, data flow and configuration documentation that shows every location where diagram data is stored or processed.
We document the upgrade and patch process for draw.io, including how new releases are validated before rollout.
We prepare the control evidence your internal team or independent auditor needs to review, without issuing any audit opinion ourselves.

How we support

Ongoing support covers upgrades, backups and configuration changes to the self-hosted draw.io environment.
Continuous security testing of the hosting platform is available as a retainer, scoped to your environment.
We confirm with you, in writing, which responsibilities sit with your team and which sit with DeployOpen during each phase.