Can a self-hosted Figma alternative run in an air-gapped network?
Yes. Penpot can be self-hosted entirely inside a closed network, which makes it the open-source option for a design team that cannot use cloud tools. Penpot documents self-hosting with Docker Compose and an official Helm chart, so the deployment can be built from images and charts that your team mirrors into its own registry and artifact store before the network is closed. Penpot's application runs with PostgreSQL, which it requires in version 13 or later, uses Valkey for websocket notification coordination, and stores uploaded objects on the filesystem or in S3-compatible storage such as MinIO. Each of these components has to be present inside the boundary, and each needs its own images, packages and update path.
Figma's cloud model does not solve this problem on its own. Its data residency option is available only on the Enterprise plan, and the Figma help center notes that comments, file names, plugins, fonts and preview thumbnails are not hosted in the chosen region. A design team with a no-internet rule therefore still depends on a vendor-operated service that runs outside its boundary. Other design and diagramming tools in this group follow a similar pattern, where offline or regional options sit on higher plans. Confirm with your vendor, in writing, exactly what a closed-network deployment of any commercial tool would require before you rely on it.
This page covers running and updating Penpot without internet access: the Docker Compose and Helm inputs to collect, PostgreSQL and object storage sizing decisions, login through LDAP or generic OpenID Connect, and how new Penpot releases are brought across the boundary and verified. It does not compare licensing costs. Ask your team to inventory the container images, chart versions and database and storage dependencies for the release you select, and to test the full install and one upgrade on a staging network that matches your isolation model before production.
What an air-gapped design environment must provide
A closed network removes the vendor cloud from the design workflow, so every service, image and login path has to sit inside the boundary. The cards below cover the four requirements that follow from that constraint and the Penpot dependencies that each one touches.
No calls to a vendor cloud
Penpot's cloud plans run on Penpot's servers, so an air-gapped team uses a self-hosted instance with no dependency on an external service at run time. Check every feature your designers rely on, including fonts, plugins and integrations, and confirm whether each one fetches resources from the internet or works from local copies. Test the instance with outbound traffic blocked before pilot users arrive.
Every image inside the boundary
Penpot documents self-hosting with Docker Compose and an official Helm chart, so the deployment path decides which images must be mirrored. Build a list of all containers and their tags, pull them on a connected staging host, and move them into an internal registry. Ask your platform team whether the chosen runtime, such as OpenShift or Rancher, needs additional base images.
Accounts from the internal directory
Self-hosted Penpot supports email and password login by default, but an air-gapped organization usually needs LDAP or generic OpenID Connect so accounts follow the directory that already governs the network. Confirm how group membership maps to Penpot roles, how deprovisioning works when someone leaves, and whether the identity provider is reachable from inside the boundary. Test sign-in with a leaver account before go-live.
Three stateful dependencies to host
Penpot supports only PostgreSQL, recommending version 13 or later, uses Valkey for websocket notification coordination, and stores uploaded objects on the filesystem or in S3-compatible storage such as MinIO. Each of these needs its own backup, patching and capacity plan inside the boundary. Ask whether the storage backend has replication and whether restores have been tested against design files, not only database dumps.
Controlled transfer of software and updates
Every package, image and release carried across the boundary is software that must be verified before use. Penpot publishes tagged releases on its GitHub releases page, so record which version you approved, check its integrity against the publisher's artifacts, and keep an internal copy of the approved set. Plan updates as scheduled transfer batches, and confirm with your security team how the transfer process is documented and audited.
Where Figma's hosting options stop short of a closed network
Figma's data residency option is the first thing a closed-network team should check, and it does not settle the question on its own. According to Figma's help center, data residency through localized file hosting is available only on the Enterprise plan, and comments, file names, plugins, fonts and preview thumbnails are not hosted in the chosen region. For an air-gapped design team, that means some design metadata and supporting assets would still sit outside the boundary the region was meant to enforce, and the region setting alone does not describe where all design data lives. Read the localized file hosting article before you assume a regional option covers your requirement.
The local copy option does not give a closed network an offline archive either. Figma documents local copies as .fig, .jam and .deck files, and states that these files carry no version history or comments. Figma also describes these formats as proprietary and subject to change, so an export made today may not be readable by a different tool later. Teams planning a long-retention archive or a move to self-hosted software should test a sample export, confirm what it contains, and decide how comments and history will be kept. The guide to saving local copies explains what each copy includes.
Before you plan around Figma, confirm with Figma directly whether it offers a deployment or hosting arrangement that works for a closed network with no outbound connectivity, and get the answer in writing with the plan, the scope and the file types covered. Ask which data stays in-region, how plugins and fonts are handled, and what happens to licensing and updates inside a disconnected environment. Those answers determine whether a self-hosted design platform is a replacement or a parallel system, and they set the export and cutover work your team needs to budget for.
Which open-source options fit a closed design network
Penpot is the only option on this page that covers interface design, the work Figma does for product teams. It is licensed under the Mozilla Public License 2.0 and runs from Docker Compose or the official Helm chart, so an internal team can deploy it on hosts with no route to the internet once images and packages are staged. Its dependencies are PostgreSQL, version 13 or later, Valkey for websocket notifications, and file storage on a filesystem or an S3-compatible store such as MinIO. Sign-in can use local accounts, generic OpenID Connect or LDAP.
- Offline deployment: Build an inventory of every container image in your chosen Penpot release and mirror it to an internal registry before the network is closed.
- Design file coverage: Test representative Figma files and confirm which components, variants, auto layout and text survive the export.
- Exporter limits: The penpot-exporter-figma-plugin produces a .zip for import, and it does not support prototyping settings, so those flows must be rebuilt by hand.
- Identity: OpenID Connect or LDAP connects Penpot to the directory already inside the closed network.
- Data location: Files, comments and accounts stay on the hosts you run, with no vendor cloud in the path.
Ask your design leads which prototyping flows must be rebuilt before you set a cutover date.
draw.io covers architecture diagrams, network maps and process flows, which many teams currently produce in Visio or Lucidchart. Its source code is licensed under the Apache License 2.0. draw.io's privacy policy states that diagrams are saved where the user chooses, on the device or a connected storage service, and never on draw.io's servers. That storage model suits a closed network, because editing and saving can happen without any outbound connection.
- License terms: Apache 2.0 allows internal use and modification without a per-seat fee, so your costs come from packaging and support.
- Storage choice: Shared diagrams need a location you control, such as an internal file share or a connected storage service. Confirm which one your team will use.
- Import fidelity: draw.io imports .vsdx, .vsd and .vst files, Visio stencils, Gliffy diagrams and Lucidchart diagrams. Test these on representative files, because shape-level fidelity varies.
- Maintenance trade-off: The maintainers do not accept pull requests, so any change you need becomes a fork that your team carries and must update.
- Installation: Confirm whether your security team approves the desktop installer or requires a hosted build inside the network.
Check how your approved software store packages draw.io before the migration plan assumes it will be available on every workstation.
Excalidraw is a collaborative whiteboard licensed under the MIT License, the most permissive license among the options on this page. Its collaboration is end-to-end encrypted, which is designed to keep board content unreadable to the server that relays sessions. It suits workshops, sketches and flow outlines. It is not an interface design tool: it has no component libraries, design tokens or prototyping, so interface work belongs in Penpot.
- License terms: The MIT License permits internal use and modification, so licensing costs do not recur.
- Encryption: End-to-end encryption limits what the server operator can read, but confirm the key handling and what metadata the server still sees in the project documentation.
- Hosting the collaboration service: Live sessions depend on a sync service, so confirm how it is deployed and updated inside the closed network.
- Scope: Use it for boards and sketches, and keep component-based interface design in Penpot.
- Export: Confirm which formats boards export to, so they can be archived outside the tool.
Decide whether boards live on a standalone deployment or inside Nextcloud, because storage, backup and access control differ between the two.
Nextcloud Whiteboard is the official whiteboard app for Nextcloud. It is built on Excalidraw and licensed under the AGPL-3.0. If your organization already runs Nextcloud inside the closed network, boards sit beside files and use the same accounts for access. Like Excalidraw, it is a board tool and does not replace Penpot for interface design.
- License terms: The AGPL-3.0 requires that modified versions offered to users over a network make their source available, so have legal review any internal changes before deployment.
- Storage: Boards are stored in the Nextcloud file system, so backup, retention and restore follow the Nextcloud environment.
- Dependency: You need a working Nextcloud deployment first, which brings its own database, storage and update cycle.
- Access: Sharing and permissions reuse Nextcloud users and groups. Confirm how LDAP or OpenID Connect is configured in your Nextcloud setup.
- Offline updates: Confirm how updates for Nextcloud and the whiteboard app are packaged and approved for an isolated network.
Ask your Nextcloud administrators whether the app version you need already passes your change process.
How to deploy Penpot offline with Docker Compose or Helm
This sequence takes a Penpot instance from release media to a running, sign-in-ready deployment inside a closed network, with every image, chart and dependency staged beforehand and checked for outbound calls.
Size hosts and confirm dependencies
The platform or infrastructure team lists the internal hosts or cluster nodes, then confirms the PostgreSQL version and the storage option that will hold uploaded objects. Penpot supports only PostgreSQL, and the Penpot technical guide recommends version 13 or later. Storage can be a local filesystem or an S3-compatible store such as MinIO, and Valkey handles websocket notification coordination. Write the chosen versions and storage backend into the deployment record. The step is done when every dependency has a named owner and a version that matches the Penpot documentation you are deploying from.
Mirror images and the Helm chart
On a connected staging host, the team pulls the Penpot container images for the release tag under test, along with Valkey, PostgreSQL and object storage images, and downloads the official Penpot Helm chart if Kubernetes is the target. Images are saved as archives, scanned and checked against the publisher's release notes, then transferred on approved media to the isolated network and pushed to an internal registry. Test one tag from the Penpot GitHub releases page first, and record the digest of each image. Confirm that the staged set starts cleanly on a test host before it crosses the boundary.
Prepare an offline Kubernetes cluster if needed
If the target is Kubernetes, the cluster platform team builds it without internet access. Kubernetes documents that kubeadm config images list and kubeadm config images pull fetch the control plane images in advance, and the --image-repository flag on kubeadm init points the cluster at the private registry. The team mirrors the network plugin and any add-on images the same way. The step is done when all nodes join and report ready with no pulls leaving the network. Skip this step when Penpot runs under Docker Compose on an existing host.
Deploy Penpot with Compose or Helm
The engineer deploys Penpot using either the Docker Compose file or the official Helm chart, pointing every image reference at the internal registry instead of public hosts. Set the public URL to the internal hostname users will type into a browser, and keep secrets in the environment or a secret store rather than in the compose file. The step is done when all services report healthy and the login page loads from an internal browser. Confirm the exact configuration keys against the Penpot configuration guide for the version in use.
Connect PostgreSQL, Valkey and object storage
The engineer points Penpot at the internal PostgreSQL instance, the Valkey service and the chosen storage backend, then creates the database and confirms credentials and TLS settings with the database owner. For S3-compatible storage, the bucket and access keys are created on the internal store and tested with a small upload before Penpot relies on it. The step is done when a test file can be created, saved, reloaded and its uploaded assets appear in the storage backend. Record backup targets for the database and the object store at the same time.
Wire LDAP or OpenID Connect sign-in
The identity team connects Penpot to the internal directory. Penpot supports LDAP and generic OpenID Connect for single sign-on, alongside email and password login by default. Choose one primary method, set the bind account and search base for LDAP or the issuer, client ID and redirect URI for OIDC, and confirm the identity provider is reachable from inside the network. Disable or restrict local password accounts according to your access policy. The step is done when a test user from the directory signs in, and a user outside the permitted group is refused.
Verify there are no outbound calls
The security team confirms that the running instance makes no connections beyond the internal network. They review firewall logs and egress rules, run a traffic capture during a full design session including file export and import, and check that no Penpot service attempts to reach public endpoints for fonts, updates or telemetry. Any failed connection attempt is traced to its configuration key and fixed. The step is done when the capture and firewall logs show only internal traffic, and the result is filed as evidence with the deployment record.
Set up offline updates from new media
The operations team establishes a repeatable update path. For each new release, the team repeats the staging, scanning and transfer steps on newer release media, reviews the release notes for database migrations and configuration changes, and takes a database and object store backup before applying the update. Confirm the update process with your own change control and test it on a non-production copy first. The step is done when a second release tag has been applied on the test instance, the rollback path has been exercised, and the update record names the tag, the image digests and the approver.
How to update Penpot without internet access
Updating a closed Penpot instance is a controlled import, not a pull. Someone outside the boundary has to watch the upstream release history, pick a target version, and carry every artifact across by approved media. The Penpot GitHub releases page is the place to start, and the recent history shows how quickly the project ships: 2.18.3 followed 2.18.2 and 2.18.1 within days in October 2026. Frequent point releases mean the team should set a review cadence it can sustain, rather than chasing every tag. Before each cycle, record the currently running version, the container image tags, and the Helm chart version, so the rollback target is known in advance.
Each candidate release should be validated in a staging enclave that mirrors production: the same PostgreSQL major version, the same Valkey and object storage configuration, and the same login method, whether that is LDAP or OpenID Connect. Restore a recent backup of the production database into staging, run the upgrade, and test real design workflows such as opening large files, editing shared libraries, commenting and exporting. Only then move the verified container images and chart archives across the boundary, and record a hash or signature for every package. Verifying software integrity on the way in is the same kind of control that NERC CIP-013-2 expects of vendor software and patches, so it is a useful model even if your organization is not in the energy sector.
Database migrations are the riskiest step because they change data in place. Take a fresh backup immediately before the upgrade, keep the previous image available offline, and agree on who decides to roll back and within what window. Confirm in the release notes whether a given version requires a specific migration order, whether any change is irreversible, and whether a rolling update is supported for your deployment method. The Penpot technical guide's configuration reference and the release notes are the authoritative sources for these steps, so confirm them against the exact version you plan to install before scheduling a window.
Evidence assessors ask for when a design tool sits in a closed network
Assessors rarely accept a claim that a design tool is isolated. They want documents, test results and records that show where data can flow, how users sign in, what is running and how updates reached the network. The cards below cover the evidence that connects the Penpot deployment to those questions. DeployOpen prepares this evidence for your own assessment, but independent auditors and certification bodies issue any audit report, attestation or certification.
Architecture diagram with trust boundaries
Draw the Penpot frontend, backend, PostgreSQL, Valkey, object storage and the login provider as separate components, then mark every boundary where data crosses from one zone to another. Show which connections are internal only and which, if any, reach a directory or a mail relay. Assessors will compare this diagram against the network scans and firewall rules, so each arrow should match a rule you can point to. Confirm the current component list with the Penpot technical guide before you draw it.
Network egress test results
Record tests run from inside the Penpot network segment that show outbound connections fail to public destinations, including package registries and image sources. Keep the test commands, timestamps, source hosts and results together so the evidence can be repeated. Test DNS resolution as well, since a blocked route with open resolution still leaks names. Repeat the tests after each update, because a new release can add an outbound call that your earlier tests did not cover.
Login and session configuration
Export the active settings for the chosen login method, whether LDAP or generic OpenID Connect, and show the session and password rules applied to users. Assessors usually ask who can create accounts, how sessions end and where credentials are checked. Keep the configuration files under version control with the reviewer's approval recorded against each change. Confirm the supported login options in the Penpot technical guide before you finalize the settings.
Inventory of images and versions
List every container image, Helm chart version and database and Valkey version in the deployment, with the digest that was actually pulled. This list tells the assessor what is running, and it becomes the baseline for every later update. Compare the inventory with the release notes for the version you run, so known fixes and changes are visible. Store the inventory alongside the architecture diagram so both describe the same system.
Records of transferred update packages
Each update that crosses the boundary needs a record that names the package, its source, its checksum or signature, the person who approved the transfer and the date it entered the network. Verify integrity on the inside before installing, and keep the verification output. This is the evidence that matches the supply chain control in NERC CIP-013-2 for software integrity and authenticity, so it should also appear in your procurement file. Confirm the verification method each vendor publishes for its artifacts.
Backup and restore tests
Keep records of backups for the PostgreSQL database and the object storage that holds uploaded files, and of at least one restore into a separate environment. A backup that has never been restored is weak evidence, so record how long the restore took, which files were checked afterward and who signed off. Restore tests also show that the backup set contains the schema and file references needed for Penpot to start. Repeat the test after each major version change.
What do buyers ask before running Penpot offline?
What does an air-gapped Penpot deployment cost, and which costs recur?
The software itself carries no license fee, since Penpot is licensed under the Mozilla Public License 2.0. The cost sits in the components around it: hosting for the application, PostgreSQL, Valkey and object storage, plus staff time for setup, identity integration and each update cycle. Setup costs are one-time, while hosting, storage growth, patch handling and staff time recur. Ask for a written scope that lists each component, who builds it, who runs it, and what happens at each update. Penpot's cloud plans are not part of this cost, because an offline deployment runs on your own servers.
How long does an offline Penpot deployment take?
No researched duration is available for this deployment, so confirm the timeline in writing before work starts. The schedule depends on how many environments you need, whether you use Docker Compose or the official Helm chart, how your private registry and artifact transfer work, and how many identity providers you connect. Ask the implementation partner to list each phase, the dependencies it needs from your team, and the acceptance tests for each one.
What must our team provide before the work begins?
Plan for infrastructure, access and people. You need a host or cluster inside the closed network, a private container registry, PostgreSQL 13 or later, a Valkey instance, and storage for uploaded objects on the filesystem or in an S3-compatible service such as MinIO. You also need an LDAP directory or an OpenID Connect provider, a process for moving verified packages across the boundary, and named staff who can approve changes. Ask the partner to confirm each of these in the scope.
Can our internal staff run Penpot offline without outside help?
Yes, if you have people who can operate Docker Compose or Kubernetes, PostgreSQL, Valkey, object storage and your identity provider. Penpot's documentation covers Docker Compose and an official Helm chart, so the technical path is documented. The harder part is the offline update cycle: each release must be obtained outside the network, checked for integrity, moved across the boundary and tested before rollout. Ask whether your team can staff that cycle every release, or whether a retainer for upgrades and support fits better.
How do we migrate Figma files, and what does the exporter plugin miss?
Export from Figma with the penpot-exporter-figma-plugin, which is maintained by Kaleidos under MPL-2.0 and produces a .zip file that Penpot can import. The plugin does not support prototyping settings, so those must be rebuilt by hand. Test large files in a staging copy first, then compare components, variants, auto layout, libraries and text against the source. Your scope should name the files in the first wave, the acceptance checks and who signs off on fidelity.
Does Penpot's paid cloud plan matter for an offline deployment?
For a closed network, the cloud plans do not change the cost of running Penpot on your own servers. Penpot's pricing page lists Professional, Unlimited, Enterprise and a Private Server tier, and those prices cover Penpot-hosted service. Before you decide on any paid option, confirm with Penpot which features, support terms and update channels apply to self-hosted installs, since the self-hosted software is available under the MPL-2.0 license.
What should we ask for in a written scope for offline Penpot?
Ask for a written list of components, versions and the target environment, a migration plan for libraries and files, the identity integration method and the acceptance tests. Also request the update procedure for a closed network, including how packages are verified for integrity and authenticity before they cross the boundary. Ask who keeps the backups, who responds to incidents, and what support continues after handover. Fixed-scope engagements agree these items in writing before work starts.
How do we verify packages before they enter an isolated network?
Set a written process for every package that crosses the boundary, including container images, the Helm chart and any migration tools. Record the source, check the published integrity information, and keep a log of who approved each transfer. This supports supply chain expectations that regulators apply in some sectors, such as the software integrity and authenticity controls in NERC CIP-013-2. Confirm with your compliance lead which frameworks apply to your environment.
Where to check the Penpot self-hosting details
Check the version and offline steps against Penpot's own documentation before you build anything inside a closed network. Penpot's technical guide has a getting started page covering the Docker Compose and Helm deployment paths, and a configuration page listing the environment settings for PostgreSQL, Valkey, object storage, and LDAP or OpenID Connect login. Read both against the exact release you intend to deploy, not against the version you tested last year. The Penpot technical guide, getting started is the starting point for the Compose files and chart values, and the Penpot technical guide, configuration is where you confirm the keys your identity provider and storage backend need.
Track releases on the Penpot GitHub releases page, because the release notes are where breaking changes, database migration steps and image tag changes appear. Confirm three things for your target version: which PostgreSQL major versions it supports, whether the Valkey and object storage settings changed since your last upgrade, and whether any container images or chart dependencies must be mirrored into your internal registry. Ask your team to record the exact image digests and chart version you approved, so an offline update later moves from one known state to another. Note that the guide does not replace testing in your own environment, so run a staging restore from backup before the first production update.
Treat the documentation as a list of questions for your own environment. Confirm with your security team how the approved release bundle is transferred across the boundary and verified, and confirm with your identity team that the chosen login method works with your directory and certificates before users depend on it. If any step in the guide assumes internet access, such as fetching fonts, plugins or images at startup, record it as a gap and resolve it before go-live. Where the guide is silent, ask the Penpot project or your implementation partner rather than assuming the behavior.
How DeployOpen deploys Penpot under an air-gapped constraint
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including closed networks. For an air-gapped Penpot deployment, the work starts with which container images, chart versions, database and storage components, and login systems can cross the boundary, and it ends with a documented procedure the design team can repeat.
How we scope
- Written scope lists the Penpot version, deployment target and which login method, LDAP or OpenID Connect, applies
- Scope records the PostgreSQL, Valkey and object storage components that must run inside the closed network
- Scope defines how design libraries, existing files and user accounts will be migrated and verified
How we build
- We prepare an offline image and chart bundle, with checksums recorded for each artifact carried across the boundary
- We deploy with Docker Compose or the Helm chart, configure PostgreSQL, Valkey and storage, and connect the chosen login system
- We run security testing against the instance and document the findings and fixes before handover
How we hand over
- Deliverables include architecture notes, configuration records, backup and restore runbooks and access procedures
- We document the offline update workflow so administrators can apply new Penpot releases from vetted media
- Evidence for compliance readiness is packaged for your assessors, who issue any audit reports or certifications
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover reviewing each new Penpot release before it is carried into the closed network
- Support scope is agreed in writing, so response expectations and service levels are stated before work begins
