Penpot

Open-source design and prototyping platform

Developer Tools & Git ★ 60.3k stars Medium setup MPL-2.0

Penpot is an open-source design tool for product teams that bridges designers and developers with open standards. It runs in the browser and can be fully self-hosted.

Key features

  • Design and prototyping
  • Open SVG-based files
  • Real-time collaboration
  • Developer-friendly handoff

Pros & cons

Strengths

  • True Figma alternative
  • Open SVG-based standards
  • Strong developer handoff

Trade-offs

  • Resource-heavy stack
  • Performance lags Figma

Penpot replaces

Last reviewed Sep 13, 2026 · 833 words

Budget 2 GB of RAM and 5 containers for Penpot, then stop worrying about hardware, because the hard part of self-hosting it is not the server. It is that moving a team off Figma means re-drawing the design system, and no importer fully spares you that. Penpot is the only open-source tool (MPL-2.0, 59,557 stars) where that trade is worth making: real vector design, components, prototyping, developer handoff with inspectable CSS, and files stored as open SVG-based data you can pull out of the database rather than a proprietary blob.

Who actually runs it

Three groups, in my experience. Product teams in regulated or public-sector organisations who are not allowed to put designs on a US cloud. Agencies that got tired of per-seat pricing as their freelancer roster changed monthly. And developers who want a design tool inside the same self-hosted stack as their Gitea and CI, so a design file and the code it becomes live behind the same SSO. A solo homelabber who draws the occasional diagram is not in this list; Excalidraw runs in one container, uses 100 MB, and is a better fit for boxes and arrows. The broader dev-tools category has more of that shape.

The stack is heavier than the pitch suggests

Penpot's backend is Clojure on the JVM, which is where the 2 GB minimum comes from, and it wants PostgreSQL, Redis (or Valkey), a separate frontend container, and an exporter that runs a headless Chromium for PNG, PDF and SVG exports. That exporter is the container people forget to allocate for; rendering a large board can spike it past 1 GB on its own. The official compose file in the repository's docker/images directory is the sane starting point and is actually intended for production, which is not something I can say of every project in this band.

The settings that matter are environment variables on the frontend and backend:

environment:
  - PENPOT_PUBLIC_URI=https://design.example.com
  - PENPOT_FLAGS=enable-registration enable-login-with-password disable-email-verification
  - PENPOT_DATABASE_URI=postgresql://penpot-postgres/penpot
  - PENPOT_REDIS_URI=redis://penpot-redis/0

PENPOT_PUBLIC_URI must match the URL your reverse proxy serves, or asset links and the exporter break in ways that look like random 500s. PENPOT_FLAGS is where the behaviour lives: open registration is on in the sample file, and you want it off after your team has accounts. Without a working SMTP mailer, keep disable-email-verification or nobody can log in. The compose patterns I use elsewhere apply directly here; one network, named volumes for Postgres and the assets directory, a reverse proxy in front.

Performance is honest, not equal

Large files with hundreds of components render noticeably slower than in Figma, and real-time multiplayer with 6 or 8 cursors on one board can lag on a modest VM. It is fine for a team of 10 designing a product; it is not fine for a 40-person design org working on one giant file. Penpot 2.x moved the render pipeline in the right direction and the gap has narrowed, but I would not tell anyone it has closed. Keep files split by feature area rather than one file per product and most of the pain disappears.

The Figma migration is lossy, plan for it

There is a community Figma-to-Penpot exporter plugin, and it gets shapes, text and basic frames across. It does not reliably carry auto-layout constraints, variants, or component property wiring, so your design system arrives as flat drawings and has to be rebuilt as Penpot components. For a system of 50 components that is 2 or 3 designer-days. For 500, it is a project you schedule. The upside is permanent: Penpot's native .penpot export and the SVG-based storage mean the next migration, if there ever is one, is yours to script. The Figma alternatives page sets out what else you give up, mainly the plugin ecosystem, which Penpot's own plugin API is rebuilding but has not matched.

Backups: the database is only half of it

Files live in Postgres; uploaded assets, fonts and thumbnails live in the penpot_assets volume. Back up both in the same window or a restore gives you designs with missing images. A nightly pg_dump plus a tarball of the assets volume is enough; test a restore into a second instance once, because the two halves must match versions.

What I'd do

For a team of 3 to 15 that wants out of Figma for cost or data-residency reasons, run Penpot on a 4 GB VM with the official compose file, close registration once accounts exist, put it behind SSO via your reverse proxy, and accept a week of design-system rebuilding as the price of owning the files. For a solo developer or a homelab wanting a whiteboard, run Excalidraw instead and save the 2 GB.

Similar developer tools & git apps