Penpot Configuration #

This section intends to explain all available configuration options, when you are self-hosting Penpot or also if you are using the Penpot developer setup.

Penpot is configured using environment variables. All variables start with PENPOT_ prefix.

Variables are initialized in the docker-compose.yaml file, as explained in the Self-hosting guide with Elestio or Docker.

Additionally, if you are using the developer environment, you may override their values in the startup scripts, as explained in the Developer Guide.

NOTE: All the examples that have values represent the default values, and the examples that do not have values are optional, and inactive by default.

Common #

This section will list all common configuration between backend and frontend.

There are two types of configuration: options (properties that requieres some value) and flags (that just enables or disables something). All flags are set in a single PENPOT_FLAGS environment variable will have an ordered list of strings using this format: <enable|disable>-<flag-name>.

Registration #

Penpot comes with an option to completely disable the registration process or restrict it to some domains.

If you want to completelly disable registration, use the following variable in both frontend & backend:

PENPOT_FLAGS="$PENPOT_FLAGS disable-registration"

You also can restict the registrations to a closed list of domains:

# comma separated list of domains (backend only)

Demo users #

Penpot comes with facilities for fast creation of demo users without the need of a registration process. The demo users by default have an expiration time of 7 days, and once expired they are completly deleted with all the generated content. Very useful for testing or demostration purposes.

You can enable demo users using the following variable:

PENPOT_FLAGS="$PENPOT_FLAGS enable-demo-users"

They are disabled by default since 1.13.0

Authentication Providers #

For configure the authentication with third-party auth providers you will need to configure penpot and set the correct callback of your penpot instance in the auth-provider configuration.

The callback has the following format:


You will need to change <your_domain> and <oauth_provider> according to your setup. This is how it looks with Gitlab provider:


Penpot #

Consists on registration and authentication via pasword. It is enabled by default, but can be disabled with the following flags:

PENPOT_FLAGS="[...] disable-login-with-password"

And the registration also can be disabled with:

PENPOT_FLAGS="[...] disable-registration"

Google #

Allows integrating with Google as OAuth provider:

# Backend & Frontend
PENPOT_FLAGS="[...] enable-login-with-google"

# Backend only:

GitLab #

Allows integrating with GitLab as OAuth provider:

# Backend & Frontend
PENPOT_FLAGS="[...] enable-login-with-gitlab"

# Backend only

GitHub #

Allows integrating with GitHub as OAuth provider:

# Backend & Frontend
PENPOT_FLAGS="[...] enable-login-with-github"

# Backend only

OpenID Connect #

NOTE: Since version 1.5.0

Allows integrating with a generic authentication provider that implements the OIDC protocol (usually used for SSO).

All the other options are backend only:

## Frontend & Backend
PENPOT_FLAGS="[...] enable-login-with-oidc"

## Backend only

# Mainly used for auto discovery the openid endpoints

# Optional backend variables, used mainly if you want override; they are
# autodiscovered using the standard openid-connect mechanism.

# Optional list of roles that users are required to have. If no role
# is provided, roles checking disabled.
PENPOT_OIDC_ROLES="role1 role2"

# Attribute to use for lookup roles on the user object. Optional, if
# not provided, the roles checking will be disabled.

Since version 1.6.0:

# This settings allow overwrite the required scopes, use with caution
# because penpot requres at least `name` and `email` attrs found on the
# user info. Optional, defaults to `openid profile`.
PENPOT_OIDC_SCOPES="scope1 scope2"

Since version 1.12.0

# Attribute to use for lookup the name on the user object. Optional,
# if not perovided, the `name` prop will be used.

# Attribute to use for lookup the email on the user object. Optional,
# if not perovided, the `email` prop will be used.

Azure Active Directory using OpenID Connect #

Allows integrating with Azure Active Directory as authentication provider:

# Backend & Frontend

## Backend only


Penpot comes with support for Lightweight Directory Access Protocol (LDAP). This is the example configuration we use internally for testing this authentication backend.

## Backend & Frontend
PENPOT_FLAGS="$PENPOT_FLAGS enable-login-with-ldap"

