Can Penpot replace Figma Dev Mode for developer handoff?
Developers who work from Figma Dev Mode pay for Dev seats as a recurring line item, and the design specs they inspect live in a proprietary cloud. Penpot covers most handoff needs on self-hosted infrastructure: inspecting designs, producing code-oriented output based on SVG, CSS and HTML, working with native design tokens, and reaching files through an open API. Whether each of those needs is met in your own workflow is a question to settle with a proof of concept, not a checklist ticked from a feature page. Confirm with Penpot's documentation which handoff views, code snippets and export options your developers rely on today, and test them against your real component libraries.
Penpot is licensed under the Mozilla Public License 2.0 and is an open-source project of Kaleidos. The MPL-2.0 license lets you run, modify and host the software in your own environment, and it is the license to check with your legal team when you plan any changes to the code. Because Penpot is maintained by a single organization that also offers a hosted service, plan for the governance question as well: who funds upgrades, who triages security fixes, and what your internal team must own if you run it yourselves.
This section covers developer handoff only, not the full design tool. Decide early which Figma features your handoff depends on, such as prototyping links, comment threads that engineers reply to, or spec annotations, and map each one to a Penpot equivalent or a documented workaround before you commit. Record every gap in writing so that the migration plan and any stakeholder sign-off reflect what handoff will and will not do after the switch.
Which Dev Mode capabilities map to Penpot and which need a workaround
This table maps each Figma Dev Mode capability to the closest Penpot option and notes where coverage is partial or missing. Read the coverage column first, since it shows which items need a test on your own design files before you commit. The main takeaway is that Penpot covers the core handoff of properties, assets, tokens and CSS, while code-generation plugins, Figma-specific annotations and prototyping specs need confirmation or a workaround.
| Dev Mode capability | Penpot option | Coverage notes |
|---|---|---|
| Inspecting properties | Inspect panel on design files | Confirm that sizes, spacing, fills and typography read correctly for your components in a test file. |
| Exporting assets | Export of frames, shapes and components | Check export formats and naming conventions against what your build pipeline expects. |
| CSS and code snippets | CSS and HTML output based on open standards | Generated snippets may differ from Figma's output, so review them against your codebase before reuse. |
| Design tokens | Native design tokens | Confirm that your token sets map to your build tooling, since token formats vary by team. |
| Component specs | Components, variants and libraries | Components, variants and auto layout are expected to convert; verify each one after import with the Figma exporter. |
| Comments and review | Comments in Penpot | Figma comments do not migrate with the exporter, so record open review items before moving files. |
| Version history | Penpot file history | Figma version history does not come across in a file export, so keep a record of past versions you need. |
| Prototyping specs | No direct equivalent | Prototyping settings do not convert with the Figma exporter, so rebuild them or document them separately. |
| Code-generation plugins and Figma-specific annotations | Plugin system to confirm | Not covered by supplied facts; test each plugin and annotation against your own file before relying on it. |
Options for developer handoff on self-hosted infrastructure
Penpot covers developer handoff through its own inspect and export path, its design tokens and its open API, but it does not copy Dev Mode feature for feature. The options below separate what Penpot provides directly from what your team must build, configure or keep in a separate tool. Check each one against your own handoff workflow before you commit.
Built-in inspect and export
Penpot works with open standards such as SVG, CSS, HTML and JSON, so developers can take values and assets straight from the design file without a separate handoff server. This suits teams that want designers and engineers to work in one tool on a self-hosted instance. The trade-off is that Dev Mode's generated code snippets and measurement views have no documented equivalent in the sources for this page. Before you commit, export a real component to SVG and CSS and check whether the output is clean enough for your front-end stack.
Native design tokens
Penpot includes native design tokens, so colors, spacing and typography values can be defined once and referenced across components. Engineers then receive named values instead of hard-coded numbers copied from the canvas. The gap to plan for is the bridge into your build pipeline: confirm which token format Penpot exports, whether a sync or transform step is required, and who owns that step. Without it, tokens stay in the design file and drift from the code.
Plugins and open API
Penpot's plugin system and open API let your team build custom handoff tooling, such as scripts that read file data and publish specs to an internal page. This fits organizations with an internal developer portal or a specific review process that Dev Mode does not match. The cost is ownership: your team builds, tests and maintains the tooling, and must track API changes across Penpot releases. Review the release notes for each version you run before upgrading the plugin code.
Prototype flows need rework
Penpot's Figma exporter plugin converts files into a .zip that Penpot can import, but it does not support prototyping settings. If developers currently read interaction behavior from Figma prototypes, those flows must be rewritten as written specifications or rebuilt in another tool. Inventory the prototype links in your active files before migration so the gap is known early. Confirm with your product owners which flows are specifications and which are only reference material.
Pairing with documentation or review tools
Acceptance criteria, handoff notes and design-to-code review usually live outside the design tool. Teams commonly pair Penpot with a self-hosted Git forge such as GitLab, Gitea or Forgejo, or with a wiki, both covered on other pages in this collection. Confirm whether comments in Penpot can link to tickets or repository issues in your setup, since this is not documented in the sources for this page. Agree on one system of record for each handoff decision so engineers do not have to check two places.
Running Penpot next to Figma and your engineering stack during the transition
Many organizations cannot move every design file in one step. Active projects may depend on Figma prototypes, plugins or libraries that other teams still use, so the two tools often run side by side for a period. In that setup, Penpot should own the projects that move, and Figma should keep the rest until their owners agree on a date.
- Assign ownership per file: Record which team owns each file in each tool so that no design is edited in both places.
- Plan for prototypes: Penpot's Figma exporter plugin does not support prototyping settings, so flows that depend on them need to be rebuilt in Penpot or kept in Figma.
- Track library dependencies: Components shared across teams can drift if one side republishes. Decide which library is the source of truth during the overlap.
- Set a review cadence: A short recurring check on which files have moved keeps the overlap from lasting longer than planned.
- Keep local backups: Figma local copies (.fig, .jam or .deck) carry no version history or comments, so export comments and notes separately before archiving.
Confirm with your design leads which Figma features your active projects actually use, then test the exporter on one representative file before setting any cutover date.
Teams that move design and developer handoff at the same time avoid a split where designers work in Penpot and engineers still inspect specs in Figma. Penpot keeps its design files in open formats (SVG, CSS, HTML and JSON), so developers can read values and assets without a proprietary viewer. The handoff workflow then runs on the same self-hosted instance as the design work.
- Inspect in the same place: Designers and developers open the same files, so specs, measurements and exported assets come from one source.
- Export in standard formats: Assets and values can be taken out as SVG, CSS and JSON, which fits existing front-end build steps.
- Use the open API: Scripts can read file data for documentation or checks, and plugins can add handoff tools inside the instance.
- Align naming before import: Layer, component and style names drive how code is generated and matched, so agree on a convention before migrating.
- Test with one feature team: Run a single product team through the full handoff cycle first, then widen the group.
Before committing, ask a pilot team to list every Dev Mode feature they use daily and mark which have a Penpot equivalent, a workaround or no equivalent.
Penpot has native design tokens, so token definitions can live in the design file rather than in a separate spreadsheet. The practical question for engineering is how those tokens and exported assets reach the build system. The answer depends on the export path your team chooses, so the pipeline should be designed around files that the build can read without a Figma or Penpot session.
- Export tokens as files: Store token files in the repository and have CI jobs read them, so the build never calls the design tool directly.
- Version the output: Commit generated token and asset files with the pull request that changed them, which makes design changes reviewable.
- Script asset exports: Use the open API or a scheduled job to write SVG and other assets into the build directory.
- Pin the instance version: Upgrades can change exporter or API behavior, so test pipeline steps before updating the self-hosted server.
- Document the failure path: Define what happens when an export fails, such as keeping the last good token set.
Confirm the exact token file format and API calls with the Penpot project documentation for the version you run, and test them in a staging pipeline before production use.
A self-hosted Penpot instance supports email and password login by default, and it can also connect to identity systems. Generic OpenID Connect provides single sign-on, and LDAP is available for directory-based accounts. Google, GitHub and GitLab OAuth are also supported. During parallel use, the identity design matters because people will hold accounts in both tools, and access should be removed from both when they leave.
- Choose one identity source: Use OpenID Connect or LDAP as the primary login so accounts follow the organization's joiner and leaver process.
- Keep a break-glass admin: Retain a local administrator account that works if the identity provider is unavailable, and store its credentials securely.
- Map groups to roles: Decide how directory groups correspond to Penpot team roles before onboarding users.
- Review OAuth options: Disable social login providers that conflict with your identity policy.
- Remove access in both tools: Include Figma seat removal and Penpot account deactivation in the same offboarding step.
Confirm the OpenID Connect or LDAP settings, group mapping and any account provisioning behavior with your identity team against the Penpot configuration guide before rollout.
Moving handoff specs and tokens from Figma to Penpot
This sequence moves the design files developers depend on for handoff into Penpot, checks that components, variants, auto layout and text survive the move, and rebuilds what the exporter cannot carry. The result is a set of Penpot files and a build pipeline that developers have reviewed and accepted.
Inventory the files developers use for handoff
The design lead and one or two developers list the Figma files that feed implementation, including component libraries, token sources and any files with prototype flows that specs depend on. Ask developers which frames they open during a typical build and which exports their pipeline reads. The output is a short register with file name, owner, last handoff date and the consuming repository or team. Files nobody opens for handoff can be left out of the first move.
Run the Penpot Figma exporter on a sample
Pick one representative file from the register and run the penpot-exporter-figma-plugin inside Figma. The plugin is maintained by Kaleidos under MPL-2.0 and converts the file into a .zip that Penpot can import. Import the archive into a test Penpot team on your own instance, not the cloud. The output is an imported test file and a log of anything the plugin reported as skipped or unsupported.
Check components, variants, auto layout and text
Open the imported file beside the original and compare, frame by frame, the components and their main instances, variant properties, auto layout behavior when content is resized, and text styles including font fallbacks. Record each mismatch with a screenshot and the node name. Confirm that the exporter's stated limits match what you see, and note that prototyping settings are not carried over. The output is a fidelity checklist signed by the designer who owns the file.
Rebuild prototyping-dependent specs by hand
Prototype links, transitions and interaction flows do not come across through the exporter, so any spec that depends on them has to be recreated in Penpot or documented in the ticket instead. The designer rebuilds the flows that developers rely on and marks the remaining ones as static references. Check the rebuilt flows against the original clickthrough. The output is a list of recreated flows and a list of specs that now live in written acceptance criteria.
Re-link design tokens and exports in the build pipeline
Penpot has native design tokens and reads open formats such as JSON, so map the token set and any exported assets to the paths your build reads today. Update the token and asset references in the repository, then run the build on a branch to confirm the generated CSS variables or asset files match the previous output. Confirm the token names and values with the design system owner. The output is a passing build from the migrated sources and a diff of token values reviewed against the original.
Sign off with developers
Walk the lead developers through the migrated files in Penpot, using the same frames they used for their last feature. Ask them to inspect spacing, color values, asset export and component properties from the Penpot interface, and to report anything they cannot read. Log open items with an owner and a decision on whether each blocks cutover. The output is a written sign-off from each team that consumes the files, or a dated list of items still open.
What changes for designers and developers after the move
The biggest change for developers is where specs come from. In Figma, Dev Mode is the place to inspect properties, copy code snippets and export assets from the same file designers edit. In Penpot, the equivalent handoff work is done inside the design file itself, because Penpot works with open standards such as SVG, CSS, HTML and JSON and stores design tokens natively. Developers should expect to read values from the file, export assets in the formats the team agrees on, and confirm that the exported CSS and SVG match their codebase. Ask your developers to run this check on two or three real screens before you decide, and note which inspection steps take longer than they did in Dev Mode. Confirm current export options and the state of any code-generation features in the Penpot version you deploy, since this page does not claim parity with Dev Mode snippets.
Designers face a different set of changes. Components, libraries and tokens move with the file, but the team must agree how tokens are named, grouped and published before anyone migrates. Without a shared naming convention, token sets drift between designers and developers and the handoff breaks down regardless of the tool. Plugins are a second area to plan. Penpot's plugin system and open API replace some Figma plugins, and the Figma exporter plugin maintained by Kaleidos does not convert prototyping settings, so designers should list which prototype links they rely on and rebuild them where needed.
Ownership changes as well. On Figma, Figma runs the service and the team manages seats and permissions. On a self-hosted Penpot instance, your platform or IT team maintains PostgreSQL, Valkey, object storage, the Penpot release and login configuration, and someone must own upgrades and backups. Decide who receives Penpot release notes, who approves updates in a test environment first, and who answers design-team access requests. Clarify the roles with your provider, DeployOpen or an internal team, in writing before work starts, and ask whether the scope covers upgrades and support after go-live.
Questions buyers ask before replacing Figma Dev Mode
How much does moving from Figma Dev Mode to Penpot cost?
Penpot is licensed under the Mozilla Public License 2.0, so the software itself carries no license fee. The cost sits in the infrastructure around it: servers or cloud accounts for the Penpot application, a PostgreSQL database (version 13 or later), Valkey for websocket notification coordination, and object storage on the filesystem or an S3-compatible store such as MinIO. Migration work, identity setup and support add to that. Some costs are one-time, such as setup, identity integration and moving libraries. Others recur, including hosting, storage growth, backups, patching and staff time. Costs rise with the number of users, the size of your design libraries and your uptime and backup requirements. Ask any implementation partner for a quote that lists each component separately and marks which items are one-time and which recur.
How long does a Figma to Penpot move take?
The duration depends mostly on the size and structure of your files, the number of shared libraries, and how many screens depend on features that do not convert. Penpot's Figma exporter plugin converts files into a .zip that Penpot can import, but it does not support prototyping settings, so teams with heavy prototype logic need extra rebuild time. A practical first step is a pilot: export a representative set of files, import them, and compare components, variants, auto layout and text against the originals. The pilot results give you the information to plan from. No general duration applies to every team, so ask for a timeline built from a written scope that follows the pilot. Very large files may need to be split and exported in batches.
Can our team migrate from Figma to Penpot without outside help?
Yes, a team with Linux, container and database administration skills can deploy Penpot with Docker Compose or the official Helm chart and move files without an outside partner. The work is more than a single install, though. Your team would own the PostgreSQL database, Valkey, file storage, TLS certificates, backups, upgrades and identity configuration. Teams without that skill set in-house often bring in outside help for part of the work. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure. Work is usually agreed under a fixed scope in writing before it starts, and ongoing support and upgrades are available as retainers. Whichever path you take, confirm who will operate the instance after go-live.
Which Figma Dev Mode features have no direct Penpot equivalent?
Penpot works with open formats such as SVG, CSS, HTML and JSON, has native design tokens, and offers an open API and plugin system, so developers can read design data and build their own handoff tooling. Figma-specific Dev Mode features and their plugin ecosystem do not transfer one for one, however. Prototyping settings do not convert through the exporter plugin. Check each Dev Mode feature your engineers use every day, such as generated code views, measurement and spec panels, linked resources and third-party integrations, and confirm whether Penpot offers the same behavior today. Replace each missing feature with Penpot's API, an existing plugin or a small internal script, and record every gap as a decision that the design and engineering leads sign off on.
Does Penpot offer a cloud plan, and what does it cost?
Yes. Penpot's pricing page, as read in October 2026, lists a Professional plan at $0, an Unlimited plan at $7 per editor per month capped at $175 per month, an Enterprise plan at $25 per member per month, and a Private Server option at $50k per year. These figures come from the vendor and can change, so confirm them on the Penpot pricing page before you budget. A cloud plan removes server operations, but design files then sit on Penpot's infrastructure, so check the hosting location and data handling terms against your data residency requirements. Self-hosting replaces the subscription with the infrastructure and staff costs described above, and that choice should follow from your residency and control requirements.
What does our team need to provide before a Penpot project starts?
Provide an accountable admin owner with time to review designs and make decisions, a named technical contact for infrastructure and identity, and a set of representative test files that includes large libraries and heavily prototyped screens. You also need access to your identity provider. Penpot supports email and password login by default, plus Google, GitHub and GitLab OAuth, generic OpenID Connect for single sign-on, and LDAP, so decide which method your organization requires before go-live. Confirm the hosting capacity in your own environment, a PostgreSQL 13 or later database, file or S3-compatible storage, backup targets and a change window for cutover. Name the people who will sign off on fidelity checks after import.
Can Penpot match Figma's team and governance controls?
Penpot can run with your own identity provider and keeps design files on servers you control, but it does not automatically match every governance feature Figma offers. Confirm which administration, audit and permission controls your compliance team requires, then test each one in Penpot before retiring Figma. For comparison, Figma's data residency solution is available only on its Enterprise plan, and comments, file names, plugins, fonts and preview thumbnails are not hosted in the chosen region. Map where each data type lives in both tools. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies perform those steps.
Which Dev Mode gaps matter for your team and which do not
Start by sorting each Dev Mode feature your team uses into one of three groups: things you use every day, things you use occasionally, and things you use only because they came with the seat. Only the first group can block a move, and it is usually small. For each feature in the first group, write down who depends on it, what they do with it after handoff, and whether Penpot already covers the same job through its open formats, CSS and HTML output, design tokens and API. Prototyping settings are the clearest case. The Penpot Figma exporter does not carry prototyping settings across, so a team that hands off interactive flows from Figma needs a plan for those flows before committing, such as rebuilding them in another prototyping tool or keeping them documented in a separate spec. Next, review the Figma plugins your developers and designers run every week. Plugins that read tokens, generate code snippets or push assets to a repository are the ones to test first, because they depend on Figma's own API and plugin catalog. Penpot has its own plugin system and open API, so a plugin may have an equivalent, may need rewriting, or may have no counterpart at all. Ask each plugin owner to name the output the plugin produces and the consumer downstream. A pilot with a representative file set will answer most of these questions faster than a feature comparison document. Finally, check how review actually happens. If designers and engineers use comment threads tied to specific Dev Mode states, such as an approved component or a redline, confirm how Penpot comments and version history work for that workflow, and whether your existing ticket or repository links still resolve after migration. Confirm these points with Penpot's maintainers or in your own environment during a pilot, and record the result for each feature. A gap that matters to one team but not others should be solved for that team, not used as a reason to keep every design file in Figma.
Risks to plan for before cutting over handoff
Moving developer handoff from Figma Dev Mode to Penpot changes where design data lives, how tokens reach code and who operates the service. The risks below connect because each one surfaces only in a pilot with real files, real developers and a restore test, so run those before retiring Dev Mode for any team.
Exporter fidelity on large files
The penpot-exporter-figma-plugin converts Figma files into a .zip that Penpot can import, and it does not carry prototyping settings. Large or heavily nested files, custom fonts and component variants are the most likely to lose structure on import. Test by exporting your three most complex production files, then compare component counts, auto layout behavior, text wrapping and library links in Penpot against the originals. Record every difference before deciding which files move first.
Loss of prototyping specs
Prototype links, transitions and interaction settings do not come across through the exporter. Developers who rely on prototype flows to understand navigation or motion will lose that context unless it is rebuilt or documented elsewhere. Inventory every prototype used as a handoff reference, decide whether to recreate it in Penpot or write the behavior into the ticket, and confirm that reviewers can still follow the intended user journey.
Token drift between design and code
Penpot has native design tokens, but tokens in the design file only stay aligned with code if a team defines a single source and a sync step. Drift appears when a designer changes a value in Penpot while a repository still holds the old value. Test a token change end to end: edit a color in Penpot, run your export or build step, and confirm the value that reaches the UI and the stylesheet. Assign an owner for the token source of truth.
Instance operations and backups
A self-hosted Penpot instance needs PostgreSQL, Valkey and file storage on the filesystem or in S3-compatible storage such as MinIO, and each one must be backed up and restored together. A database restore without the matching uploaded objects leaves broken images and components. Confirm the PostgreSQL version meets the supported minimum of 13, schedule backups for every component, and run a full restore into a separate environment before go-live.
Identity configuration errors
Self-hosted Penpot supports email and password login by default, plus Google, GitHub and GitLab OAuth, generic OpenID Connect and LDAP. A wrong redirect URL, a missing group mapping or a stale directory sync can lock out developers or leave former staff with access. Test sign-in for every user group, confirm that removing someone from the identity provider revokes Penpot access, and document which accounts are local break-glass users.
Developer adoption
Developers used to Dev Mode inspect panels will look for specs, code snippets and measurements in a different place. Without a short onboarding and a clear rule for where handoff notes live, teams drift back to screenshots or direct messages. Run a pilot with two or three squads, record the questions they ask in the first two weeks, and update the handoff template with the answers. Track whether tickets still reference the design file.
How DeployOpen scopes and delivers a Penpot handoff migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Penpot handoff setup runs on servers you control. For developer handoff, we define which Dev Mode workflows move to Penpot, how design tokens and exports reach your codebase, and what your developers need to confirm before the team relies on it.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- The written scope lists which Dev Mode workflows, such as inspect, code snippets and asset export, must carry over
- We record which Figma features have no direct Penpot equivalent so the team can plan workarounds in advance
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
How we build
- We deploy Penpot in your environment with PostgreSQL, Valkey and filesystem or S3-compatible storage for uploaded objects
- We configure login through your identity provider, using OpenID Connect or LDAP where your policy requires it
- We set up design token structures and export paths so frontend and mobile code can consume them from the repository
- We test handoff against a sample of real screens from your team's current Figma files, with your developers reviewing output
How we hand over
- You receive runbooks for deployment, upgrades, backups and restores, written for your platform and operations staff
- Developer guides document how to inspect specs, read CSS and SVG output, and use the open API and plugin system
- A fidelity checklist records which components, variants, auto layout and text styles converted and which need manual rework
- Access, backup and configuration decisions are documented so your own auditors can review the controls
How we support
- Support covers Penpot version upgrades, including checking each release's notes before you apply it
- Backup and restore tests run on a schedule you agree, so recovery is verified rather than assumed
- Retainers can include periodic security testing of the Penpot instance and its integrations
- DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications
