Should a security-conscious design team choose Sketch Private Cloud or self-hosted Penpot?
Start with one question: who must control the servers that hold your interface files? Sketch Private Cloud is a vendor-operated option, so the vendor runs the environment and sets its maintenance schedule. Self-hosted Penpot is open source under the Mozilla Public License 2.0 and runs on infrastructure your organization controls. For a security-conscious design team, that difference decides who patches the platform, who manages backups and encryption keys, and who answers when an auditor asks where design files live. This section frames the decision. The sections below cover data location, login options and the operating work each choice leaves with you.
Before comparing features, get written answers from Sketch on the Private Cloud deployment: the region or data center, whether the environment is dedicated to your organization, who holds administrative access, and how and when updates are applied. Ask whether you can approve upgrade windows and how your data is returned or deleted if you end the contract. With self-hosted Penpot, those answers come from your own change process. Penpot documents self-hosting with Docker Compose and an official Helm chart, so your team chooses the cluster, the region and the network boundary, and also owns patching, backups and monitoring. Confirm that your platform team has the capacity for that work before you commit.
Login is where the two options diverge most in day-to-day administration. Self-hosted Penpot supports email and password login by default, plus Google, GitHub and GitLab OAuth, generic OpenID Connect for single sign-on, and LDAP, so access can follow your existing directory and offboarding process. Check which login methods Sketch Private Cloud supports and whether it can enforce your identity provider policies, such as multi-factor authentication and session limits. In short, Private Cloud shifts operational work to the vendor, while self-hosted Penpot keeps the servers, updates and identity configuration in your hands. The rest of this page covers each area in turn.
What a control-focused constraint requires from a design tool
A design tool that stays under your control has to answer four questions: who runs the servers, who decides when updates land, which sign-in methods are allowed, and where design data physically sits. Sketch Private Cloud and self-hosted Penpot answer these differently, so each card lists what to confirm before you commit.
Who operates the server
With a vendor-hosted Private Cloud, the vendor or its hosting partner typically runs the infrastructure, so your team depends on its staffing, access controls and incident process. With self-hosted Penpot, your own team or implementation partner runs the Docker Compose or Helm deployment, which means you own patching, monitoring and restores. Ask Sketch in writing who holds administrative access to the Private Cloud environment and which staff can reach customer data.
Who controls updates
Self-hosting lets you choose when a Penpot release goes into production, test it against your plugins and integrations, and roll back if needed. Under a vendor-managed tier, upgrade timing and maintenance windows are set by the vendor, so ask whether you can defer a release, how much notice you get and whether a staging environment is included. Penpot's release history shows frequent point releases, so the update process matters as much as the version.
Which login methods are allowed
Self-hosted Penpot supports email and password login by default, plus Google, GitHub and GitLab OAuth, generic OpenID Connect for single sign-on, and LDAP. Your identity provider decides who can sign in and how quickly access is removed when someone leaves. Confirm with Sketch which SSO protocols and directory connectors the Private Cloud tier supports, whether SCIM provisioning is included, and whether enforced MFA is controlled by you or the vendor.
Where design data is stored
Penpot stores design data in PostgreSQL, which must be version 13 or later, and keeps uploaded objects on the filesystem or in S3-compatible storage such as MinIO. You choose the data center, the backup location and the storage encryption. For Sketch Private Cloud, ask for the hosting region, the locations of backups and replicas, whether any file metadata or telemetry leaves that region, and how deletion requests are honored.
Who can audit and exit
Your ability to produce evidence and to leave depends on the data formats and the logs you can reach. Penpot is open source, and its files work with open standards such as SVG, CSS, HTML and JSON, which eases export. Ask Sketch what audit logs are available to administrators, how long they are kept, whether they can be exported to your SIEM, and which file formats a full export returns.
How Sketch Private Cloud and self-hosted Penpot differ on control and data location
Server operation decides who installs, patches, monitors and recovers the system that holds your design files. With a vendor-hosted Private Cloud tier, the vendor runs the environment and your team's job is to verify the contract and the operating terms. With self-hosted Penpot, your platform team runs the stack. Penpot documents self-hosting with Docker Compose and an official Helm chart, and it needs PostgreSQL 13 or later, Valkey for websocket notifications, and either a filesystem or S3-compatible storage such as MinIO for uploaded objects. See the Penpot configuration guide for the settings involved.
- Host ownership: Self-hosting means your staff or contractor provisions the nodes, chooses the cloud account or data center, and sets capacity.
- Dependent services: PostgreSQL, Valkey and object storage each need backups, monitoring and patching on a schedule you set.
- Recovery: You define backup frequency, restore testing and failover. Ask Sketch in writing for its recovery point and recovery time commitments.
- Vendor access: Ask Sketch who holds administrative access to the Private Cloud environment, from which locations, and how that access is logged.
Compare the staff hours your team would need to run the full stack with the operations model Sketch documents for its tier, and get that model in writing.
Update control determines when new code reaches your users and how quickly security fixes are applied. Penpot publishes releases on GitHub at a steady pace. For example, Penpot 2.18.1 was published on October 1, 2026, 2.18.2 on October 5, and 2.18.3 on October 6, 2026, so a self-hosting team needs a standing update process. With a vendor-hosted tier, the vendor chooses the timing, and your contract determines how much notice you receive and whether you can delay a change.
- Upgrade timing: Self-hosted teams choose when to pull a new version and can hold a release until it has been tested.
- Staging: You can run a test environment with a copy of the production database and verify migrations before changing production.
- Vendor notice: Ask Sketch for its notice periods, maintenance windows and whether a customer can defer an update.
- Security fixes: Ask how critical fixes reach the Private Cloud tier and how quickly. For self-hosted Penpot, patch speed depends on your own staffing and approval process.
- Rollback: Ask Sketch whether it supports a rollback path if an update causes a problem. Self-hosted teams should document their own rollback steps before the first upgrade.
Request the vendor's update, notice and rollback terms in writing, and set a self-hosted patch window that your security team has approved.
Login options determine how people sign in, how access is removed when someone leaves, and whether your identity provider remains the source of truth. Self-hosted Penpot supports email and password login by default, along with Google, GitHub and GitLab OAuth, generic OpenID Connect for single sign-on, and LDAP. The Penpot configuration guide lists the settings for each. Sketch's login options for its Private Cloud tier were not part of the supplied material, so they must be confirmed directly with the vendor.
- Built-in accounts: Email and password is the default in self-hosted Penpot. Enforce password policy and multi-factor authentication through your identity provider wherever your setup allows it.
- Directory integration: OpenID Connect and LDAP connect Penpot to your directory. Confirm group mapping and account deprovisioning with your identity team before go-live.
- Social providers: Google, GitHub and GitLab OAuth may not fit a regulated identity policy, so decide which providers to enable, if any.
- Sketch's options: Ask Sketch in writing which single sign-on protocols, provisioning methods, multi-factor controls and session limits the Private Cloud tier supports.
Map each login path to your joiner, mover and leaver process before choosing a model, because a login that works in testing can still leave accounts active after someone departs.
Data location determines which jurisdictions, subprocessors and support staff can reach design files, comments and metadata. With self-hosted Penpot, files and database records stay wherever you deploy them, whether in your own data center, your cloud account, or an air-gapped network. With a vendor-hosted tier, the vendor determines the primary and backup regions, and the contract determines what you can verify. Residency commitments often cover some data but not all of it, so read the scope carefully. Figma's residency documentation, for example, states that comments, file names, plugins, fonts and preview thumbnails are not hosted in the chosen region. Treat that as a question to put to Sketch, not as a statement about Sketch.
- Hosting region: Self-hosted data sits in the location you select. For the Private Cloud tier, ask Sketch for the region, data center and backup locations in writing.
- Metadata and previews: Ask whether file names, comments, thumbnails, fonts and plugin data are hosted in the same region as the design content.
- Support access: Ask who at the vendor can view customer content, from which countries, and under which approval process.
- Export and exit: Self-hosted Penpot keeps data in PostgreSQL and object storage you control. Ask Sketch which formats it supports for exporting all project files.
File the vendor's written answers with your data protection and records teams before you decide, and record the same questions for any self-hosted deployment.
Which self-hosted options fit when design files must stay on your servers
This table compares Penpot, draw.io and Excalidraw by the design work each one handles and the license behind it. Read the rows as a fit check: Penpot is the option for interface design files, while draw.io and Excalidraw cover diagrams and whiteboarding. The main takeaway is that only Penpot takes over Sketch-style interface design, and even then the team should test its own file set before committing.
| Capability | Penpot | draw.io and Excalidraw |
|---|---|---|
| Primary purpose | Interface design and prototyping in a browser | draw.io for diagrams; Excalidraw for collaborative whiteboards and sketches |
| License | Mozilla Public License 2.0 | draw.io is Apache 2.0; Excalidraw is MIT |
| Fit for Sketch-style interface work | Yes | No |
| Open standards in files | Works with SVG, CSS, HTML and JSON, with native design tokens | Diagram files and whiteboard scenes; not designed for component-driven UI work |
| Figma import path | Figma exporter plugin converts files to a .zip Penpot can import | Not a design file import path; draw.io imports Visio and Lucidchart diagrams |
| Known trade-off | The Figma exporter does not support prototyping settings, so prototype flows need rebuilding | Limited suitability for pixel-level UI specs and prototypes |
| Data location | Self-hosted on servers you control, with PostgreSQL and object storage under your administration | draw.io saves diagrams where the user chooses; Excalidraw collaboration is end-to-end encrypted |
| Confirm before choosing | Test your own Sketch files, plugins and shared libraries on a staging instance | Confirm that the team's artifacts are diagrams or whiteboards, not interface masters |
How to deploy self-hosted Penpot under your control
This sequence takes a design team from choosing a deployment path to a Penpot instance that runs on servers you control, with your own database, storage, login method and upgrade routine.
Choose the deployment path
Your platform team picks how Penpot will run: Docker Compose for a single host, the official Helm chart for a Kubernetes cluster, or one of the other documented routes such as OpenShift, Rancher, Elestio or TrueNAS. The choice depends on what your infrastructure team already operates and supports. Confirm with the team that will carry the pager which path they can patch and back up. You are done when the target platform and its owner are named in writing.
Provision PostgreSQL 13 or later
Your database team creates a PostgreSQL instance on version 13 or later, which is the minimum the Penpot configuration guide recommends. Penpot supports only PostgreSQL, so this is the single database engine you will operate. Set up encrypted connections, scheduled backups and restore tests under your existing standards. You are done when a test restore from backup succeeds and the database accepts connections only from the Penpot services.
Add Valkey for websocket coordination
Deploy Valkey alongside Penpot, because the platform uses it to coordinate websocket notifications between services. Keep it on the same private network as the application and restrict access to it. Confirm the connection settings in the Penpot configuration guide before you start the application containers. You are done when the application logs show a successful connection and two browser sessions receive live updates on the same file.
Configure file storage
Choose where uploaded objects such as images and assets are kept: the local filesystem or an S3-compatible store such as MinIO. A filesystem works for a single host, while object storage suits clustered deployments and gives you a separate backup target. Set the storage settings in the configuration guide and place the bucket or volume under the same backup policy as the database. You are done when an uploaded image persists after the application container restarts.
Set the login method
Decide how people sign in. Penpot uses email and password by default, and it also supports Google, GitHub and GitLab OAuth, generic OpenID Connect for single sign-on, and LDAP. For regulated teams, OpenID Connect or LDAP usually fits identity governance better, and you should confirm with your identity team which option ties into your directory and multi-factor policy. Disable self-registration if only directory users should have access. You are done when a test account from your directory signs in and an unlisted account is refused.
Prepare air-gapped delivery if required
If the environment has no internet access, plan the image transfer before installation. For Kubernetes, the kubeadm documentation describes listing and pulling control plane images in advance and pointing kubeadm init at a private registry with the image repository flag. Mirror the Penpot images and chart into your internal registry the same way, and verify each artifact against the publisher's checksums before it crosses the boundary. You are done when a cluster with no outbound route pulls every image from your internal registry.
Plan upgrades against the release page
Set up a recurring review of the Penpot GitHub releases page, read the changelog for each release, and test the new version in a staging copy with a restored database backup before production. Penpot publishes frequent point releases, so decide in advance who approves each upgrade and how a rollback works. Record each version you run in your change log. You are done when a staging upgrade completes from a production backup and the rollback path has been tested.
What moving existing Sketch files to Penpot involves
No Sketch importer is documented in the supplied facts, so a team moving to self-hosted Penpot should plan on rebuilding most artboards or moving them through indirect routes. The Figma exporter plugin, maintained by Kaleidos under MPL-2.0, converts Figma files into a .zip that Penpot can import, but it does not carry prototyping settings. That makes it a partial route for Figma-origin files and not a general path for Sketch documents. Before committing, confirm with the Penpot project and its current documentation whether a Sketch-specific import exists or is planned for your version.
The effort driver is the structure of the existing Sketch files, not their number of screens alone. Check how much of the design system lives in shared symbols, text and color styles, and components, and whether those assets map cleanly to Penpot components and design tokens. Penpot has native design tokens and works with open standards such as SVG, CSS and JSON, so teams with a disciplined token layer will usually find the rebuild simpler than teams whose styles are hard-coded per layer. Inventory these assets before estimating anything.
Run a pilot before deciding on a full migration. Choose one product area with a few flows, one component library and at least one prototype, then rebuild it in a self-hosted Penpot instance. Record which steps needed manual work, which assets lost fidelity and which plugins or prototyping links had to be redone. Use that log to set the scope of the remaining work and to write the quote request, asking the implementation partner to price the inventory, the rebuild and the handover separately.
Evidence to collect for a control review of the design platform
A control review of a design platform asks for the same core records whichever way the server is run. The cards below cover what the organization should hold for a self-hosted Penpot deployment, and each one names what to check before the review starts.
Deployed Penpot version and release source
Record the exact Penpot version running in production, the image or chart tag it came from, and the date it was deployed. Penpot publishes numbered releases on its GitHub releases page, so the record should show which release was installed and that it came from the official source rather than a rebuilt image. Keep the same record for staging and disaster recovery copies. Confirm which release your team tested before the production upgrade.
Identity configuration and access policy
Document which login methods are enabled, such as email and password, Google, GitHub, GitLab, generic OpenID Connect or LDAP, and who can use each one. Include the settings that control registration, the mapping between directory groups and workspace roles, and how departing staff lose access. Auditors usually want to see that the access policy matches the identity provider's own records, so export the configuration alongside the policy text.
Database and storage backup records
Keep dated evidence that PostgreSQL and the object store, whether filesystem or S3-compatible storage such as MinIO, are backed up and that the two backups belong to the same point in time. Record backup schedules, retention periods, encryption, storage location and the result of the most recent restore test. A backup that has never been restored is weak evidence, so schedule and log a restore test with the design team present.
Update and patch process
Write down how the team learns of a new Penpot release, how it tests the release, who approves it and how rollback works. Keep the change tickets, the test results and the date each upgrade reached production. Note also how base components are patched, including the Kubernetes or Docker host, PostgreSQL and Valkey, since these sit outside the Penpot release cycle.
Software integrity and package verification
Where packages or images are moved into an isolated network, keep records showing how they were obtained, how their checksums or signatures were verified and who approved the transfer. This matters most for regulated networks, where supply chain procurement controls, such as the verification of vendor software and patches in NERC CIP-013-2, expect this evidence. Confirm the verification method with your own compliance lead before the review.
Hosting responsibility and control ownership
Assign a named owner for each control, showing which controls the organization runs itself and which, if any, DeployOpen supports under a fixed-scope engagement or retainer. Show who controls the servers, the update schedule and the network boundary, and how that differs from a vendor-hosted Sketch Private Cloud arrangement. DeployOpen prepares these records and does not issue audit reports or certifications. The auditor decides whether the evidence is sufficient.
What do teams ask before choosing self-hosted Penpot over Sketch Private Cloud?
What drives the cost of self-hosting Penpot instead of paying for Sketch?
Self-hosted Penpot has no software license fee, so the cost is the infrastructure and the people who run it. Penpot is licensed under the Mozilla Public License 2.0, so the software itself is free to use. The recurring costs are the application server, a PostgreSQL database (version 13 or later is recommended), a Valkey service for websocket notifications, and object storage on the filesystem or an S3-compatible store such as MinIO. Costs rise with the number of editors, the volume of files, backup retention and high availability requirements. One-time costs include the initial deployment, file migration and rebuilding designs. Ask every provider to split its quote into these lines so you can compare them with Sketch's current fees.
What does Penpot's cloud pricing cost per editor and per year?
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 (Penpot pricing). These are Penpot's cloud list prices, not DeployOpen fees or Sketch prices. A self-hosted deployment avoids these subscription fees but takes on the server, database, storage and support costs described above. For a fair comparison, get Sketch's current per-editor and Private Cloud quotes in writing for the same headcount and period, then set them against the infrastructure and support lines in your own scope.
What must our internal team provide for a self-hosted Penpot deployment?
Your team provides the environment and the decisions. You need a container or Kubernetes host in your own data center or cloud account, since Penpot documents Docker Compose and an official Helm chart. You also need a PostgreSQL server at version 13 or later, storage for uploaded objects, and an identity owner who connects Google, GitHub, GitLab, OpenID Connect or LDAP. A backup owner must own restore testing, and someone must approve upgrades and access changes. Decide who receives security alerts and who signs off on new administrators. Ask any implementation partner to list these responsibilities in the written scope so that no task falls between teams.
Can our own engineers deploy self-hosted Penpot without outside help?
Yes, if your platform team already runs containers, PostgreSQL and single sign-on in production. Penpot's getting started guide covers Docker Compose, the official Helm chart, OpenShift, Rancher, Elestio and TrueNAS, so the main choice is the platform you already operate. Teams often underestimate the ongoing work: patching, backup restores, certificate renewal, storage growth and monitoring. Outside help makes sense when you need a fixed-scope deployment, hardening, integration with existing identity systems and documented evidence for an assessment. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside the client's infrastructure under a written scope, and offers retainers for ongoing upgrades and support.
How long does it take to deploy self-hosted Penpot?
The sources for this page do not give a deployment duration, so treat any number you hear as a claim to verify. The time depends on the platform you deploy to, whether an identity provider is already in place, how many files you migrate, and whether you need high availability and tested backups before go-live. A single-host pilot is a much smaller project than a multi-team rollout with single sign-on and recovery testing. Ask for a timeline in the written scope that lists each phase, its owner and its acceptance tests. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
Does Sketch Private Cloud let us control updates and server location?
Confirm this with Sketch in writing before you decide, because the sources for this page do not describe Private Cloud's hosting model, update control or maintenance responsibilities. Ask who operates the servers, which region they run in, who applies security patches and feature releases, how much notice you receive, and whether you can defer an update during a freeze. Ask whether your administrators can see audit logs and whether you can restore data without vendor involvement. With self-hosted Penpot, your team decides when to upgrade between releases such as 2.18.1, 2.18.2 and 2.18.3, and you choose where the database and object storage sit.
How do login options compare between self-hosted Penpot and Sketch?
Self-hosted Penpot supports email and password login by default, along with Google, GitHub and GitLab OAuth, generic OpenID Connect for single sign-on, and LDAP, as documented in the Penpot configuration guide. You choose which methods to enable, so your own identity provider remains the source of access decisions. For Sketch, confirm in writing which sign-in methods, single sign-on protocols and directory integrations its Private Cloud tier and workspace plans support, and whether automated user provisioning is included. Ask how offboarding works on each product, since removing a user from your directory should end access quickly. Test every login path with a non-admin account before go-live.
How DeployOpen implements self-hosted Penpot under your constraints
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Penpot deployment, we start from where your design files must live, who must control servers and updates, and which login method your identity team will operate.
How we scope
- Written scope fixes hosting location, server ownership, update responsibility and login method before any build work starts.
- We confirm which design teams, file volumes and external collaborators the Penpot instance must serve.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
- We record PostgreSQL and object storage choices, including filesystem or S3-compatible storage such as MinIO, in the scope.
How we build
- We deploy Penpot with Docker Compose or the official Helm chart, matching your existing container platform.
- We configure email and password login, or OAuth or OpenID Connect single sign-on, against your identity provider.
- We set up PostgreSQL 13 or later, Valkey for websocket coordination and backup-ready storage paths.
- We test the Figma exporter workflow on sample files and document where rebuilds are needed.
How we hand over
- You receive architecture notes, configuration records, access model and runbooks for installing and updating Penpot.
- We document the update process, including how new Penpot releases are tested and promoted in your environment.
- Backup and restore procedures are tested and handed over so your team can recover design data independently.
- Evidence for your compliance assessments is prepared, while independent auditors or certification bodies issue any reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Security testing of the Penpot instance and its login integration can be scoped separately.
- We agree with you in advance which patches and upgrades are applied in your environment and on what cadence.
- Your team keeps control of servers, data and credentials throughout the engagement and after it ends.