## Backend only

If you miss something, please open an issue and we discuss it.

Backend #

This section enumerates the backend only configuration variables.

Database #

We only support PostgreSQL and we highly recommend >=13 version. If you are using official docker images this is already solved for you.

Essential database configuration:

# Backend

The username and password are optional.

Email (SMTP) #

By default, when no SMTP (email) is configured, the email will be printed to the console, which means that the emails will be shown in the stdout. If you have an SMTP service, uncomment the appropiate settings section in docker-compose.yml and configure those environment variables.

Setting up the default FROM and REPLY-TO:

# Backend

Enable SMTP:

# Backend
PENPOT_FLAGS="[...] enable-smtp"

Storage #

Storage refers to storage used for store the user uploaded assets.

Assets storage is implemented using "plugable" backends. Currently there are three backends available: fs and s3 (for AWS S3).

FS Backend (default) #

This is the default backend when you use the official docker images and the default configuration looks like this:

# Backend

The main downside of this backend is the hard dependency on nginx approach to serve files managed by an application (not a simple directory serving static files). But you should not worry about this unless you want to install it outside the docker container and configure the nginx yourself.

In case you want undestand how it internally works, you can take a look on the nginx configuration file used in the docker images.

AWS S3 Backend #

This backend uses AWS S3 bucket for store the user uploaded assets. For use it you should have an appropriate account on AWS cloud and have the credentials, region and the bucket.

This is how configuration looks for S3 backend:

# AWS Credentials

# Backend configuration

# Optional if you want to use it with non AWS, S3 compatible service:

Redis #

The redis configuration is very simple, just provide with a valid redis URI. Redis is used mainly for websocket notifications coordination.

# Backend

If you are using the official docker compose file, this is already configured.


You can set the port where the backend http server will listen for requests.

# Backend

Additionally, you probably will need to set the PENPOT_PUBLIC_URI environment variable in case you go to serve penpot to the users, and it should point to public URI where users will access the application:

# Backend

Frontend #

In comparison with backend, frontend only has a small number of runtime configuration options, and they are located in the <dist>/js/config.js file.

If you are using the official docker images, the best approach to set any configuration is using environment variables, and the image automatically generates the config.js from them.

NOTE: many frontend related configuration variables are explained in the Common section, this section explains frontend only options.

But in case you have a custom setup you probably need setup the following environment variables on the frontend container:

To connect the frontend to the exporter and backend, you need to fill out these environment variables.

# Frontend

These variables are used for generate correct nginx.conf file on container startup.

Demo warning #

If you want to show a warning in the register and login page saying that this is a demostration purpose instance (no backups, periodical data wipe, ...), set the following variable:

# Frontend
PENPOT_FLAGS="$PENPOT_FLAGS enable-demo-warning"

Exporter #

The exporter application only have a single configuration option and it can be provided using environment variables in the same way as backend.

# Backend & Frontend

This environment variable indicates where the exporter can access to the public frontend application (because it uses special pages from it to render the shapes in the underlying headless web browser).

Other flags #

  • enable-cors: Enables the default cors cofiguration that allows all domains (this configuration is designed only for dev purposes right now).
  • enable-backend-api-docs: Enables the /api/_doc endpoint that lists all rpc methods available on backend.
  • enable-insecure-register: Enables the insecure process of profile registrion deactivating the email verification process (only for local or internal setups).
  • enable-user-feedback: Enables the feedback form at the dashboard.
  • disable-secure-session-cookies: By default, penpot uses the secure flag on cookies, this flag disables it; it is usefull if you have plan to serve penpot under different domain than localhost without HTTPS.
  • disable-login: allows disable password based login form.
  • disable-registration: disables registration (still enabled for invitations only).
  • enable-prepl-server: enables PREPL server, used by and other additional tools for communicate internally with penpot backend.

Since version 1.13.0:

  • enable-log-invitation-tokens: for cases where you don't have email configured, this will log to console the invitation tokens.
  • enable-log-emails: if you want to log in console send emails. This only works if smtp is not configured.