Penpot: develop is the default branch and governance is the paid tier

The default branch is develop, so a clone is not a release

Penpot's default branch is develop, not master or main. That single fact changes what you get when you clone. The published releases are numbered separately, with 2.18.0 on 2026-09-23, 2.17.2 on 2026-08-27, and 2.17.1 on 2026-08-17, and the repository was last pushed to on 2026-09-29. What a plain clone cannot do is give you a release. Because the default branch tracks in-progress work, a reader who needs a reproducible build has to check out a tag rather than trust the branch tip, and the root package.json shows why that distinction matters: it declares version 2.17.0 while the newest published release is 2.18.0, so the manifest on develop and the shipped release are not the same artifact. Pin the tag when the difference between a development build and a release matters to you.

The npm package is dev tooling, the application is Clojure

Penpot's primary language is Clojure, and the JavaScript side of the repository is tooling rather than the app you install. The root package.json is marked private, declares no runtime dependencies, and lists only devDependencies: Playwright and its test runner, the Playwright MCP package, Node type definitions, commander, dotenv, esbuild, mdts, and nrepl-client, with pnpm pinned at 12.6.0 through pnpm-workspace.yaml and pnpm-lock.yaml. On the Clojure side there is a deps.edn manifest plus tooling configs such as .clj-kondo for linting and .cljfmt.edn for formatting, and a .devenv directory. What this layout cannot do is hand you an npm install that runs Penpot. There is no published package to install the platform from, so a reader looking for a one-line npm setup is looking in the wrong place, and the documented route into running the platform is deployment rather than a package manager.

One repository, several services, no single binary

The top level shows how much sits behind the product: backend/, frontend/, common/, library/, exporter/, render-wasm/, media-processor/, plugins/, and mcp/, alongside docker/, scripts/, docs/, and experiments/, with a manage.sh at the root. That is a frontend, a backend, an exporter, a WebAssembly renderer, a media processor, a plugin system, and an MCP server sharing one repository. What this structure cannot do is give you a single process to start for local development. The project's own answer to running Penpot is deployment rather than a dev command: it describes itself as deployment agnostic, letting you use its SaaS or deploy it anywhere, and it points to Docker, Kubernetes, Elestio, or other options for installation without printing a command on the front page. A reader who wants a hosted instance should take the SaaS path, and one who needs their own servers should follow the self-host instructions rather than trying to run the repository as a single app.

Automation runs on webhooks and an access token

Penpot integrates with the development toolchain through webhooks and an API reached with access tokens, and that is the whole of the programmatic surface the front page promises. The shape of a credential is visible in the repository's .env.example, which is titled as configuration for an error-reports CLI tool:

PENPOT_API_URI=http://localhost:3450
PENPOT_ACCESS_TOKEN=your-access-token-here

What this cannot do is make the platform scriptable without your own secret in hand. Every integration, script, and CI job you write carries a token you must issue and protect, and the example values are placeholders you have to replace. Note also the scope: that file documents a specific CLI tool pointed at localhost port 3450, so it shows how a Penpot credential is expressed without telling you the default port of a full deployment.

Inspect mode hands out SVG, CSS, and HTML

Penpot is built on open standards, and it says it works with SVG, CSS, HTML, and JSON whether you use it in the browser or on your own servers. The inspect tab is where that pays off for developers, giving instant access to SVG, CSS, and HTML code instead of a table of values. The design is expressed as code so it stays readable by developers and by AI, and the MCP server is what lets a model read that design back out. Layout follows the same principle, with CSS Grid and Flex Layout available so responsive interfaces behave like real code from the start. What inspect mode cannot do is remove the translation step entirely. It gives you code generated from the current design, which means the output is only as current as the last time somebody committed a change, and a developer still has to decide what to do with it.

Governance, permissions, and SSO are the paid tier

Penpot is open source under MPL-2.0, and the platform itself is free to run, including self-hosted. The paid part is scoped to governance. Penpot Enterprise is the plan for organizations scaling design work across multiple teams that need advanced governance, security, and administration, and what it adds is a centralized Admin Console, advanced permissions, and connecting an identity provider through SSO, available for both cloud and self-hosted environments. What self-hosting the open build cannot do is hand you those controls. If your reason for self-hosting is compliance, be clear that the compliance features named here belong to the commercial plan, sitting on top of the open-source foundation rather than inside it. That split is also the answer to whether Penpot is entirely free: it is not, even though the editor, the API, the plugin system, and the MCP server are open.

Design tokens carry the contract, the integrations carry the enforcement

The shared source of truth in Penpot is the set of native Design Tokens, Components, and Variants, which the project positions as the thing that keeps design and development consistent and makes complex design systems manageable. Around that sit the extension points: a plugin system for expanding capabilities and integrating with other apps, and the MCP server, framed as enabling multi-directional workflows between design and code and as a way to make designs readable by developers and AI. Real-time collaboration is optional by design, since you can collaborate or work alone. What these features cannot do is enforce token adoption in your repository. A token is only a single source of truth if the code actually consumes it, and that connection is made through the API, the webhooks, and the MCP server rather than by the editor itself. Those are the pieces you have to build and maintain.

Editorial conclusion

Penpot is a sound choice for a product team that wants its design files in open formats, on infrastructure it controls, and reachable by both designers and developers. It is a weaker choice if SSO, centralized permissions, and admin governance have to come from the same free build, because those live in the paid Enterprise plan. Before you commit, check the MPL-2.0 terms, confirm you can run the deploy path you need since the repository is several services rather than one binary, and read the develop branch as work in progress rather than a release.

Frequently asked questions

Official sources

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