Examples
Below are some sample YAML configurations demonstrating how to override some default values.
Basic
core:
+ Examples - WireGuard Portal Examples
Below are some sample YAML configurations demonstrating how to override some default values.
Basic
core:
admin_user: test@example.com
admin_password: password
admin_api_token: super-s3cr3t-api-token-or-a-UUID
diff --git a/master/documentation/configuration/overview/index.html b/master/documentation/configuration/overview/index.html
index a64e931..f53d21d 100644
--- a/master/documentation/configuration/overview/index.html
+++ b/master/documentation/configuration/overview/index.html
@@ -1,4 +1,4 @@
- Overview - WireGuard Portal Overview
This page provides an overview of all available configuration options for WireGuard Portal.
You can supply these configurations in a YAML file when starting the Portal. The path of the configuration file defaults to config/config.yaml (or config/config.yml) in the working directory of the executable.
It is possible to override the configuration filepath using the environment variable WG_PORTAL_CONFIG. For example: WG_PORTAL_CONFIG=/etc/wg-portal/config.yaml ./wg-portal.
Also, environment variable substitution in the config file is supported. Refer to the syntax.
Configuration examples are available on the Examples page.
Default configuration
core:
+ Overview - WireGuard Portal Overview
This page provides an overview of all available configuration options for WireGuard Portal.
You can supply these configurations in a YAML file when starting the Portal. The path of the configuration file defaults to config/config.yaml (or config/config.yml) in the working directory of the executable.
It is possible to override the configuration filepath using the environment variable WG_PORTAL_CONFIG. For example: WG_PORTAL_CONFIG=/etc/wg-portal/config.yaml ./wg-portal.
Also, environment variable substitution in the config file is supported. Refer to the syntax.
Configuration examples are available on the Examples page.
Default configuration
core:
admin_user: admin@wgportal.local
admin_password: wgportal-default
admin_api_token: ""
@@ -14,6 +14,7 @@
backend:
default: local
+ rekey_timeout_interval: 125s
local_resolvconf_prefix: tun.
advanced:
@@ -90,7 +91,7 @@
url: ""
authentication: ""
timeout: 10s
-
Below you will find sections like core, backend, advanced, database, statistics, mail, auth, web and webhook.
Each section describes the individual configuration keys, their default values, and a brief explanation of their purpose.
Core
These are the primary configuration options that control fundamental WireGuard Portal behavior. More advanced options are found in the subsequent Advanced section.
admin_user
- Default:
admin@wgportal.local - Environment Variable:
WG_PORTAL_CORE_ADMIN_USER - Description: The administrator user. This user will be created as a default admin if it does not yet exist.
admin_password
- Default:
wgportal-default - Environment Variable:
WG_PORTAL_CORE_ADMIN_PASSWORD - Description: The administrator password. The default password should be changed immediately!
- Important: The password should be strong and secure. The minimum password length is specified in auth.min_password_length. By default, it is 16 characters.
disable_admin_user
- Default:
false - Environment Variable:
WG_PORTAL_CORE_DISABLE_ADMIN_USER - Description: If
true, no admin user is created. This is useful if you plan to manage users exclusively through external authentication providers such as LDAP or OAuth.
admin_api_token
- Default: (empty)
- Environment Variable:
WG_PORTAL_CORE_ADMIN_API_TOKEN - Description: An API token for the admin user. If a token is provided, the REST API can be accessed using this token. If empty, the API is initially disabled for the admin user.
editable_keys
- Default:
true - Environment Variable:
WG_PORTAL_CORE_EDITABLE_KEYS - Description: Allow editing of WireGuard key-pairs directly in the UI.
create_default_peer
- Default:
false - Environment Variable:
WG_PORTAL_CORE_CREATE_DEFAULT_PEER - Description: If a user logs in for the first time with no existing peers, automatically create a new WireGuard peer for all server interfaces where the "Create default peer" flag is set.
- Important: This option is only effective for interfaces where the "Create default peer" flag is set (via the UI).
create_default_peer_on_creation
- Default:
false - Environment Variable:
WG_PORTAL_CORE_CREATE_DEFAULT_PEER_ON_CREATION - Description: If an LDAP user is created (e.g., through LDAP sync) and has no peers, automatically create a new WireGuard peer for all server interfaces where the "Create default peer" flag is set.
- Important: This option requires create_default_peer to be enabled.
re_enable_peer_after_user_enable
- Default:
true - Environment Variable:
WG_PORTAL_CORE_RE_ENABLE_PEER_AFTER_USER_ENABLE - Description: Re-enable all peers that were previously disabled if the associated user is re-enabled.
delete_peer_after_user_deleted
- Default:
false - Environment Variable:
WG_PORTAL_CORE_DELETE_PEER_AFTER_USER_DELETED - Description: If a user is deleted, remove all linked peers. Otherwise, peers remain but are disabled.
self_provisioning_allowed
- Default:
false - Environment Variable:
WG_PORTAL_CORE_SELF_PROVISIONING_ALLOWED - Description: Allow registered (non-admin) users to self-provision peers from their profile page.
import_existing
- Default:
true - Environment Variable:
WG_PORTAL_CORE_IMPORT_EXISTING - Description: On startup, import existing WireGuard interfaces and peers into WireGuard Portal.
restore_state
- Default:
true - Environment Variable:
WG_PORTAL_CORE_RESTORE_STATE - Description: Restore the WireGuard interface states (up/down) that existed before WireGuard Portal started.
Backend
Configuration options for the WireGuard backend, which manages the WireGuard interfaces and peers. The current MikroTik backend is in BETA and may not support all features.
default
- Default:
local - Description: The default backend to use for managing WireGuard interfaces. Valid options are:
local, or other backend id's configured in the mikrotik section.
local_resolvconf_prefix
- Default:
tun. - Environment Variable:
WG_PORTAL_BACKEND_LOCAL_RESOLVCONF_PREFIX - Description: Interface name prefix for WireGuard interfaces on the local system which is used to configure DNS servers with resolvconf. It depends on the resolvconf implementation you are using, most use a prefix of
tun., but some have an empty prefix (e.g., systemd).
ignored_local_interfaces
- Default: (empty)
- Environment Variable:
WG_PORTAL_BACKEND_IGNORED_LOCAL_INTERFACES (comma-separated values) - Description: A list of interface names to exclude when enumerating local interfaces. This is useful if you want to prevent certain interfaces from being imported from the local system.
Mikrotik
The mikrotik array contains a list of MikroTik backend definitions. Each entry describes how to connect to a MikroTik RouterOS instance that hosts WireGuard interfaces.
Below are the properties for each entry inside backend.mikrotik:
id
- Default: (empty)
- Description: A unique identifier for this backend. This value can be referenced by
backend.default to use this backend as default. The identifier must be unique across all backends and must not use the reserved keyword local.
display_name
- Default: (empty)
- Description: A human-friendly display name for this backend. If omitted, the
id will be used as the display name.
api_url
- Default: (empty)
- Description: Base URL of the MikroTik REST API, including scheme and path, e.g.,
https://10.10.10.10:8729/rest.
api_user
- Default: (empty)
- Description: Username for authenticating against the MikroTik API. Ensure that the user has sufficient permissions to manage WireGuard interfaces and peers.
api_password
- Default: (empty)
- Description: Password for the specified API user.
api_verify_tls
- Default:
false - Description: Whether to verify the TLS certificate of the MikroTik API endpoint. Set to
false to allow self-signed certificates (not recommended for production).
api_timeout
- Default:
30s - Description: Timeout for API requests to the MikroTik device. Uses Go duration format (e.g.,
10s, 1m). If omitted, a default of 30 seconds is used.
concurrency
- Default:
5 - Description: Maximum number of concurrent API requests the backend will issue when enumerating interfaces and their details. If
0 or negative, a sane default of 5 is used.
ignored_interfaces
- Default: (empty)
- Description: A list of interface names to exclude during interface enumeration. This is useful if you want to prevent specific interfaces from being imported from the MikroTik device.
debug
- Default:
false - Description: Enable verbose debug logging for the MikroTik backend.
For more details on configuring the MikroTik backend, see the Backends documentation.
Advanced
Additional or more specialized configuration options for logging and interface creation details.
log_level
- Default:
info - Environment Variable:
WG_PORTAL_ADVANCED_LOG_LEVEL - Description: The log level used by the application. Valid options are:
trace, debug, info, warn, error.
log_pretty
- Default:
false - Environment Variable:
WG_PORTAL_ADVANCED_LOG_PRETTY - Description: If
true, log messages are colorized and formatted for readability (pretty-print).
log_json
- Default:
false - Environment Variable:
WG_PORTAL_ADVANCED_LOG_JSON - Description: If
true, log messages are structured in JSON format.
start_listen_port
- Default:
51820 - Environment Variable:
WG_PORTAL_ADVANCED_START_LISTEN_PORT - Description: The first port to use when automatically creating new WireGuard interfaces.
start_cidr_v4
- Default:
10.11.12.0/24 - Environment Variable:
WG_PORTAL_ADVANCED_START_CIDR_V4 - Description: The initial IPv4 subnet to use when automatically creating new WireGuard interfaces.
start_cidr_v6
- Default:
fdfd:d3ad:c0de:1234::0/64 - Environment Variable:
WG_PORTAL_ADVANCED_START_CIDR_V6 - Description: The initial IPv6 subnet to use when automatically creating new WireGuard interfaces.
use_ip_v6
- Default:
true - Environment Variable:
WG_PORTAL_ADVANCED_USE_IP_V6 - Description: Enable or disable IPv6 support.
config_storage_path
- Default: (empty)
- Environment Variable:
WG_PORTAL_ADVANCED_CONFIG_STORAGE_PATH - Description: Path to a directory where
wg-quick style configuration files will be stored (if you need local filesystem configs).
expiry_check_interval
- Default:
15m - Environment Variable:
WG_PORTAL_ADVANCED_EXPIRY_CHECK_INTERVAL - Description: Interval after which existing peers are checked if they are expired. Format uses
s, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.
rule_prio_offset
- Default:
20000 - Environment Variable:
WG_PORTAL_ADVANCED_RULE_PRIO_OFFSET - Description: Offset for IP route rule priorities when configuring routing.
route_table_offset
- Default:
20000 - Environment Variable:
WG_PORTAL_ADVANCED_ROUTE_TABLE_OFFSET - Description: Offset for IP route table IDs when configuring routing.
api_admin_only
- Default:
true - Environment Variable:
WG_PORTAL_ADVANCED_API_ADMIN_ONLY - Description: If
true, the public REST API is accessible only to admin users. The API docs live at /api/v1/doc.html.
limit_additional_user_peers
- Default:
0 - Environment Variable:
WG_PORTAL_ADVANCED_LIMIT_ADDITIONAL_USER_PEERS - Description: Limit additional peers a normal user can create.
0 means unlimited.
Database
Configuration for the underlying database used by WireGuard Portal. Supported databases include SQLite, MySQL, Microsoft SQL Server, and Postgres.
If sensitive values (like private keys) should be stored in an encrypted format, set the encryption_passphrase option.
debug
- Default:
false - Environment Variable:
WG_PORTAL_DATABASE_DEBUG - Description: If
true, logs all database statements (verbose).
slow_query_threshold
- Default: "0"
- Environment Variable:
WG_PORTAL_DATABASE_SLOW_QUERY_THRESHOLD - Description: A time threshold (e.g.,
100ms) above which queries are considered slow and logged as warnings. If zero, slow query logging is disabled. Format uses s, ms for seconds, milliseconds, see time.ParseDuration. The value must be a string.
type
- Default:
sqlite - Environment Variable:
WG_PORTAL_DATABASE_TYPE - Description: The database type. Valid options:
sqlite, mssql, mysql, postgres.
dsn
- Default:
data/sqlite.db - Environment Variable:
WG_PORTAL_DATABASE_DSN - Description: The Data Source Name (DSN) for connecting to the database.
For example: user:pass@tcp(1.2.3.4:3306)/dbname?charset=utf8mb4&parseTime=True&loc=Local
+
Below you will find sections like core, backend, advanced, database, statistics, mail, auth, web and webhook.
Each section describes the individual configuration keys, their default values, and a brief explanation of their purpose.
Core
These are the primary configuration options that control fundamental WireGuard Portal behavior. More advanced options are found in the subsequent Advanced section.
admin_user
- Default:
admin@wgportal.local - Environment Variable:
WG_PORTAL_CORE_ADMIN_USER - Description: The administrator user. This user will be created as a default admin if it does not yet exist.
admin_password
- Default:
wgportal-default - Environment Variable:
WG_PORTAL_CORE_ADMIN_PASSWORD - Description: The administrator password. The default password should be changed immediately!
- Important: The password should be strong and secure. The minimum password length is specified in auth.min_password_length. By default, it is 16 characters.
disable_admin_user
- Default:
false - Environment Variable:
WG_PORTAL_CORE_DISABLE_ADMIN_USER - Description: If
true, no admin user is created. This is useful if you plan to manage users exclusively through external authentication providers such as LDAP or OAuth.
admin_api_token
- Default: (empty)
- Environment Variable:
WG_PORTAL_CORE_ADMIN_API_TOKEN - Description: An API token for the admin user. If a token is provided, the REST API can be accessed using this token. If empty, the API is initially disabled for the admin user.
editable_keys
- Default:
true - Environment Variable:
WG_PORTAL_CORE_EDITABLE_KEYS - Description: Allow editing of WireGuard key-pairs directly in the UI.
create_default_peer
- Default:
false - Environment Variable:
WG_PORTAL_CORE_CREATE_DEFAULT_PEER - Description: If a user logs in for the first time with no existing peers, automatically create a new WireGuard peer for all server interfaces where the "Create default peer" flag is set.
- Important: This option is only effective for interfaces where the "Create default peer" flag is set (via the UI).
create_default_peer_on_creation
- Default:
false - Environment Variable:
WG_PORTAL_CORE_CREATE_DEFAULT_PEER_ON_CREATION - Description: If an LDAP user is created (e.g., through LDAP sync) and has no peers, automatically create a new WireGuard peer for all server interfaces where the "Create default peer" flag is set.
- Important: This option requires create_default_peer to be enabled.
re_enable_peer_after_user_enable
- Default:
true - Environment Variable:
WG_PORTAL_CORE_RE_ENABLE_PEER_AFTER_USER_ENABLE - Description: Re-enable all peers that were previously disabled if the associated user is re-enabled.
delete_peer_after_user_deleted
- Default:
false - Environment Variable:
WG_PORTAL_CORE_DELETE_PEER_AFTER_USER_DELETED - Description: If a user is deleted, remove all linked peers. Otherwise, peers remain but are disabled.
self_provisioning_allowed
- Default:
false - Environment Variable:
WG_PORTAL_CORE_SELF_PROVISIONING_ALLOWED - Description: Allow registered (non-admin) users to self-provision peers from their profile page.
import_existing
- Default:
true - Environment Variable:
WG_PORTAL_CORE_IMPORT_EXISTING - Description: On startup, import existing WireGuard interfaces and peers into WireGuard Portal.
restore_state
- Default:
true - Environment Variable:
WG_PORTAL_CORE_RESTORE_STATE - Description: Restore the WireGuard interface states (up/down) that existed before WireGuard Portal started.
Backend
Configuration options for the WireGuard backend, which manages the WireGuard interfaces and peers. The current MikroTik backend is in BETA and may not support all features.
default
- Default:
local - Description: The default backend to use for managing WireGuard interfaces. Valid options are:
local, or other backend id's configured in the mikrotik section.
rekey_timeout_interval
- Default:
180s - Environment Variable:
WG_PORTAL_BACKEND_REKEY_TIMEOUT_INTERVAL - Description: The interval after which a WireGuard peer is considered disconnected if no handshake updates are received. This corresponds to the WireGuard rekey timeout setting of 120 seconds plus a 60-second buffer to account for latency or retry handling. Uses Go duration format (e.g.,
10s, 1m). If omitted, a default of 180 seconds is used.
local_resolvconf_prefix
- Default:
tun. - Environment Variable:
WG_PORTAL_BACKEND_LOCAL_RESOLVCONF_PREFIX - Description: Interface name prefix for WireGuard interfaces on the local system which is used to configure DNS servers with resolvconf. It depends on the resolvconf implementation you are using, most use a prefix of
tun., but some have an empty prefix (e.g., systemd).
ignored_local_interfaces
- Default: (empty)
- Environment Variable:
WG_PORTAL_BACKEND_IGNORED_LOCAL_INTERFACES (comma-separated values) - Description: A list of interface names to exclude when enumerating local interfaces. This is useful if you want to prevent certain interfaces from being imported from the local system.
Mikrotik
The mikrotik array contains a list of MikroTik backend definitions. Each entry describes how to connect to a MikroTik RouterOS instance that hosts WireGuard interfaces.
Below are the properties for each entry inside backend.mikrotik:
id
- Default: (empty)
- Description: A unique identifier for this backend. This value can be referenced by
backend.default to use this backend as default. The identifier must be unique across all backends and must not use the reserved keyword local.
display_name
- Default: (empty)
- Description: A human-friendly display name for this backend. If omitted, the
id will be used as the display name.
api_url
- Default: (empty)
- Description: Base URL of the MikroTik REST API, including scheme and path, e.g.,
https://10.10.10.10:8729/rest.
api_user
- Default: (empty)
- Description: Username for authenticating against the MikroTik API. Ensure that the user has sufficient permissions to manage WireGuard interfaces and peers.
api_password
- Default: (empty)
- Description: Password for the specified API user.
api_verify_tls
- Default:
false - Description: Whether to verify the TLS certificate of the MikroTik API endpoint. Set to
false to allow self-signed certificates (not recommended for production).
api_timeout
- Default:
30s - Description: Timeout for API requests to the MikroTik device. Uses Go duration format (e.g.,
10s, 1m). If omitted, a default of 30 seconds is used.
concurrency
- Default:
5 - Description: Maximum number of concurrent API requests the backend will issue when enumerating interfaces and their details. If
0 or negative, a sane default of 5 is used.
ignored_interfaces
- Default: (empty)
- Description: A list of interface names to exclude during interface enumeration. This is useful if you want to prevent specific interfaces from being imported from the MikroTik device.
debug
- Default:
false - Description: Enable verbose debug logging for the MikroTik backend.
For more details on configuring the MikroTik backend, see the Backends documentation.
Advanced
Additional or more specialized configuration options for logging and interface creation details.
log_level
- Default:
info - Environment Variable:
WG_PORTAL_ADVANCED_LOG_LEVEL - Description: The log level used by the application. Valid options are:
trace, debug, info, warn, error.
log_pretty
- Default:
false - Environment Variable:
WG_PORTAL_ADVANCED_LOG_PRETTY - Description: If
true, log messages are colorized and formatted for readability (pretty-print).
log_json
- Default:
false - Environment Variable:
WG_PORTAL_ADVANCED_LOG_JSON - Description: If
true, log messages are structured in JSON format.
start_listen_port
- Default:
51820 - Environment Variable:
WG_PORTAL_ADVANCED_START_LISTEN_PORT - Description: The first port to use when automatically creating new WireGuard interfaces.
start_cidr_v4
- Default:
10.11.12.0/24 - Environment Variable:
WG_PORTAL_ADVANCED_START_CIDR_V4 - Description: The initial IPv4 subnet to use when automatically creating new WireGuard interfaces.
start_cidr_v6
- Default:
fdfd:d3ad:c0de:1234::0/64 - Environment Variable:
WG_PORTAL_ADVANCED_START_CIDR_V6 - Description: The initial IPv6 subnet to use when automatically creating new WireGuard interfaces.
use_ip_v6
- Default:
true - Environment Variable:
WG_PORTAL_ADVANCED_USE_IP_V6 - Description: Enable or disable IPv6 support.
config_storage_path
- Default: (empty)
- Environment Variable:
WG_PORTAL_ADVANCED_CONFIG_STORAGE_PATH - Description: Path to a directory where
wg-quick style configuration files will be stored (if you need local filesystem configs).
expiry_check_interval
- Default:
15m - Environment Variable:
WG_PORTAL_ADVANCED_EXPIRY_CHECK_INTERVAL - Description: Interval after which existing peers are checked if they are expired. Format uses
s, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.
rule_prio_offset
- Default:
20000 - Environment Variable:
WG_PORTAL_ADVANCED_RULE_PRIO_OFFSET - Description: Offset for IP route rule priorities when configuring routing.
route_table_offset
- Default:
20000 - Environment Variable:
WG_PORTAL_ADVANCED_ROUTE_TABLE_OFFSET - Description: Offset for IP route table IDs when configuring routing.
api_admin_only
- Default:
true - Environment Variable:
WG_PORTAL_ADVANCED_API_ADMIN_ONLY - Description: If
true, the public REST API is accessible only to admin users. The API docs live at /api/v1/doc.html.
limit_additional_user_peers
- Default:
0 - Environment Variable:
WG_PORTAL_ADVANCED_LIMIT_ADDITIONAL_USER_PEERS - Description: Limit additional peers a normal user can create.
0 means unlimited.
Database
Configuration for the underlying database used by WireGuard Portal. Supported databases include SQLite, MySQL, Microsoft SQL Server, and Postgres.
If sensitive values (like private keys) should be stored in an encrypted format, set the encryption_passphrase option.
debug
- Default:
false - Environment Variable:
WG_PORTAL_DATABASE_DEBUG - Description: If
true, logs all database statements (verbose).
slow_query_threshold
- Default: "0"
- Environment Variable:
WG_PORTAL_DATABASE_SLOW_QUERY_THRESHOLD - Description: A time threshold (e.g.,
100ms) above which queries are considered slow and logged as warnings. If zero, slow query logging is disabled. Format uses s, ms for seconds, milliseconds, see time.ParseDuration. The value must be a string.
type
- Default:
sqlite - Environment Variable:
WG_PORTAL_DATABASE_TYPE - Description: The database type. Valid options:
sqlite, mssql, mysql, postgres.
dsn
- Default:
data/sqlite.db - Environment Variable:
WG_PORTAL_DATABASE_DSN - Description: The Data Source Name (DSN) for connecting to the database.
For example: user:pass@tcp(1.2.3.4:3306)/dbname?charset=utf8mb4&parseTime=True&loc=Local
encryption_passphrase
- Default: (empty)
- Environment Variable:
WG_PORTAL_DATABASE_ENCRYPTION_PASSPHRASE - Description: Passphrase for encrypting sensitive values such as private keys in the database. Encryption is only applied if this passphrase is set. Important: Once you enable encryption by setting this passphrase, you cannot disable it or change it afterward. New or updated records will be encrypted; existing data remains in plaintext until it’s next modified.
Statistics
Controls how WireGuard Portal collects and reports usage statistics, including ping checks and Prometheus metrics.
use_ping_checks
- Default:
true - Environment Variable:
WG_PORTAL_STATISTICS_USE_PING_CHECKS - Description: Enable periodic ping checks to verify that peers remain responsive.
ping_check_workers
- Default:
10 - Environment Variable:
WG_PORTAL_STATISTICS_PING_CHECK_WORKERS - Description: Number of parallel worker processes for ping checks.
ping_unprivileged
- Default:
false - Environment Variable:
WG_PORTAL_STATISTICS_PING_UNPRIVILEGED - Description: If
false, ping checks run without root privileges. This is currently considered BETA.
ping_check_interval
- Default:
1m - Environment Variable:
WG_PORTAL_STATISTICS_PING_CHECK_INTERVAL - Description: Interval between consecutive ping checks for all peers. Format uses
s, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.
data_collection_interval
- Default:
1m - Environment Variable:
WG_PORTAL_STATISTICS_DATA_COLLECTION_INTERVAL - Description: Interval between data collection cycles (bytes sent/received, handshake times, etc.). Format uses
s, m, h, d for seconds, minutes, hours, days, see time.ParseDuration.
collect_interface_data
- Default:
true - Environment Variable:
WG_PORTAL_STATISTICS_COLLECT_INTERFACE_DATA - Description: If
true, collects interface-level data (bytes in/out) for monitoring and statistics.
collect_peer_data
- Default:
true - Environment Variable:
WG_PORTAL_STATISTICS_COLLECT_PEER_DATA - Description: If
true, collects peer-level data (bytes, last handshake, endpoint, etc.).
collect_audit_data
- Default:
true - Environment Variable:
WG_PORTAL_STATISTICS_COLLECT_AUDIT_DATA - Description: If
true, logs certain portal events (such as user logins) to the database.
listening_address
- Default:
:8787 - Environment Variable:
WG_PORTAL_STATISTICS_LISTENING_ADDRESS - Description: Address and port for the integrated Prometheus metric server (e.g.,
:8787 or 127.0.0.1:8787).
Mail
Options for configuring email notifications or sending peer configurations via email. By default, emails will only be sent to peers that have a valid user record linked. To send emails to all peers that have a valid email-address as user-identifier, set allow_peer_email to true.
host
- Default:
127.0.0.1 - Environment Variable:
WG_PORTAL_MAIL_HOST - Description: Hostname or IP of the SMTP server.
port
- Default:
25 - Environment Variable:
WG_PORTAL_MAIL_PORT - Description: Port number for the SMTP server.
encryption
- Default:
none - Environment Variable:
WG_PORTAL_MAIL_ENCRYPTION - Description: SMTP encryption type. Valid values:
none, tls, starttls.
cert_validation
- Default:
true - Environment Variable:
WG_PORTAL_MAIL_CERT_VALIDATION - Description: If
true, validate the SMTP server certificate (relevant if encryption = tls).
username
- Default: (empty)
- Environment Variable:
WG_PORTAL_MAIL_USERNAME - Description: Optional SMTP username for authentication.
password
- Default: (empty)
- Environment Variable:
WG_PORTAL_MAIL_PASSWORD - Description: Optional SMTP password for authentication.
auth_type
- Default:
plain - Environment Variable:
WG_PORTAL_MAIL_AUTH_TYPE - Description: SMTP authentication type. Valid values:
plain, login, crammd5.
from
- Default:
Wireguard Portal <noreply@wireguard.local> - Environment Variable:
WG_PORTAL_MAIL_FROM - Description: The default "From" address when sending emails.
link_only
- Default:
false - Environment Variable:
WG_PORTAL_MAIL_LINK_ONLY - Description: If
true, emails only contain a link to WireGuard Portal, rather than attaching the full configuration.
allow_peer_email
- Default:
false - Environment Variable:
WG_PORTAL_MAIL_ALLOW_PEER_EMAIL - Description: If
true, and a peer has no valid user record linked, but the user-identifier of the peer is a valid email address, emails will be sent to that email address. If false, and the peer has no valid user record linked, emails will not be sent. If a peer has linked a valid user, the email address is always taken from the user record.
templates_path
- Default: (empty)
- Environment Variable:
WG_PORTAL_MAIL_TEMPLATES_PATH - Description: Path to the email template files that override embedded templates. Check usage documentation for an example.`
Auth
WireGuard Portal supports multiple authentication strategies, including OpenID Connect (oidc), OAuth (oauth), Passkeys (webauthn) and LDAP (ldap). Each can have multiple providers configured. Below are the relevant keys.
Some core authentication options are shared across all providers, while others are specific to each provider type.
min_password_length
- Default:
16 - Environment Variable:
WG_PORTAL_AUTH_MIN_PASSWORD_LENGTH - Description: Minimum password length for local authentication. This is not enforced for LDAP authentication. The default admin password strength is also enforced by this setting.
- Important: The password should be strong and secure. It is recommended to use a password with at least 16 characters, including uppercase and lowercase letters, numbers, and special characters.
hide_login_form
- Default:
false - Environment Variable:
WG_PORTAL_AUTH_HIDE_LOGIN_FORM - Description: If
true, the login form is hidden and only the OIDC, OAuth, LDAP, or WebAuthn providers are shown. This is useful if you want to enforce a specific authentication method. If no social login providers are configured, the login form is always shown, regardless of this setting. - Important: You can still access the login form by adding the
?all query parameter to the login URL (e.g. https://wg.portal/#/login?all).
OIDC
The oidc array contains a list of OpenID Connect providers. Below are the properties for each OIDC provider entry inside auth.oidc:
provider_name
- Default: (empty)
- Description: A unique name for this provider. Must not conflict with other providers.
display_name
- Default: (empty)
- Description: A user-friendly name shown on the login page (e.g., "Login with Google").
base_url
- Default: (empty)
- Description: The OIDC provider’s base URL (e.g.,
https://accounts.google.com).
client_id
- Default: (empty)
- Description: The OAuth client ID from the OIDC provider.
client_secret
- Default: (empty)
- Description: The OAuth client secret from the OIDC provider.
extra_scopes
- Default: (empty)
- Description: A list of additional OIDC scopes (e.g.,
profile, email).
allowed_domains
- Default: (empty)
- Description: A list of allowlisted domains. Only users with email addresses in these domains can log in or register. This is useful for restricting access to specific organizations or groups.
field_map
- Default: (empty)
- Description: Maps OIDC claims to WireGuard Portal user fields.
-
Available fields: user_identifier, email, firstname, lastname, phone, department, is_admin, user_groups.
Field Typical OIDC Claim Explanation user_identifiersub or preferred_usernameA unique identifier for the user. Often the OIDC sub claim is used because it’s guaranteed to be unique for the user within the IdP. Some providers also support preferred_username if it’s unique. emailemailThe user’s email address as provided by the IdP. Not always verified, depending on IdP settings. firstnamegiven_nameThe user’s first name, typically provided by the IdP in the given_name claim. lastnamefamily_nameThe user’s last (family) name, typically provided by the IdP in the family_name claim. phonephone_numberThe user’s phone number. This may require additional scopes/permissions from the IdP to access. departmentCustom claim (e.g., department) If the IdP can provide organizational data, it may store it in a custom claim. Adjust accordingly (e.g., department, org, or another attribute). is_adminCustom claim or derived role If the IdP returns a role or admin flag, you can map that to is_admin. Often this is managed through custom claims or group membership. user_groupsgroups or another custom claimA list of group memberships for the user. Some IdPs provide groups out of the box; others require custom claims or directory lookups.
admin_mapping
- Default: (empty)
- Description: WgPortal can grant a user admin rights by matching the value of the
is_admin claim against a regular expression. Alternatively, a regular expression can be used to check if a user is member of a specific group listed in the user_group claim. The regular expressions are defined in admin_value_regex and admin_group_regex. admin_value_regex: A regular expression to match the is_admin claim. By default, this expression matches the string "true" (^true$).admin_group_regex: A regular expression to match the user_groups claim. Each entry in the user_groups claim is checked against this regex.
registration_enabled
- Default:
false - Description: If
true, a new user will be created in WireGuard Portal if not already present.
log_user_info
- Default:
false - Description: If
true, OIDC user data is logged at the trace level upon login (for debugging).
log_sensitive_info
- Default:
false - Description: If
true, sensitive OIDC user data, such as tokens and raw responses, will be logged at the trace level upon login (for debugging). - Important: Keep this setting disabled in production environments! Remove logs once you finished debugging authentication issues.
OAuth
The oauth array contains a list of plain OAuth2 providers. Below are the properties for each OAuth provider entry inside auth.oauth:
provider_name
- Default: (empty)
- Description: A unique name for this provider. Must not conflict with other providers.
display_name
- Default: (empty)
- Description: A user-friendly name shown on the login page.
client_id
- Default: (empty)
- Description: The OAuth client ID for the provider.
client_secret
- Default: (empty)
- Description: The OAuth client secret for the provider.
auth_url
- Default: (empty)
- Description: URL of the authentication endpoint.
token_url
- Default: (empty)
- Description: URL of the token endpoint.
user_info_url
- Default: (empty)
- Description: URL of the user information endpoint.
scopes
- Default: (empty)
- Description: A list of OAuth scopes.
allowed_domains
- Default: (empty)
- Description: A list of allowlisted domains. Only users with email addresses in these domains can log in or register. This is useful for restricting access to specific organizations or groups.
field_map
- Default: (empty)
- Description: Maps OAuth attributes to WireGuard Portal fields.
-
Available fields: user_identifier, email, firstname, lastname, phone, department, is_admin, user_groups.
Field Typical Claim Explanation user_identifiersub or preferred_usernameA unique identifier for the user. Often the OIDC sub claim is used because it’s guaranteed to be unique for the user within the IdP. Some providers also support preferred_username if it’s unique. emailemailThe user’s email address as provided by the IdP. Not always verified, depending on IdP settings. firstnamegiven_nameThe user’s first name, typically provided by the IdP in the given_name claim. lastnamefamily_nameThe user’s last (family) name, typically provided by the IdP in the family_name claim. phonephone_numberThe user’s phone number. This may require additional scopes/permissions from the IdP to access. departmentCustom claim (e.g., department) If the IdP can provide organizational data, it may store it in a custom claim. Adjust accordingly (e.g., department, org, or another attribute). is_adminCustom claim or derived role If the IdP returns a role or admin flag, you can map that to is_admin. Often this is managed through custom claims or group membership. user_groupsgroups or another custom claimA list of group memberships for the user. Some IdPs provide groups out of the box; others require custom claims or directory lookups.
admin_mapping
- Default: (empty)
- Description: WgPortal can grant a user admin rights by matching the value of the
is_admin claim against a regular expression. Alternatively, a regular expression can be used to check if a user is member of a specific group listed in the user_group claim. The regular expressions are defined in admin_value_regex and admin_group_regex. admin_value_regex: A regular expression to match the is_admin claim. By default, this expression matches the string "true" (^true$).admin_group_regex: A regular expression to match the user_groups claim. Each entry in the user_groups claim is checked against this regex.
registration_enabled
- Default:
false - Description: If
true, new users are created automatically on successful login.
log_user_info
- Default:
false - Description: If
true, logs user info at the trace level upon login.
log_sensitive_info
- Default:
false - Description: If
true, sensitive OIDC user data, such as tokens and raw responses, will be logged at the trace level upon login (for debugging). - Important: Keep this setting disabled in production environments! Remove logs once you finished debugging authentication issues.
LDAP
The ldap array contains a list of LDAP authentication providers. Below are the properties for each LDAP provider entry inside auth.ldap:
provider_name
- Default: (empty)
- Description: A unique name for this provider. Must not conflict with other providers.
url
- Default: (empty)
- Description: The LDAP server URL (e.g.,
ldap://srv-ad01.company.local:389).
start_tls
- Default:
false - Description: If
true, use STARTTLS to secure the LDAP connection.
cert_validation
- Default:
false - Description: If
true, validate the LDAP server’s TLS certificate.
tls_certificate_path
- Default: (empty)
- Description: Path to a TLS certificate if needed for LDAP connections.
tls_key_path
- Default: (empty)
- Description: Path to the corresponding TLS certificate key.
base_dn
- Default: (empty)
- Description: The base DN for user searches (e.g.,
DC=COMPANY,DC=LOCAL).
bind_user
- Default: (empty)
- Description: The bind user for LDAP (e.g.,
company\\ldap_wireguard or ldap_wireguard@company.local).
bind_pass
- Default: (empty)
- Description: The bind password for LDAP authentication.
field_map
- Default: (empty)
-
Description: Maps LDAP attributes to WireGuard Portal fields.
- Available fields:
user_identifier, email, firstname, lastname, phone, department, memberof.
WireGuard Portal Field Typical LDAP Attribute Short Description user_identifier sAMAccountName / uid Uniquely identifies the user within the LDAP directory. email mail / userPrincipalName Stores the user's primary email address. firstname givenName Contains the user's first (given) name. lastname sn Contains the user's last (surname) name. phone telephoneNumber / mobile Holds the user's phone or mobile number. department departmentNumber / ou Specifies the department or organizational unit of the user. memberof memberOf Lists the groups and roles to which the user belongs.
login_filter
- Default: (empty)
- Description: An LDAP filter to restrict which users can log in. Use
{{login_identifier}} to insert the username. For example: (&(objectClass=organizationalPerson)(mail={{login_identifier}})(!userAccountControl:1.2.840.113556.1.4.803:=2))
- Important: The
login_filter must always be a valid LDAP filter. It should at most return one user. If the filter returns multiple or no users, the login will fail.
admin_group
- Default: (empty)
- Description: A specific LDAP group whose members are considered administrators in WireGuard Portal. For example:
CN=WireGuardAdmins,OU=Some-OU,DC=YOURDOMAIN,DC=LOCAL
sync_interval
- Default: (empty)
- Description: How frequently (in duration, e.g.
30m) to synchronize users from LDAP. Empty or 0 disables sync. Format uses s, m, h, d for seconds, minutes, hours, days, see time.ParseDuration. Only users that match the sync_filter are synchronized, if disable_missing is true, users not found in LDAP are disabled.
sync_filter
- Default: (empty)
- Description: An LDAP filter to select which users get synchronized into WireGuard Portal. For example:
(&(objectClass=organizationalPerson)(!userAccountControl:1.2.840.113556.1.4.803:=2)(mail=*))
diff --git a/master/documentation/getting-started/binaries/index.html b/master/documentation/getting-started/binaries/index.html
index 0b730be..fcb0f08 100644
--- a/master/documentation/getting-started/binaries/index.html
+++ b/master/documentation/getting-started/binaries/index.html
@@ -1,4 +1,4 @@
- Binaries - WireGuard Portal Binaries
Starting from v2, each release includes compiled binaries for supported platforms. These binary versions can be manually downloaded and installed.
Download
Make sure that you download the correct binary for your architecture. The available binaries are:
wg-portal_linux_amd64 - Linux x86_64wg-portal_linux_arm64 - Linux ARM 64-bitwg-portal_linux_arm_v7 - Linux ARM 32-bit
Released versions
To download a specific version, replace ${WG_PORTAL_VERSION} with the desired version (or set an environment variable). All official release versions can be found on the GitHub Releases Page.
With curl:
curl -L -o wg-portal https://github.com/h44z/wg-portal/releases/download/${WG_PORTAL_VERSION}/wg-portal_linux_amd64
+ Binaries - WireGuard Portal Binaries
Starting from v2, each release includes compiled binaries for supported platforms. These binary versions can be manually downloaded and installed.
Download
Make sure that you download the correct binary for your architecture. The available binaries are:
wg-portal_linux_amd64 - Linux x86_64wg-portal_linux_arm64 - Linux ARM 64-bitwg-portal_linux_arm_v7 - Linux ARM 32-bit
Released versions
To download a specific version, replace ${WG_PORTAL_VERSION} with the desired version (or set an environment variable). All official release versions can be found on the GitHub Releases Page.
With curl:
curl -L -o wg-portal https://github.com/h44z/wg-portal/releases/download/${WG_PORTAL_VERSION}/wg-portal_linux_amd64
With wget:
wget -O wg-portal https://github.com/h44z/wg-portal/releases/download/${WG_PORTAL_VERSION}/wg-portal_linux_amd64
with gh cli:
gh release download ${WG_PORTAL_VERSION} --repo h44z/wg-portal --output wg-portal --pattern '*amd64'
The downloaded file will be named wg-portal and can be moved to a directory of your choice, see Install for more information.
Unreleased versions (master branch builds)
Unreleased versions can be fetched directly from the artifacts section of the GitHub Workflow.
Install
The following command can be used to install the downloaded binary (wg-portal) to /opt/wg-portal/wg-portal. It ensures that the binary is executable.
sudo mkdir -p /opt/wg-portal
diff --git a/master/documentation/getting-started/docker/index.html b/master/documentation/getting-started/docker/index.html
index da90baf..3f9e941 100644
--- a/master/documentation/getting-started/docker/index.html
+++ b/master/documentation/getting-started/docker/index.html
@@ -1,4 +1,4 @@
- Docker - WireGuard Portal Docker
Image Usage
The WireGuard Portal Docker image is available on both Docker Hub and GitHub Container Registry. It is built on the official Alpine Linux base image and comes pre-packaged with all necessary WireGuard dependencies.
This container allows you to establish WireGuard VPN connections without relying on a host system that supports WireGuard or using the linuxserver/wireguard Docker image.
The recommended method for deploying WireGuard Portal is via Docker Compose for ease of configuration and management.
A sample docker-compose.yml (managing WireGuard interfaces directly on the host) is provided below:
---
+ Docker - WireGuard Portal Docker
Image Usage
The WireGuard Portal Docker image is available on both Docker Hub and GitHub Container Registry. It is built on the official Alpine Linux base image and comes pre-packaged with all necessary WireGuard dependencies.
This container allows you to establish WireGuard VPN connections without relying on a host system that supports WireGuard or using the linuxserver/wireguard Docker image.
The recommended method for deploying WireGuard Portal is via Docker Compose for ease of configuration and management.
A sample docker-compose.yml (managing WireGuard interfaces directly on the host) is provided below:
---
services:
wg-portal:
image: wgportal/wg-portal:v2
diff --git a/master/documentation/getting-started/helm/index.html b/master/documentation/getting-started/helm/index.html
index 10214c3..08c955b 100644
--- a/master/documentation/getting-started/helm/index.html
+++ b/master/documentation/getting-started/helm/index.html
@@ -1,2 +1,2 @@
- Helm - WireGuard Portal Helm
Installing the Chart
To install the chart with the release name wg-portal:
helm install wg-portal oci://ghcr.io/h44z/charts/wg-portal
+ Helm - WireGuard Portal Helm
Installing the Chart
To install the chart with the release name wg-portal:
helm install wg-portal oci://ghcr.io/h44z/charts/wg-portal
This command deploy wg-portal on the Kubernetes cluster in the default configuration. The Values section lists the parameters that can be configured during installation.
Values
Key Type Default Description nameOverride string ""Partially override resource names (adds suffix) fullnameOverride string ""Fully override resource names extraDeploy list []Array of extra objects to deploy with the release config.advanced tpl/object {}Advanced configuration options. config.auth tpl/object {}Auth configuration options. config.core tpl/object {}Core configuration options.
If external admins in auth are defined and there are no admin_user and admin_password defined here, the default admin account will be disabled. config.database tpl/object {}Database configuration options config.mail tpl/object {}Mail configuration options config.statistics tpl/object {}Statistics configuration options config.web tpl/object {}Web configuration options.
listening_address will be set automatically from service.web.port. external_url is required to enable ingress and certificate resources. revisionHistoryLimit string 10The number of old ReplicaSets to retain to allow rollback. workloadType string "Deployment"Workload type - Deployment or StatefulSet replicas int 1The replicas for the workload. strategy object {"type":"RollingUpdate"}Update strategy for the workload Valid values are: RollingUpdate or Recreate for Deployment, RollingUpdate or OnDelete for StatefulSet image.repository string "ghcr.io/h44z/wg-portal"Image repository image.pullPolicy string "IfNotPresent"Image pull policy image.tag string ""Overrides the image tag whose default is the chart appVersion imagePullSecrets list []Image pull secrets podAnnotations tpl/object {}Extra annotations to add to the pod podLabels object {}Extra labels to add to the pod podSecurityContext object {}Pod Security Context securityContext.capabilities.add list ["NET_ADMIN"]Add capabilities to the container initContainers tpl/list []Pod init containers sidecarContainers tpl/list []Pod sidecar containers dnsPolicy string "ClusterFirst"Set DNS policy for the pod. Valid values are ClusterFirstWithHostNet, ClusterFirst, Default or None. restartPolicy string "Always"Restart policy for all containers within the pod. Valid values are Always, OnFailure or Never. hostNetwork string false.Use the host's network namespace. resources object {}Resources requests and limits command list []Overwrite pod command args list []Additional pod arguments env tpl/list []Additional environment variables envFrom tpl/list []Additional environment variables from a secret or configMap livenessProbe object {}Liveness probe configuration readinessProbe object {}Readiness probe configuration startupProbe object {}Startup probe configuration volumes tpl/list []Additional volumes volumeMounts tpl/list []Additional volumeMounts nodeSelector object {"kubernetes.io/os":"linux"}Node Selector configuration tolerations list []Tolerations configuration affinity object {}Affinity configuration service.mixed.enabled bool falseWhether to create a single service for the web and wireguard interfaces service.mixed.type string "LoadBalancer"Service type service.web.annotations object {}Annotations for the web service service.web.type string "ClusterIP"Web service type service.web.port int 8888Web service port Used for the web interface listener service.web.appProtocol string "http"Web service appProtocol. Will be auto set to https if certificate is enabled. service.web.extraSelectorLabels object {}Extra labels to append to the selector labels. service.wireguard.annotations object {}Annotations for the WireGuard service service.wireguard.type string "LoadBalancer"Wireguard service type service.wireguard.ports list [51820]Wireguard service ports. Exposes the WireGuard ports for created interfaces. Lowerest port is selected as start port for the first interface. Increment next port by 1 for each additional interface. service.wireguard.extraSelectorLabels object {}Extra labels to append to the selector labels. service.metrics.port int 8787 ingress.enabled bool falseSpecifies whether an ingress resource should be created ingress.className string ""Ingress class name ingress.pathType string "ImplementationSpecific"Ingress pathType value. Valid values are ImplementationSpecific, Exact or Prefix. ingress.annotations object {}Ingress annotations ingress.tls bool falseIngress TLS configuration. Enable certificate resource or add ingress annotation to create required secret certificate.enabled bool falseSpecifies whether a certificate resource should be created. If enabled, certificate will be used for the web. certificate.issuer.name string ""Certificate issuer name certificate.issuer.kind string ""Certificate issuer kind (ClusterIssuer or Issuer) certificate.issuer.group string "cert-manager.io"Certificate issuer group certificate.duration string ""Optional. Documentation certificate.renewBefore string ""Optional. Documentation certificate.commonName string ""Optional. Documentation certificate.emailAddresses list []Optional. Documentation certificate.ipAddresses list []Optional. Documentation certificate.keystores object {}Optional. Documentation certificate.privateKey object {}Optional. Documentation certificate.secretTemplate object {}Optional. Documentation certificate.subject object {}Optional. Documentation certificate.uris list []Optional. Documentation certificate.usages list []Optional. Documentation persistence.enabled bool falseSpecifies whether an persistent volume should be created persistence.annotations object {}Persistent Volume Claim annotations persistence.storageClass string ""Persistent Volume storage class. If undefined (the default) cluster's default provisioner will be used. persistence.accessMode string "ReadWriteOnce"Persistent Volume Access Mode persistence.size string "1Gi"Persistent Volume size persistence.volumeName string ""Persistent Volume Name (optional) serviceAccount.create bool trueSpecifies whether a service account should be created serviceAccount.annotations object {}Service account annotations serviceAccount.automount bool falseAutomatically mount a ServiceAccount's API credentials serviceAccount.name string ""The name of the service account to use. If not set and create is true, a name is generated using the fullname template monitoring.enabled bool falseEnable Prometheus monitoring. monitoring.apiVersion string "monitoring.coreos.com/v1"API version of the Prometheus resource. Use azmonitoring.coreos.com/v1 for Azure Managed Prometheus. monitoring.kind string "PodMonitor"Kind of the Prometheus resource. Could be PodMonitor or ServiceMonitor. monitoring.labels object {}Resource labels. monitoring.annotations object {}Resource annotations. monitoring.interval string 1mInterval at which metrics should be scraped. If not specified config.statistics.data_collection_interval interval is used. monitoring.metricRelabelings list []Relabelings to samples before ingestion. monitoring.relabelings list []Relabelings to samples before scraping. monitoring.scrapeTimeout string ""Timeout after which the scrape is ended If not specified, the Prometheus global scrape interval is used. monitoring.jobLabel string ""The label to use to retrieve the job name from. monitoring.podTargetLabels object {}Transfers labels on the Kubernetes Pod onto the target. monitoring.dashboard.enabled bool falseEnable Grafana dashboard. monitoring.dashboard.annotations object {}Annotations for the dashboard ConfigMap. monitoring.dashboard.labels object {}Additional labels for the dashboard ConfigMap. monitoring.dashboard.namespace string ""Dashboard ConfigMap namespace Overrides the namespace for the dashboard ConfigMap.
\ No newline at end of file
diff --git a/master/documentation/getting-started/reverse-proxy/index.html b/master/documentation/getting-started/reverse-proxy/index.html
index 5b0dc40..6e99f49 100644
--- a/master/documentation/getting-started/reverse-proxy/index.html
+++ b/master/documentation/getting-started/reverse-proxy/index.html
@@ -1,4 +1,4 @@
- Reverse Proxy (HTTPS) - WireGuard Portal Reverse Proxy (HTTPS)
Reverse Proxy for HTTPS
For production deployments, always serve the WireGuard Portal over HTTPS. You have two options to secure your connection:
Reverse Proxy
Let a front‐end proxy handle HTTPS for you. This also frees you from managing certificates manually and is therefore the preferred option. You can use Nginx, Traefik, Caddy or any other proxy.
Below is an example using a Docker Compose stack with Traefik. It exposes the WireGuard Portal on https://wg.domain.com and redirects initial HTTP traffic to HTTPS.
services:
+ Reverse Proxy (HTTPS) - WireGuard Portal Reverse Proxy (HTTPS)
Reverse Proxy for HTTPS
For production deployments, always serve the WireGuard Portal over HTTPS. You have two options to secure your connection:
Reverse Proxy
Let a front‐end proxy handle HTTPS for you. This also frees you from managing certificates manually and is therefore the preferred option. You can use Nginx, Traefik, Caddy or any other proxy.
Below is an example using a Docker Compose stack with Traefik. It exposes the WireGuard Portal on https://wg.domain.com and redirects initial HTTP traffic to HTTPS.
services:
reverse-proxy:
image: traefik:v3.3
restart: unless-stopped
diff --git a/master/documentation/getting-started/sources/index.html b/master/documentation/getting-started/sources/index.html
index d60f850..a6b12fe 100644
--- a/master/documentation/getting-started/sources/index.html
+++ b/master/documentation/getting-started/sources/index.html
@@ -1,4 +1,4 @@
- Sources - WireGuard Portal Sources
To build the application from source files, use the Makefile provided in the repository.
Requirements
- Git
- Make
- Go:
>=1.25.0 - Node.js with npm:
node>=18, npm>=9
Build
# Get source code
+ Sources - WireGuard Portal Sources
To build the application from source files, use the Makefile provided in the repository.
Requirements
- Git
- Make
- Go:
>=1.25.0 - Node.js with npm:
node>=18, npm>=9
Build
# Get source code
git clone https://github.com/h44z/wg-portal -b ${WG_PORTAL_VERSION:-master} --depth 1
cd wg-portal
# Build the frontend
diff --git a/master/documentation/monitoring/prometheus/index.html b/master/documentation/monitoring/prometheus/index.html
index 7328ad6..a6c13b1 100644
--- a/master/documentation/monitoring/prometheus/index.html
+++ b/master/documentation/monitoring/prometheus/index.html
@@ -1,4 +1,4 @@
- Monitoring - WireGuard Portal By default, WG-Portal exposes Prometheus metrics on port 8787 if interface/peer statistic data collection is enabled.
Exposed Metrics
Metric Type Description wireguard_interface_received_bytes_totalgauge Bytes received through the interface. wireguard_interface_sent_bytes_totalgauge Bytes sent through the interface. wireguard_peer_last_handshake_secondsgauge Seconds from the last handshake with the peer. wireguard_peer_received_bytes_totalgauge Bytes received from the peer. wireguard_peer_sent_bytes_totalgauge Bytes sent to the peer. wireguard_peer_upgauge Peer connection state (boolean: 1/0).
Prometheus Config
Add the following scrape job to your Prometheus config file:
# prometheus.yaml
+ Monitoring - WireGuard Portal By default, WG-Portal exposes Prometheus metrics on port 8787 if interface/peer statistic data collection is enabled.
Exposed Metrics
Metric Type Description wireguard_interface_received_bytes_totalgauge Bytes received through the interface. wireguard_interface_sent_bytes_totalgauge Bytes sent through the interface. wireguard_peer_last_handshake_secondsgauge Seconds from the last handshake with the peer. wireguard_peer_received_bytes_totalgauge Bytes received from the peer. wireguard_peer_sent_bytes_totalgauge Bytes sent to the peer. wireguard_peer_upgauge Peer connection state (boolean: 1/0).
Prometheus Config
Add the following scrape job to your Prometheus config file:
# prometheus.yaml
scrape_configs:
- job_name: wg-portal
scrape_interval: 60s
diff --git a/master/documentation/overview/index.html b/master/documentation/overview/index.html
index aa09adc..cf4d104 100644
--- a/master/documentation/overview/index.html
+++ b/master/documentation/overview/index.html
@@ -1 +1 @@
- Overview - WireGuard Portal Overview
WireGuard Portal is a simple, web-based configuration portal for WireGuard server management. The portal uses the WireGuard wgctrl library to manage existing VPN interfaces. This allows for the seamless activation or deactivation of new users without disturbing existing VPN connections.
The configuration portal supports using a database (SQLite, MySQL, MsSQL, or Postgres), OAuth or LDAP (Active Directory or OpenLDAP) as a user source for authentication and profile data.
Features
- Self-hosted - the whole application is a single binary
- Responsive multi-language web UI with dark-mode written in Vue.js
- Automatically selects IP from the network pool assigned to the client
- QR-Code for convenient mobile client configuration
- Sends email to the client with QR-code and client config
- Enable / Disable clients seamlessly
- Generation of wg-quick configuration file (
wgX.conf) if required - User authentication (database, OAuth, or LDAP), Passkey support
- IPv6 ready
- Docker ready
- Can be used with existing WireGuard setups
- Support for multiple WireGuard interfaces
- Supports multiple WireGuard backends (wgctrl, MikroTik, or pfSense)
- Peer Expiry Feature
- Handles route and DNS settings like wg-quick does
- Exposes Prometheus metrics for monitoring and alerting
- REST API for management and client deployment
- Webhook for custom actions on peer, interface, or user updates
\ No newline at end of file
+ Overview - WireGuard Portal Overview
WireGuard Portal is a simple, web-based configuration portal for WireGuard server management. The portal uses the WireGuard wgctrl library to manage existing VPN interfaces. This allows for the seamless activation or deactivation of new users without disturbing existing VPN connections.
The configuration portal supports using a database (SQLite, MySQL, MsSQL, or Postgres), OAuth or LDAP (Active Directory or OpenLDAP) as a user source for authentication and profile data.
Features
- Self-hosted - the whole application is a single binary
- Responsive multi-language web UI with dark-mode written in Vue.js
- Automatically selects IP from the network pool assigned to the client
- QR-Code for convenient mobile client configuration
- Sends email to the client with QR-code and client config
- Enable / Disable clients seamlessly
- Generation of wg-quick configuration file (
wgX.conf) if required - User authentication (database, OAuth, or LDAP), Passkey support
- IPv6 ready
- Docker ready
- Can be used with existing WireGuard setups
- Support for multiple WireGuard interfaces
- Supports multiple WireGuard backends (wgctrl, MikroTik, or pfSense)
- Peer Expiry Feature
- Handles route and DNS settings like wg-quick does
- Exposes Prometheus metrics for monitoring and alerting
- REST API for management and client deployment
- Webhook for custom actions on peer, interface, or user updates
\ No newline at end of file
diff --git a/master/documentation/rest-api/api-doc/index.html b/master/documentation/rest-api/api-doc/index.html
index 2098fee..7e00641 100644
--- a/master/documentation/rest-api/api-doc/index.html
+++ b/master/documentation/rest-api/api-doc/index.html
@@ -1,5 +1,5 @@
- REST API - WireGuard Portal REST API
REST API
Upgrade
Major upgrades between different versions may require special procedures, which are described in the following sections.
Upgrade from v1 to v2
Before upgrading from V1, make sure that you have a backup of your currently working configuration files and database!
To start the upgrade process, start the wg-portal binary with the -migrateFrom parameter. The configuration (config.yaml) for WireGuard Portal must be updated and valid before starting the upgrade.
To upgrade from a previous SQLite database, start wg-portal like:
./wg-portal-amd64 -migrateFrom=old_wg_portal.db
+ Upgrade - WireGuard Portal Upgrade
Major upgrades between different versions may require special procedures, which are described in the following sections.
Upgrade from v1 to v2
Before upgrading from V1, make sure that you have a backup of your currently working configuration files and database!
To start the upgrade process, start the wg-portal binary with the -migrateFrom parameter. The configuration (config.yaml) for WireGuard Portal must be updated and valid before starting the upgrade.
To upgrade from a previous SQLite database, start wg-portal like:
./wg-portal-amd64 -migrateFrom=old_wg_portal.db
You can also specify the database type using the parameter -migrateFromType. Supported database types: mysql, mssql, postgres or sqlite.
For example:
./wg-portal-amd64 -migrateFromType=mysql -migrateFrom='user:pass@tcp(1.2.3.4:3306)/dbname?charset=utf8mb4&parseTime=True&loc=Local'
The upgrade will transform the old, existing database and store the values in the new database specified in the config.yaml configuration file. Ensure that the new database does not contain any data!
If you are using Docker, you can adapt the docker-compose.yml file to start the upgrade process:
services:
wg-portal:
diff --git a/master/documentation/usage/authentication/index.html b/master/documentation/usage/authentication/index.html
index cd80c11..bf43141 100644
--- a/master/documentation/usage/authentication/index.html
+++ b/master/documentation/usage/authentication/index.html
@@ -1,4 +1,4 @@
- Authentication - WireGuard Portal Authentication
WireGuard Portal supports multiple authentication mechanisms to manage user access. This includes
- Local user accounts
- LDAP authentication
- OAuth2 and OIDC authentication
- Passkey authentication (WebAuthn)
Users can have two roles which limit their permissions in WireGuard Portal:
- User: Can manage their own account and peers.
- Admin: Can manage all users and peers, including the ability to manage WireGuard interfaces.
In general, each user is identified by a unique identifier. If the same user identifier exists across multiple authentication sources, WireGuard Portal automatically merges those accounts into a single user record. When a user is associated with multiple authentication sources, their information in WireGuard Portal is updated based on the most recently logged-in source. For more details, see User Synchronization documentation.
Password Authentication
WireGuard Portal supports username and password authentication for both local and LDAP-backed accounts. Local users are stored in the database, while LDAP users are authenticated against an external LDAP server.
On initial startup, WireGuard Portal automatically creates a local admin account with the password wgportal-default.
This password must be changed immediately after the first login.
The minimum password length for all local users can be configured in the auth section of the configuration file. The default value is 16 characters, see min_password_length. The minimum password length is also enforced for the default admin user.
Passkey (WebAuthn) Authentication
Besides the standard authentication mechanisms, WireGuard Portal supports Passkey authentication. This feature is enabled by default and can be configured in the webauthn section of the configuration file.
Users can register multiple Passkeys to their account. These Passkeys can be used to log in to the web UI as long as the user is not locked.
Passkey authentication does not disable password authentication. The password can still be used to log in (e.g., as a fallback).
To register a Passkey, open the settings page (1) in the web UI and click on the "Register Passkey" (2) button.
OAuth2 and OIDC Authentication
WireGuard Portal supports OAuth2 and OIDC authentication. You can use any OAuth2 or OIDC provider that supports the authorization code flow, such as Google, GitHub, or Keycloak.
For OAuth2 or OIDC to work, you need to configure the external_url property in the web section of the configuration file. If you are planning to expose the portal to the internet, make sure that the external_url is configured to use HTTPS.
To add OIDC or OAuth2 authentication to WireGuard Portal, create a Client-ID and Client-Secret in your OAuth2 provider and configure a new authentication provider in the auth section of the configuration file. Make sure that each configured provider has a unique provider_name property set. Samples can be seen here.
Limiting Login to Specific Domains
You can limit the login to specific domains by setting the allowed_domains property for OAuth2 or OIDC providers. This property is a comma-separated list of domains that are allowed to log in. The user's email address is checked against this list. For example, if you want to allow only users with an email address ending in outlook.com to log in, set the property as follows:
auth:
+ Authentication - WireGuard Portal Authentication
WireGuard Portal supports multiple authentication mechanisms to manage user access. This includes
- Local user accounts
- LDAP authentication
- OAuth2 and OIDC authentication
- Passkey authentication (WebAuthn)
Users can have two roles which limit their permissions in WireGuard Portal:
- User: Can manage their own account and peers.
- Admin: Can manage all users and peers, including the ability to manage WireGuard interfaces.
In general, each user is identified by a unique identifier. If the same user identifier exists across multiple authentication sources, WireGuard Portal automatically merges those accounts into a single user record. When a user is associated with multiple authentication sources, their information in WireGuard Portal is updated based on the most recently logged-in source. For more details, see User Synchronization documentation.
Password Authentication
WireGuard Portal supports username and password authentication for both local and LDAP-backed accounts. Local users are stored in the database, while LDAP users are authenticated against an external LDAP server.
On initial startup, WireGuard Portal automatically creates a local admin account with the password wgportal-default.
This password must be changed immediately after the first login.
The minimum password length for all local users can be configured in the auth section of the configuration file. The default value is 16 characters, see min_password_length. The minimum password length is also enforced for the default admin user.
Passkey (WebAuthn) Authentication
Besides the standard authentication mechanisms, WireGuard Portal supports Passkey authentication. This feature is enabled by default and can be configured in the webauthn section of the configuration file.
Users can register multiple Passkeys to their account. These Passkeys can be used to log in to the web UI as long as the user is not locked.
Passkey authentication does not disable password authentication. The password can still be used to log in (e.g., as a fallback).
To register a Passkey, open the settings page (1) in the web UI and click on the "Register Passkey" (2) button.
OAuth2 and OIDC Authentication
WireGuard Portal supports OAuth2 and OIDC authentication. You can use any OAuth2 or OIDC provider that supports the authorization code flow, such as Google, GitHub, or Keycloak.
For OAuth2 or OIDC to work, you need to configure the external_url property in the web section of the configuration file. If you are planning to expose the portal to the internet, make sure that the external_url is configured to use HTTPS.
To add OIDC or OAuth2 authentication to WireGuard Portal, create a Client-ID and Client-Secret in your OAuth2 provider and configure a new authentication provider in the auth section of the configuration file. Make sure that each configured provider has a unique provider_name property set. Samples can be seen here.
Limiting Login to Specific Domains
You can limit the login to specific domains by setting the allowed_domains property for OAuth2 or OIDC providers. This property is a comma-separated list of domains that are allowed to log in. The user's email address is checked against this list. For example, if you want to allow only users with an email address ending in outlook.com to log in, set the property as follows:
auth:
oidc:
- provider_name: "oidc1"
# ... other settings
diff --git a/master/documentation/usage/backends/index.html b/master/documentation/usage/backends/index.html
index fde3dd4..bd61580 100644
--- a/master/documentation/usage/backends/index.html
+++ b/master/documentation/usage/backends/index.html
@@ -1,4 +1,4 @@
- Backends - WireGuard Portal Backends
WireGuard Portal can manage WireGuard interfaces and peers on different backends. Each backend represents a system where interfaces actually live. You can register multiple backends and choose which one to use per interface. A global default backend determines where newly created interfaces go (unless you explicitly choose another in the UI).
Supported backends: - Local (default): Manages interfaces on the host running WireGuard Portal (Linux WireGuard via wgctrl). Use this when the portal should directly configure wg devices on the same server. - MikroTik RouterOS (beta): Manages interfaces and peers on MikroTik devices via the RouterOS REST API. Use this to control WG interfaces on RouterOS v7+. - pfSense (alpha): Manages interfaces and peers on pfSense firewalls via the pfSense REST API.
How backend selection works: - The default backend is configured at backend.default (local or the id of a defined MikroTik backend). New interfaces created in the UI will use this backend by default. - Each interface stores its backend. You can select a different backend when creating a new interface.
Configuring MikroTik backends (RouterOS v7+)
The MikroTik backend is currently marked beta. While basic functionality is implemented, some advanced features are not yet implemented or contain bugs. Please test carefully before using in production.
The MikroTik backend uses the REST API under a base URL ending with /rest. You can register one or more MikroTik devices as backends for a single WireGuard Portal instance.
Prerequisites on MikroTik:
- RouterOS v7 with WireGuard support.
- REST API enabled and reachable over HTTP(S). A typical base URL is https://
:8729/rest or https:///rest depending on your service setup. - A dedicated RouterOS user with the following group permissions:
- api (for logging in via REST API)
- rest-api (for logging in via REST API)
- read (to read interface and peer data)
- write (to create/update interfaces and peers)
- test (to perform ping checks)
- sensitive (to read private keys)
- TLS certificate on the device is recommended. If you use a self-signed certificate during testing, set
api_verify_tls: false in wg-portal (not recommended for production).
Example WireGuard Portal configuration (config/config.yaml):
backend:
+ Backends - WireGuard Portal Backends
WireGuard Portal can manage WireGuard interfaces and peers on different backends. Each backend represents a system where interfaces actually live. You can register multiple backends and choose which one to use per interface. A global default backend determines where newly created interfaces go (unless you explicitly choose another in the UI).
Supported backends: - Local (default): Manages interfaces on the host running WireGuard Portal (Linux WireGuard via wgctrl). Use this when the portal should directly configure wg devices on the same server. - MikroTik RouterOS (beta): Manages interfaces and peers on MikroTik devices via the RouterOS REST API. Use this to control WG interfaces on RouterOS v7+. - pfSense (alpha): Manages interfaces and peers on pfSense firewalls via the pfSense REST API.
How backend selection works: - The default backend is configured at backend.default (local or the id of a defined MikroTik backend). New interfaces created in the UI will use this backend by default. - Each interface stores its backend. You can select a different backend when creating a new interface.
Configuring MikroTik backends (RouterOS v7+)
The MikroTik backend is currently marked beta. While basic functionality is implemented, some advanced features are not yet implemented or contain bugs. Please test carefully before using in production.
The MikroTik backend uses the REST API under a base URL ending with /rest. You can register one or more MikroTik devices as backends for a single WireGuard Portal instance.
Prerequisites on MikroTik:
- RouterOS v7 with WireGuard support.
- REST API enabled and reachable over HTTP(S). A typical base URL is https://
:8729/rest or https:///rest depending on your service setup. - A dedicated RouterOS user with the following group permissions:
- api (for logging in via REST API)
- rest-api (for logging in via REST API)
- read (to read interface and peer data)
- write (to create/update interfaces and peers)
- test (to perform ping checks)
- sensitive (to read private keys)
- TLS certificate on the device is recommended. If you use a self-signed certificate during testing, set
api_verify_tls: false in wg-portal (not recommended for production).
Example WireGuard Portal configuration (config/config.yaml):
backend:
# default backend decides where new interfaces are created
default: mikrotik-prod
diff --git a/master/documentation/usage/general/index.html b/master/documentation/usage/general/index.html
index faa4992..3bb613b 100644
--- a/master/documentation/usage/general/index.html
+++ b/master/documentation/usage/general/index.html
@@ -1,2 +1,2 @@
- General - WireGuard Portal General
This documentation section describes the general usage of WireGuard Portal. If you are looking for specific setup instructions, please refer to the Getting Started and Configuration sections, for example, using a Docker deployment.
Basic Concepts
WireGuard Portal is a web-based configuration portal for WireGuard server management. It allows managing multiple WireGuard interfaces and users from a single web UI. WireGuard Interfaces can be categorized into three types:
- Server: A WireGuard server interface that to which multiple peers can connect. In this mode, it is possible to specify default settings for all peers, such as the IP address range, DNS servers, and MTU size.
- Client: A WireGuard client interface that can be used to connect to a WireGuard server. Usually, such an interface has exactly one peer.
- Unknown: This is the default type for imported interfaces. It is encouraged to change the type to either
Server or Client after importing the interface.
Accessing the Web UI
The web UI should be accessed via the URL specified in the external_url property of the configuration file. By default, WireGuard Portal listens on port 8888 for HTTP connections. Check the Security or Authentication sections for more information on securing the web UI.
So the default URL to access the web UI is:
http://localhost:8888
+ General - WireGuard Portal General
This documentation section describes the general usage of WireGuard Portal. If you are looking for specific setup instructions, please refer to the Getting Started and Configuration sections, for example, using a Docker deployment.
Basic Concepts
WireGuard Portal is a web-based configuration portal for WireGuard server management. It allows managing multiple WireGuard interfaces and users from a single web UI. WireGuard Interfaces can be categorized into three types:
- Server: A WireGuard server interface that to which multiple peers can connect. In this mode, it is possible to specify default settings for all peers, such as the IP address range, DNS servers, and MTU size.
- Client: A WireGuard client interface that can be used to connect to a WireGuard server. Usually, such an interface has exactly one peer.
- Unknown: This is the default type for imported interfaces. It is encouraged to change the type to either
Server or Client after importing the interface.
Accessing the Web UI
The web UI should be accessed via the URL specified in the external_url property of the configuration file. By default, WireGuard Portal listens on port 8888 for HTTP connections. Check the Security or Authentication sections for more information on securing the web UI.
So the default URL to access the web UI is:
http://localhost:8888
A freshly set-up WireGuard Portal instance will have a default admin user with the username admin@wgportal.local and the password wgportal-default. You can and should override the default credentials in the configuration file. Make sure to change the default password immediately after the first login!
Basic UI Description
As seen in the screenshot above, the web UI is divided into several sections which are accessible via the navigation bar on the top of the screen.
- Home: The landing page of WireGuard Portal. It provides a staring point for the user to access the different sections of the web UI. It also provides quick links to WireGuard Client downloads or official documentation.
- Interfaces: This section allows you to manage the WireGuard interfaces. You can add, edit, or delete interfaces, as well as view their status and statistics. Peers for each interface can be managed here as well.
- Users: This section allows you to manage the users of WireGuard Portal. You can add, edit, or delete users, as well as view their status and statistics.
- Key Generator: This section allows you to generate WireGuard keys locally on your browser. The generated keys are never sent to the server. This is useful if you want to generate keys for a new peer without having to store the private keys in the database.
- Profile / Settings: This section allows you to access your own profile page, settings, and audit logs.
Interface View
The interface view provides an overview of the WireGuard interfaces and peers configured in WireGuard Portal.
The most important elements are:
- Interface Selector: This dropdown allows you to select the WireGuard interface you want to manage. All further actions will be performed on the selected interface.
- Create new Interface: This button allows you to create a new WireGuard interface.
- Interface Overview: This section provides an overview of the selected WireGuard interface. It shows the interface type, number of peers, and other important information.
- List of Peers: This section provides a list of all peers associated with the selected WireGuard interface. You can view, add, edit, or delete peers from this list.
- Add new Peer: This button allows you to add a new peer to the selected WireGuard interface.
- Add multiple Peers: This button allows you to add multiple peers to the selected WireGuard interface. This is useful if you want to add a large number of peers at once.
\ No newline at end of file
diff --git a/master/documentation/usage/mail-templates/index.html b/master/documentation/usage/mail-templates/index.html
index e2feee3..a224590 100644
--- a/master/documentation/usage/mail-templates/index.html
+++ b/master/documentation/usage/mail-templates/index.html
@@ -1,4 +1,4 @@
- Mail Templates - WireGuard Portal Mail Templates
WireGuard Portal sends emails when you share a configuration with a user. By default, the application uses embedded templates. You can fully customize these emails by pointing the Portal to a folder containing your own templates. If the folder is empty on startup, the default embedded templates are written there to get you started.
Configuration
To enable custom templates, set the mail.templates_path option in the application configuration file or the WG_PORTAL_MAIL_TEMPLATES_PATH environment variable to a valid folder path.
For example:
mail:
+ Mail Templates - WireGuard Portal Mail Templates
WireGuard Portal sends emails when you share a configuration with a user. By default, the application uses embedded templates. You can fully customize these emails by pointing the Portal to a folder containing your own templates. If the folder is empty on startup, the default embedded templates are written there to get you started.
Configuration
To enable custom templates, set the mail.templates_path option in the application configuration file or the WG_PORTAL_MAIL_TEMPLATES_PATH environment variable to a valid folder path.
For example:
mail:
# ... other mail options ...
# Path where custom email templates (.gotpl and .gohtml) are stored.
# If the directory is empty on startup, the default embedded templates
diff --git a/master/documentation/usage/security/index.html b/master/documentation/usage/security/index.html
index ab5298c..8d3504c 100644
--- a/master/documentation/usage/security/index.html
+++ b/master/documentation/usage/security/index.html
@@ -1 +1 @@
- Security - WireGuard Portal Security
This section describes the security features available to administrators for hardening WireGuard Portal and protecting its data.
Database Encryption
WireGuard Portal supports multiple database backends. To reduce the risk of data exposure, sensitive information stored in the database can be encrypted. To enable encryption, set the encryption_passphrase in the database configuration section.
Important: Once encryption is enabled, it cannot be disabled, and the passphrase cannot be changed! Only new or updated records will be encrypted; existing data remains in plaintext until it’s next modified.
UI and API Access
WireGuard Portal provides a web UI and a REST API for user interaction. It is important to secure these interfaces to prevent unauthorized access and data breaches.
HTTPS
It is recommended to use HTTPS for all communication with the portal to prevent eavesdropping.
Event though, WireGuard Portal supports HTTPS out of the box, it is recommended to use a reverse proxy like Nginx or Traefik to handle SSL termination and other security features. A detailed explanation is available in the Reverse Proxy section.
Secure Authentication
To prevent unauthorized access, WireGuard Portal supports integrating with secure authentication providers such as LDAP, OAuth2, or Passkeys, see Authentication for more details. When possible, use centralized authentication and enforce multi-factor authentication (MFA) at the provider level for enhanced account security. For local accounts, administrators should enforce strong password requirements.
\ No newline at end of file
+ Security - WireGuard Portal Security
This section describes the security features available to administrators for hardening WireGuard Portal and protecting its data.
Database Encryption
WireGuard Portal supports multiple database backends. To reduce the risk of data exposure, sensitive information stored in the database can be encrypted. To enable encryption, set the encryption_passphrase in the database configuration section.
Important: Once encryption is enabled, it cannot be disabled, and the passphrase cannot be changed! Only new or updated records will be encrypted; existing data remains in plaintext until it’s next modified.
UI and API Access
WireGuard Portal provides a web UI and a REST API for user interaction. It is important to secure these interfaces to prevent unauthorized access and data breaches.
HTTPS
It is recommended to use HTTPS for all communication with the portal to prevent eavesdropping.
Event though, WireGuard Portal supports HTTPS out of the box, it is recommended to use a reverse proxy like Nginx or Traefik to handle SSL termination and other security features. A detailed explanation is available in the Reverse Proxy section.
Secure Authentication
To prevent unauthorized access, WireGuard Portal supports integrating with secure authentication providers such as LDAP, OAuth2, or Passkeys, see Authentication for more details. When possible, use centralized authentication and enforce multi-factor authentication (MFA) at the provider level for enhanced account security. For local accounts, administrators should enforce strong password requirements.
\ No newline at end of file
diff --git a/master/documentation/usage/user-sync/index.html b/master/documentation/usage/user-sync/index.html
index c4dcfeb..3e520eb 100644
--- a/master/documentation/usage/user-sync/index.html
+++ b/master/documentation/usage/user-sync/index.html
@@ -1,4 +1,4 @@
- User Management - WireGuard Portal User Management
For all external authentication providers (LDAP, OIDC, OAuth2), WireGuard Portal can automatically create a local user record upon the user's first successful login. This behavior is controlled by the registration_enabled setting in each authentication provider's configuration.
User information from external authentication sources is merged into the corresponding local WireGuard Portal user record whenever the user logs in. Additionally, WireGuard Portal supports periodic synchronization of user data from an LDAP directory.
To prevent overwriting local changes, WireGuard Portal allows you to set a per-user flag that disables synchronization of external attributes. When this flag is set, the user in WireGuard Portal will not be updated automatically during log-ins or LDAP synchronization.
LDAP Synchronization
WireGuard Portal lets you hook up any LDAP server such as Active Directory or OpenLDAP for both authentication and user sync. You can even register multiple LDAP servers side-by-side. Details on the log-in process can be found in the LDAP Authentication section.
If you enable LDAP synchronization, all users within the LDAP directory will be created automatically in the WireGuard Portal database if they do not exist. If a user is disabled or deleted in LDAP, the user will be disabled in WireGuard Portal as well. The synchronization process can be fine-tuned by multiple parameters, which are described below.
Synchronization Parameters
To enable the LDAP sycnhronization this feature, set the sync_interval property in the LDAP provider configuration to a value greater than "0". The value is a string representing a duration, such as "15m" for 15 minutes or "1h" for 1 hour (check the exact format definition for details). The synchronization process will run in the background and synchronize users from LDAP to the database at the specified interval. Also make sure that the sync_filter property is a well-formed LDAP filter, or synchronization will fail.
Limiting Synchronization to Specific Users
Use the sync_filter property in your LDAP provider block to restrict which users get synchronized. It accepts any valid LDAP search filter, only entries matching that filter will be pulled into the portal's database.
For example, to import only users with a mail attribute:
auth:
+ User Management - WireGuard Portal User Management
For all external authentication providers (LDAP, OIDC, OAuth2), WireGuard Portal can automatically create a local user record upon the user's first successful login. This behavior is controlled by the registration_enabled setting in each authentication provider's configuration.
User information from external authentication sources is merged into the corresponding local WireGuard Portal user record whenever the user logs in. Additionally, WireGuard Portal supports periodic synchronization of user data from an LDAP directory.
To prevent overwriting local changes, WireGuard Portal allows you to set a per-user flag that disables synchronization of external attributes. When this flag is set, the user in WireGuard Portal will not be updated automatically during log-ins or LDAP synchronization.
LDAP Synchronization
WireGuard Portal lets you hook up any LDAP server such as Active Directory or OpenLDAP for both authentication and user sync. You can even register multiple LDAP servers side-by-side. Details on the log-in process can be found in the LDAP Authentication section.
If you enable LDAP synchronization, all users within the LDAP directory will be created automatically in the WireGuard Portal database if they do not exist. If a user is disabled or deleted in LDAP, the user will be disabled in WireGuard Portal as well. The synchronization process can be fine-tuned by multiple parameters, which are described below.
Synchronization Parameters
To enable the LDAP sycnhronization this feature, set the sync_interval property in the LDAP provider configuration to a value greater than "0". The value is a string representing a duration, such as "15m" for 15 minutes or "1h" for 1 hour (check the exact format definition for details). The synchronization process will run in the background and synchronize users from LDAP to the database at the specified interval. Also make sure that the sync_filter property is a well-formed LDAP filter, or synchronization will fail.
Limiting Synchronization to Specific Users
Use the sync_filter property in your LDAP provider block to restrict which users get synchronized. It accepts any valid LDAP search filter, only entries matching that filter will be pulled into the portal's database.
For example, to import only users with a mail attribute:
auth:
ldap:
- id: ldap
# ... other settings
diff --git a/master/documentation/usage/webhooks/index.html b/master/documentation/usage/webhooks/index.html
index 2391629..a28c2af 100644
--- a/master/documentation/usage/webhooks/index.html
+++ b/master/documentation/usage/webhooks/index.html
@@ -1,4 +1,4 @@
- Webhooks - WireGuard Portal Webhooks
Webhooks allow WireGuard Portal to notify external services about events such as user creation, device changes, or configuration updates. This enables integration with other systems and automation workflows.
When webhooks are configured and a specified event occurs, WireGuard Portal sends an HTTP POST request to the configured webhook URL. The payload contains event-specific data in JSON format.
Configuration
All available configuration options for webhooks can be found in the configuration overview.
A basic webhook configuration looks like this:
webhook:
+ Webhooks - WireGuard Portal Webhooks
Webhooks allow WireGuard Portal to notify external services about events such as user creation, device changes, or configuration updates. This enables integration with other systems and automation workflows.
When webhooks are configured and a specified event occurs, WireGuard Portal sends an HTTP POST request to the configured webhook URL. The payload contains event-specific data in JSON format.
Configuration
All available configuration options for webhooks can be found in the configuration overview.
A basic webhook configuration looks like this:
webhook:
url: https://your-service.example.com/webhook
Security
Webhooks can be secured by using a shared secret. This secret is included in the Authorization header of the webhook request, allowing your service to verify the authenticity of the request. You can set the shared secret in the webhook configuration:
webhook:
url: https://your-service.example.com/webhook
diff --git a/master/index.html b/master/index.html
index ad293a9..5a9aa0c 100644
--- a/master/index.html
+++ b/master/index.html
@@ -1,4 +1,4 @@
- WireGuard Portal - WireGuard Portal