Self-hosting

The kit is a Penpot file and a folder of text. There is no account to create, no service to sign in to, and nothing that calls us while you work. That changes what enterprise readiness means here, and it is worth being precise about rather than vague.

Nothing to log into

Single sign-on solves one problem: one identity across many applications. This kit is not an application. It is a file you open in your own Penpot, and a set of instruction files your own AI tool reads from disk. There is no login screen, no session and no user record, so there is nothing for an identity provider to connect to.

That is not a gap waiting to be closed. Putting accounts in front of the kit would mean putting a service between you and a file you already own.

Identity is your Penpot

Access to the kit is access to the Penpot file, and that is governed by your Penpot rather than by us. If your organisation already runs an identity provider, connecting Penpot to it puts the kit behind the same sign-on as everything else your designers use.

What self-hosted Penpot supports today:

MethodConfiguration

OpenID ConnectGeneric OIDC via enable-login-with-oidc, with Azure AD documented as a worked example.

LDAPFull attribute mapping via enable-login-with-ldap.

Google, GitHub, GitLabIndividual OAuth providers, each behind its own flag.

SAMLNot documented. If you need SAML specifically, that is a question for Penpot, not for this kit.

SCIMNot documented. Provisioning is handled through your Penpot team membership.

Nothing phones home

Every part of what you buy runs where you put it:

The file. Opens in your Penpot, self-hosted or not. There is no licence check at runtime and no call out while you design.

The tokens. Plain CSS custom properties in your own globals.css. No SDK, no runtime dependency, nothing to keep reachable.

The agent skills. Markdown files your AI tool reads from disk. They carry no keys and make no network calls of their own.

No telemetry. Nothing counts your seats, your files or your usage, because nothing is listening.

For a team that cannot send design work to somebody else's cloud, the whole thing can live inside the network.

Rolling it out to a team

The real question at scale is not who can log in, but how fifty people get the kit and then get the next version of it. Two moves cover it.

The file

Publish it once as a shared library in your Penpot team. Every project connects to the same source, and updates are offered rather than forced. Membership of that team is your access control, and it is already behind whatever sign-on Penpot is configured with.

The agent skills

Commit them to a repository you host instead of handing out archives. Updating is a pull, the history shows who changed what, and access is governed by your Git host - which is already behind your identity provider. That gives you the audit trail provisioning would have given you, from a system you already run.

What this does not include

Said plainly, so nobody discovers it in a procurement call:

No SAML or SCIM from us. Both describe a service with accounts. There is no service here to attach them to.

No admin console. No seat dashboard, no usage reporting, no revoking access remotely. Access is a Penpot team and a repository.

No hosted component registry. The kit is delivered as a file, not installed from a server we operate.

If your security review asks for a SOC 2 report or a data processing agreement covering the running product, there is no running product to cover. The questions that genuinely apply are about your Penpot instance and your Git host, and you already have answers for both.