SiYuan

The easiest way to serve SiYuan on a server is to deploy it through Docker.

• Image name b3log/siyuan
• Image URL

The overall program is located under /opt/siyuan/, which is basically the structure under the resources folder of the Electron installation package:

• appearance: icon, theme, languages
• guide: user guide document
• stage: interface and static resources
• kernel: kernel program

The entry point is set when building the Docker image: ENTRYPOINT ["/opt/siyuan/entrypoint.sh"]. This script allows changing the PUID and PGID of the user that will run inside the container. This is especially relevant to solve permission issues when mounting directories from the host. The PUID (User ID) and PGID (Group ID) can be passed as environment variables, making it easier to ensure correct permissions when accessing host-mounted directories.

Use the following parameters when running the container with docker run b3log/siyuan:

Note: Since v3.7.0, the serve subcommand must be passed explicitly (e.g. docker run b3log/siyuan serve --workspace=...). Run docker run --rm b3log/siyuan serve --help to see all serving options.

• --workspace: Specifies the workspace folder path, mounted to the container via -v on the host
• --accessAuthCode: Specifies the lock screen password

More parameters can be found using --help. Here’s an example of a startup command with the new environment variables:

docker run -d    -v workspace_dir_host:workspace_dir_container    -p 6806:6806    -e PUID=1001 -e PGID=1002    b3log/siyuan    serve    --workspace=workspace_dir_container    --accessAuthCode=xxx

• PUID: Custom user ID (optional, defaults to 1000 if not provided)
• PGID: Custom group ID (optional, defaults to 1000 if not provided)
• workspace_dir_host: The workspace folder path on the host
• workspace_dir_container: The path of the workspace folder in the container, as specified in --workspace
  • Alternatively, it's possible to set the path via the SIYUAN_WORKSPACE_PATH env variable. The commandline will always have the priority, if both are set
• accessAuthCode: Lock screen password (please be sure to modify, otherwise anyone can access your data)
  • Alternatively, it's possible to set the lock screen password via the SIYUAN_ACCESS_AUTH_CODE env variable. The commandline will always have the priority, if both are set
  • To disable the lock screen password set the env variable SIYUAN_ACCESS_AUTH_CODE_BYPASS=true
• OIDC can replace the lock screen password as the required Docker access authentication. Set SIYUAN_OIDC_ENABLED=true, SIYUAN_OIDC_PROVIDER (custom, google, microsoft, or github), SIYUAN_OIDC_CLIENT_ID, and the provider-specific values below. GitHub uses its OAuth 2.0 user API adapter; the other providers use OpenID Connect discovery and ID Token validation. An invalid enabled configuration stops Docker startup when no lock screen password is available
  • SIYUAN_OIDC_ISSUER_URL: Issuer URL required by the custom and microsoft providers; Microsoft must use a tenant-specific issuer such as login.microsoftonline.com//v2.0
  • SIYUAN_OIDC_CLIENT_SECRET: Optional client secret for OpenID Connect providers; required by the GitHub OAuth adapter. Every authorization-code flow also uses PKCE
  • SIYUAN_OIDC_SCOPES: Comma- or space-separated scopes; openid is always included
  • SIYUAN_OIDC_REDIRECT_URL: Public HTTPS callback URL ending in /api/system/oidc/callback, required for remote browser access
  • SIYUAN_OIDC_ALLOW_ALL: Explicitly grant SiYuan administrator access to every identity authenticated by the provider
  • SIYUAN_OIDC_CLAIM_RULES: JSON array of claim rules used when allow-all is disabled, for example <[{"claim":"email","operator":"equals","values":["user@example.com"]},{"claim":"email_verified","operator":"equals","values":["true"]}]">662>[{"claim":"email","operator":"equals","values":["user@example.com"]},{"claim":"email_verified","operator":"equals","values":["true"]}]; values within a rule use OR, while rules use AND
  • Native mobile apps use the fixed callback URI siyuan:/oidc-callback; register it exactly as written. Mobile configuration verification uses this callback before saving. Custom providers, Microsoft, and GitHub can be used only when their application registration accepts this callback URI. Google does not accept this private-use URI for its Android client type, so Google login is limited to browser and desktop flows
• SIYUAN_LANG: Interface language (optional, defaults to en if unset in Docker). Accepts BCP 47 tags like zh-CN/zh-TW/en/ja/pt-BR; legacy underscore values like zh_CN/en_US are also accepted for backward compatibility. Omit it if you want the language chosen in Settings to persist across restarts; if set, it is applied on every startup and overrides the saved setting
  • Alternatively, use the --lang command-line parameter. If both are set, the command-line takes priority

To simplify things, it is recommended to configure the workspace folder path to be consistent on the host and container, such as having both workspace_dir_host and workspace_dir_container configured as /siyuan/workspace. The corresponding startup command would be:

docker run -d    -v /siyuan/workspace:/siyuan/workspace    -p 6806:6806    -e PUID=1001 -e PGID=1002    b3log/siyuan    serve    --workspace=/siyuan/workspace/    --accessAuthCode=xxx

For users running SiYuan with Docker Compose, the environment variables PUID and PGID can be passed to customize the user and group IDs. Here's an example of a Docker Compose configuration:

version: "3.9" services:   main:     image: b3log/siyuan     command: ['serve', '--workspace=/siyuan/workspace/', '--accessAuthCode=${AuthCode}']     ports:       - 6806:6806     volumes:       - /siyuan/workspace:/siyuan/workspace     restart: unless-stopped     environment:       - TZ=${YOUR_TIME_ZONE}    # A list of time zone identifiers can be found at en.wikipedia.org/wiki/List_of_tz_database_time_zones       - PUID=${YOUR_USER_PUID}  # Customize user ID       - PGID=${YOUR_USER_PGID}  # Customize group ID

In this setup:

• PUID and PGID are set dynamically and passed to the container
• If these variables are not provided, the default 1000 will be used

By specifying PUID and PGID in the environment, you avoid the need to explicitly set the user directive (user: '1000:1000') in the compose file. The container will dynamically adjust the user and group based on these environment variables at startup.

In the image, the entrypoint.sh script ensures the creation of the siyuan user and group with the specified PUID and PGID. Therefore, when the host creates a workspace folder, pay attention to setting the user and group ownership of the folder to match the PUID and PGID you plan to use. For example:

chown -R 1001:1002 /siyuan/workspace

If you use custom PUID and PGID values, the entrypoint script will ensure that the correct user and group are created inside the container, and ownership of mounted volumes will be adjusted accordingly. There’s no need to manually pass -u in docker run or docker-compose as the environment variables will handle the customization.

Use an NGINX reverse proxy to hide port 6806. Please note:

• Configure the WebSocket reverse proxy for /ws
• Preserve the original Host header, including the port, for both regular requests and /ws. In NGINX, configure proxy_set_header Host $http_host; in both proxy locations. Using $host drops non-standard ports (such as 8443), which can cause Origin validation to fail, leaving the page stuck on the logo with repeated reloads, API responses of 401, or failed WebSocket connections

• Be sure to confirm the correctness of the mounted volume, otherwise the data will be lost after the container is deleted
• Do not use URL rewriting for redirection, otherwise there may be problems with authentication, it is recommended to configure a reverse proxy
• If you encounter permission issues, verify that the PUID and PGID environment variables match the ownership of the mounted directories on your host system

• Does not support desktop and mobile application connections, only supports use on browsers
• Export to PDF, HTML and Word formats is not supported
• Import Markdown file is not supported

The HelmForge SiYuan chart is community-maintained by HelmForge, uses the official b3log/siyuan image, and is not an official SiYuan chart. Please report chart issues to HelmForge.

Prepare Helm, kubectl, and a Kubernetes cluster with a default StorageClass that can provision a 10Gi ReadWriteOnce volume, then run the following commands:

helm repo add helmforge repo.helmforge.dev helm repo update helm install siyuan helmforge/siyuan --namespace siyuan --create-namespace --wait kubectl -n siyuan get secret siyuan-siyuan-auth -o go-template='{{index .data "access-code" | base64decode}}{{"n"}}' kubectl -n siyuan port-forward service/siyuan-siyuan 6806:6806

Open http://localhost:6806 and enter the generated lock screen password. Keep this password secure; it is distinct from the API token. The names above assume the default chart values and release name siyuan.

For remote access, use a dedicated HTTPS hostname and an Ingress controller that proxies WebSockets on /ws, without URL rewriting. Configure ingress and allow the controller's namespace through networkPolicy.ingressFrom; the default policy allows same-namespace ingress and DNS egress only. Add explicit egress rules for cloud sync or other external services. See the chart guide and production example for TLS, existing Secrets, and storage configuration.

• One workspace, one writer: Never scale replicas or mount the same workspace in another running instance, even with ReadWriteMany storage. The chart uses Recreate, so upgrades stop the old writer before starting the new one and cause downtime.
• Persistence: The complete workspace is mounted at /siyuan/workspace. The chart retains its generated PVC on uninstall by default; deleting the namespace or PVC can still destroy data. Reuse a retained or restored claim with persistence.existingClaim.
• Backups and upgrades: Gracefully stop the writer before backing up the complete workspace, or use an application-consistent backup procedure. A copy of the live SQLite index alone is insufficient. Securely preserve authentication Secrets, encryption keys, and encrypted-notebook recovery passwords, and test restores into a separate PVC. Back up before upgrades and review storage-format changes: Helm rollback does not undo data migrations.

The Docker hosting limitations also apply: browser use only, no desktop or mobile application connections, no PDF/HTML/Word export, and no Markdown file import.

Note: First run chown -R 1000:1000 /mnt/user/appdata/siyuan in the terminal

Template reference:

Web UI: 6806 Container Port: 6806 Container Path: /home/siyuan Host path: /mnt/user/appdata/siyuan PUID: 1000 PGID: 1000 Publish parameters: serve --accessAuthCode=******(Lock screen password) 

Note: First, run the commands below in the TrueNAS Shell. Please update Pool_1/Apps_Data/siyuan to match your dataset path.

zfs create Pool_1/Apps_Data/siyuan chown -R 1001:1002 /mnt/Pool_1/Apps_Data/siyuan chmod 755 /mnt/Pool_1/Apps_Data/siyuan

Navigate to Apps - DiscoverApps - More Options (on top right, besides Custom App) - Install via YAML

Template reference:

services:   siyuan:     image: b3log/siyuan     container_name: siyuan     command: ['serve', '--workspace=/siyuan/workspace/', '--accessAuthCode=2222']     ports:       - 6806:6806     volumes:       - /mnt/Pool_1/Apps_Data/siyuan:/siyuan/workspace  # Adjust to your dataset path      restart: unless-stopped     environment:       - TZ=America/New_York  # Replace with your timezone if needed       - PUID=1001       - PGID=1002