Docmost

Overview

Docmost is an open-source knowledge base and wiki — a Confluence or Notion alternative with real-time collaborative editing, spaces, and per-space permissions. This template deploys the Docmost server (web UI, REST API, and collaboration websocket on port 3000) backed by a bundled PostgreSQL for documents and a bundled Redis for job queues and realtime coordination, with attachments kept on a persistent volume or in an S3 bucket you own. The default is a single replica; docmost.replicas scales out once attachments live in S3.

This template deploys into an existing GVC that you already have — it does not create or manage a GVC.

What Gets Created

Resource	Name	Purpose	Optional
Workload	`RELEASE_NAME-docmost`	Docmost server: UI, API, and collaboration websocket on port `3000` (stateful, `docmost.replicas` replicas)	—
Workload	`RELEASE_NAME-docmost-redis`	Bundled single-node Redis with AOF persistence — job queues and cross-replica realtime sync (stateful, 1 replica)	—
Workload	`RELEASE_NAME-postgres`	Bundled PostgreSQL from the postgres template — every page, user, space, and permission (stateful, 1 replica)	—
Workload	`RELEASE_NAME-postgres-backup`	Cron job that dumps the database to object storage on a schedule	`postgres.backup.enabled: true`
Volume set	`RELEASE_NAME-docmost-storage`	Local attachment storage, mounted at `/app/data/storage` only when `storage.type` is `local`	—
Volume set	`RELEASE_NAME-docmost-redis-vs`	Redis append-only file at `/data`	—
Volume set	`RELEASE_NAME-pg-vs`	PostgreSQL data directory; takes no scheduled snapshots; a final snapshot is taken when the volume set is deleted and kept 7 days	—
Identity	`RELEASE_NAME-docmost-identity`	Bound to the Docmost and Redis workloads; carries your AWS cloud account link in keyless S3 mode	—
Policy	`RELEASE_NAME-docmost-policy`	Grants that identity `reveal` on exactly the secrets it reads: your database credentials, Redis password and `APP_SECRET` secrets, and your S3-key and SMTP secrets when configured	—
Identity	`RELEASE_NAME-pg-identity`	Bound to the bundled PostgreSQL (and its backup job)	—
Policy	`RELEASE_NAME-pg-policy`	Grants the PostgreSQL identity `reveal` on its credentials secret only	—

Your APP_SECRET, database credentials and Redis password secrets are not created by the template — see Prerequisites.

Prerequisites

Three secrets must exist before installing: the APP_SECRET Docmost signs sessions, invitation links, and share links with, supplied through an opaque secret, and two dictionary secrets holding the database credentials and the Redis password. The values never pass through Helm values.

Create the APP_SECRET secret

The payload is a single random string of at least 32 characters. Use printf rather than echo so the payload carries no trailing newline:

printf '%s' "$(openssl rand -hex 32)" | cpln secret create-opaque --name APP_SECRET_NAME --encoding plain -f -

Set secrets.name to this name. Secrets are org-level, so no GVC flag is involved.

Back the value up outside Control Plane

APP_SECRET is effectively write-once: rotating it logs out every user and invalidates every outstanding invitation and share link (stored documents are unaffected). Keep a copy somewhere safe.

Create the database credentials secret

The bundled PostgreSQL initializes with these values and Docmost connects with them:

cpln secret create-dictionary --name DB_CREDENTIALS_SECRET_NAME \
  --entry username=docmost \
  --entry password="$(openssl rand -hex 24)" \
  --entry database=docmost

Set postgres.config.credentialsSecretName to this name. Secret names are org-wide, so give each Docmost release its own secret. The three values are part of Docmost’s connection URL, so use letters, digits, - and _ only. PostgreSQL reads the secret only when its data is first initialized — see Rotating the Database Password.

Create the Redis password secret

One key, password; the bundled Redis requires it and Docmost connects with it:

cpln secret create-dictionary --name REDIS_SECRET_NAME \
  --entry password="$(openssl rand -hex 24)"

Set redis.credentialsSecretName to this name. The password is part of Docmost’s Redis URL, so use letters, digits, - and _ only.

Create all three secrets before installing. Installing without one reports success, but the deployment then wedges silently — cpln logs returns nothing, and the only place the missing secret is named is status.versions[].message:

cpln workload get-deployments RELEASE_NAME-docmost --gvc GVC_NAME -o yaml

The message reads

The secret APP_SECRET_NAME no longer exists. Workload updates are paused until the secret is added or the reference to the secret removed.

The message names whichever secret is missing. Creating the secret lets the deployment recover on its own; cpln workload force-redeployment RELEASE_NAME-docmost --gvc GVC_NAME skips the wait.

Everything else works with the defaults. Three optional features need their own setup first:

S3 attachment storage (required for more than one replica) — an existing bucket plus either an AWS cloud account and bucket-scoped IAM policy, or a static-key secret for an S3-compatible server. See Attachment Storage on S3.
Authenticated SMTP — a dictionary secret holding SMTP_USERNAME and SMTP_PASSWORD. See Email.
Scheduled database backups — a bucket and cloud account for the bundled PostgreSQL. See Backing Up.

Installation

Once your three secrets exist, install from the marketplace registry, pointing the three secret-name keys at them:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/docmost \
  --version 1.2.0 --gvc GVC_NAME \
  --set secrets.name=APP_SECRET_NAME \
  --set postgres.config.credentialsSecretName=DB_CREDENTIALS_SECRET_NAME \
  --set redis.credentialsSecretName=REDIS_SECRET_NAME

Other ways to install and manage the template:

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

Configuration

Docmost Server

docmost:
  image: docmost/docmost:0.95.0 # pin a released tag, never latest
  replicas: 1 # >1 REQUIRES storage.type: s3; replicas coordinate via Redis
  appUrl: "" # public base URL used in links; empty = derive from the canonical endpoint; set WITH https:// for a custom domain
  resources:
    minCpu: 250m
    maxCpu: 1000m
    minMemory: 512Mi
    maxMemory: 2Gi # headroom for boot migrations and large imports

Prerequisite Secret

secrets:
  name: my-docmost-app-secret # opaque secret (encoding plain) whose payload is APP_SECRET — MUST exist before install

Attachment Storage

storage.type decides where uploaded files, images, and avatars are kept. The default local volume works for a single replica; the bucket, cloud account, and secret setup for s3 is under Attachment Storage on S3.

storage:
  type: local # local | s3 (s3 required for replicas > 1)
  local:
    volumeset:
      capacity: 10 # GiB (minimum 10); mounted at /app/data/storage
  s3:
    bucket: my-docmost-bucket
    region: us-east-1
    endpoint: "" # set for S3-compatible servers (e.g. http://WORKLOAD_NAME.GVC_NAME.cpln.local:9000)
    forcePathStyle: false # true for most S3-compatible servers (MinIO)
    cloudAccountName: my-s3-cloud-account # keyless AWS auth; used only when auth.secretName is empty
    policyName: my-docmost-s3-policy # your pre-created bucket-scoped IAM policy
    auth:
      secretName: "" # dictionary secret with AWS_S3_ACCESS_KEY_ID + AWS_S3_SECRET_ACCESS_KEY; S3-compatible servers only
  fileUploadSizeLimit: 50mb # max single attachment size — larger uploads are stored truncated, not rejected

Email

SMTP is off by default and a default install works without it — the first visitor still creates the workspace and signs in with a password. Member invitations, however, are delivered only by email.

smtp:
  enabled: false # off = member invites cannot be delivered — enable for any multi-user workspace
  host: smtp.example.com
  port: 587
  secure: false # false = STARTTLS/plain (587); true = implicit TLS (465)
  fromAddress: no-reply@example.com
  fromName: Docmost
  auth:
    secretName: "" # optional dictionary secret with SMTP_USERNAME + SMTP_PASSWORD; empty = unauthenticated relay

For an authenticated relay, create the credentials secret before installing and set smtp.auth.secretName to its name. The Docmost identity is granted reveal on exactly that secret.

cpln secret create-dictionary --name SMTP_SECRET_NAME \
  --entry SMTP_USERNAME=YOUR-SMTP-USERNAME \
  --entry SMTP_PASSWORD='YOUR-SMTP-PASSWORD'

Access

publicAccess:
  enabled: true # HTTPS UI + websockets on the auto *.cpln.app endpoint; false = internal-only
internalAccess:
  type: same-gvc # none | same-gvc | same-org | workload-list
  workloads: [] # used only with workload-list, e.g. //gvc/GVC_NAME/workload/WORKLOAD_NAME

`internalAccess.type`	Who can reach Docmost over the internal network
`none`	No workload
`same-gvc`	Every workload in the same GVC (default)
`same-org`	Every workload in the same org
`workload-list`	Only the workloads listed in `internalAccess.workloads`

A change to either access knob takes a couple of minutes to take effect after the upgrade reports success.

Bundled PostgreSQL

The database is the postgres template as a subchart, so every knob of that template is available under postgres.*. The database credentials come from your prerequisite dictionary secret (username, password and database — see Prerequisites), named by postgres.config.credentialsSecretName.

postgres:
  image: postgres:18
  config:
    credentialsSecretName: my-docmost-db-credentials # PREREQUISITE dictionary secret (username, password, database) — must exist BEFORE install
  resources:
    minCpu: 250m
    maxCpu: 1000m
    minMemory: 512Mi
    maxMemory: 1Gi
  volumeset:
    capacity: 10 # GiB (minimum 10)
  backup:
    enabled: false # scheduled pg_dumpall to object storage — see Backing Up
    schedule: "0 2 * * *" # daily at 02:00 UTC
    provider: aws # aws | gcp | minio

Bundled Redis

Redis is required: Docmost’s readiness check pings it alongside the database, and the workload does not become ready without it.

redis:
  image: redis:8
  credentialsSecretName: my-docmost-redis # PREREQUISITE dictionary secret (key: password; letters, digits, - and _) — must exist BEFORE install
  resources:
    minCpu: 100m
    maxCpu: 400m
    minMemory: 256Mi
    maxMemory: 512Mi
  volumeset:
    capacity: 10 # GiB (minimum 10); AOF at /data

PostgreSQL reads its password from the secret only when its data is first initialized; Redis reads its password each time it starts. To change either, follow Rotating the Database Password or Rotating the Redis Password. Uninstalling the release deletes the volume sets; reinstall to reset.

Connecting

What	Address	Notes
Public UI and API	`https://<canonical>.cpln.app`	Assigned automatically while `publicAccess.enabled` is `true`. Read it from `status.canonicalEndpoint` with `cpln workload get RELEASE_NAME-docmost --gvc GVC_NAME -o yaml`.
Collaboration websocket	`wss://<canonical>.cpln.app/collab`	Used by the editor; no separate configuration.
Health	`/api/health` (readiness), `/api/health/live` (liveness)	Unauthenticated, on the same host.
Internal (same GVC)	`http://RELEASE_NAME-docmost.GVC_NAME.cpln.local:3000`	Reachable per `internalAccess.type`.
Login	The account created on first run	Docmost ships no default account.
PostgreSQL	`RELEASE_NAME-postgres.GVC_NAME.cpln.local:5432`	`username` / `password` / `database` from `cpln secret reveal SECRET_NAME -o yaml`, where `SECRET_NAME` is your `postgres.config.credentialsSecretName`.
Redis	`RELEASE_NAME-docmost-redis.GVC_NAME.cpln.local:6379`	Password is the `password` key of `cpln secret reveal SECRET_NAME -o yaml`, where `SECRET_NAME` is your `redis.credentialsSecretName`.

With publicAccess.enabled: false there is no public endpoint; reach the UI from your machine through a tunnel instead and open http://localhost:3000:

cpln port-forward RELEASE_NAME-docmost 3000:3000 --gvc GVC_NAME

First Run

Docmost ships no default account: the first person to reach the instance creates the workspace and its owner account, and that form is open to anyone who can reach the endpoint.

Wait for the Docmost workload to report ready

PostgreSQL and Redis come up first, then Docmost applies its schema migrations and starts serving.

cpln workload get-deployments RELEASE_NAME-docmost --gvc GVC_NAME -o yaml

Open the endpoint and claim the workspace

Browse to the canonical endpoint (or the port-forward URL) and complete the setup form to create the workspace and the owner account. Do this as soon as the workload is ready.

Configure email before inviting anyone

Member invitations are delivered only by email. Configure SMTP before you invite your team.

Operations

Attachment Storage on S3

Set storage.type: s3 to keep attachments in a bucket you own. This is required for more than one replica, and nothing in the template moves existing attachments between the local volume and the bucket — choose the storage type before uploading content.

AWS S3 (keyless)
S3-compatible (MinIO and others)

AWS S3 uses a Control Plane cloud account: no access keys are stored anywhere, and the Docmost identity obtains temporary credentials at runtime. This is the only supported way to reach AWS S3 — the chart rejects static keys unless storage.s3.endpoint is set.

Create a bucket

Create an S3 bucket. Set storage.s3.bucket and storage.s3.region to match.

Set up a cloud account

If you do not have one, create a cloud account for your AWS account. Set storage.s3.cloudAccountName to its name.

Create a bucket-scoped IAM policy

Create an AWS IAM policy with the JSON below (replace YOUR_BUCKET_NAME with your bucket), then set storage.s3.policyName to the policy’s name:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::YOUR_BUCKET_NAME",
        "arn:aws:s3:::YOUR_BUCKET_NAME/*"
      ]
    }
  ]
}

Leave the key secret empty

Keep storage.s3.auth.secretName empty. The template then attaches the cloud account and your policy to the Docmost identity.

S3-compatible servers cannot federate with a cloud account, so they use static access keys held in a dictionary secret.

Create a bucket

Create the bucket on your server. For the MinIO template deployed in the same GVC, the S3 API address is http://WORKLOAD_NAME.GVC_NAME.cpln.local:9000.

Set the endpoint

Set storage.s3.endpoint to the S3 API address including scheme and port, and storage.s3.forcePathStyle: true (required by most S3-compatible servers).

Create the key secret

Create a dictionary secret with the server’s access and secret keys and set storage.s3.auth.secretName to its name. The Docmost identity is granted reveal on exactly this secret.

cpln secret create-dictionary --name S3_KEYS_SECRET_NAME \
  --entry AWS_S3_ACCESS_KEY_ID=YOUR-ACCESS-KEY \
  --entry AWS_S3_SECRET_ACCESS_KEY='YOUR-SECRET-KEY'

Backing Up

Scheduled backups of the bundled PostgreSQL are off by default. Enabling postgres.backup.enabled: true adds one cron workload, RELEASE_NAME-postgres-backup, that runs pg_dumpall on the schedule and uploads a gzipped dump to your bucket under the configured prefix. Pick a postgres.backup.provider and complete the matching setup before installing or upgrading with it on.

AWS S3
Google Cloud Storage
MinIO / S3-compatible

postgres:
  backup:
    enabled: true
    provider: aws
    aws:
      bucket: my-postgres-bucket
      region: us-east-1
      cloudAccountName: my-s3-cloud-account
      policyName: my-postgres-backup-policy # bucket-scoped IAM policy
      prefix: postgres/backups

Create a bucket

Create an S3 bucket. Set postgres.backup.aws.bucket and postgres.backup.aws.region to match.

Set up a cloud account

If you do not have one, create a cloud account for the AWS account holding the bucket. Set postgres.backup.aws.cloudAccountName to its name.

Create a bucket-scoped IAM policy

Create an IAM policy with the JSON below (replace YOUR_BUCKET_NAME) and set postgres.backup.aws.policyName to its name:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket",
        "s3:GetObjectVersion",
        "s3:DeleteObjectVersion",
        "s3:GetBucketLocation",
        "s3:AbortMultipartUpload",
        "s3:ListBucketMultipartUploads",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": [
        "arn:aws:s3:::YOUR_BUCKET_NAME",
        "arn:aws:s3:::YOUR_BUCKET_NAME/*"
      ]
    }
  ]
}

postgres:
  backup:
    enabled: true
    provider: gcp
    gcp:
      bucket: my-postgres-bucket
      cloudAccountName: my-gcs-cloud-account
      prefix: postgres/backups

Create a bucket

Create a GCS bucket. Set postgres.backup.gcp.bucket to its name.

Set up a cloud account

Create a cloud account for the GCP project holding the bucket and set postgres.backup.gcp.cloudAccountName to its name.

Grant storage access

Grant the cloud account’s service account the Storage Admin (roles/storage.admin) role on the project. The chart additionally binds the identity to roles/storage.objectAdmin on exactly the bucket in postgres.backup.gcp.bucket.

postgres:
  backup:
    enabled: true
    provider: minio
    minio:
      endpoint: http://my-minio-workload:9000 # S3 API address including the port
      bucket: my-postgres-bucket
      credentialsSecretName: my-postgres-minio-credentials # dictionary secret with accessKey + secretKey
      prefix: postgres/backups

Create a bucket

Create the bucket on your server. Set postgres.backup.minio.bucket to its name and postgres.backup.minio.endpoint to the S3 API address including the port — for the MinIO template in the same GVC, http://WORKLOAD_NAME.GVC_NAME.cpln.local:9000.

Create the credentials secret

Create a dictionary secret with the server’s keys and set postgres.backup.minio.credentialsSecretName to its name. No cloud account is involved.

cpln secret create-dictionary --name BACKUP_MINIO_SECRET_NAME \
  --entry accessKey=YOUR-ACCESS-KEY \
  --entry secretKey='YOUR-SECRET-KEY'

A zero-length backup object is a failed run, not a backup. If the dump cannot reach the database, the upload still writes a near-empty gzip under a normal timestamped filename. Check the object size before you rely on one.

Two things the database dump does not cover: local attachments live on the RELEASE_NAME-docmost-storage volume set (S3 attachments are already in your bucket), and your APP_SECRET lives in the secret you created. The PostgreSQL volume set RELEASE_NAME-pg-vs takes no scheduled snapshots; a final snapshot is taken when the volume set is deleted and kept 7 days.

Restoring a Backup

Each backup is a gzipped plain-SQL pg_dumpall archive. Restoring means replaying that SQL into the bundled PostgreSQL. The one transport that carries a dump into the container intact is cpln workload exec with --stdin and a base64 wrapper on both ends — raw binary piped through exec is corrupted:

gunzip -c BACKUP_FILE.sql.gz | base64 | cpln workload exec RELEASE_NAME-postgres --gvc GVC_NAME \
  --container postgresql --stdin --quiet -- sh -c 'base64 -d | psql -U "$POSTGRES_USER" -d postgres'

Two constraints make this a planned operation: the archive contains CREATE ROLE and CREATE DATABASE statements, so a straight replay collides with the database Docmost already created and migrated on first boot; and no Docmost replica may be connected while you drop and recreate that database before the replay.

This restore path has not been exercised against this template end to end. Rehearse it on a throwaway release before you depend on it. Restoring from a volume set snapshot is likewise unverified here.

Rotating the Database Password

PostgreSQL keeps the password it was initialized with, and a running workload keeps the values it started with, so a rotation takes three steps in order:

Change it in the database: ALTER ROLE DB_USERNAME PASSWORD 'NEW_PASSWORD'; (DB_USERNAME is the secret’s username; connect as that user from inside the GVC).

Update the secret — export it, change only password, and apply it:

cpln secret reveal SECRET_NAME -o yaml > secret.yaml
# edit only the password key in secret.yaml
cpln apply -f secret.yaml

Right away, redeploy Docmost, and wait until get-deployments shows a higher version number, alone and ready (ready: true alone can still describe the old replica):
cpln workload force-redeployment RELEASE_NAME-docmost --gvc GVC_NAME
Do not redeploy the database: PostgreSQL reads the secret only when it is first initialized, so restarting it only adds downtime.

Connections the app already has open keep working after ALTER ROLE; new ones fail until its redeploy finishes, so redeploy right away and rotate in a quiet window.

Rotating the Redis Password

Redis keeps no password on disk: it takes the password from the secret each time it starts, and so does Docmost.

Update the secret — export it, change only password, apply it, and check it:

cpln secret reveal SECRET_NAME -o yaml > secret.yaml
# edit only the password key in secret.yaml
cpln apply -f secret.yaml
cpln secret reveal SECRET_NAME -o yaml

Redeploy Redis, then Docmost, and wait until get-deployments shows a higher version number for each, alone and ready:

cpln workload force-redeployment RELEASE_NAME-docmost-redis --gvc GVC_NAME
cpln workload force-redeployment RELEASE_NAME-docmost --gvc GVC_NAME

Docmost cannot reach Redis between the two redeploys, so expect a short interruption and rotate in a quiet window.

Upgrading from 1.0.0

postgres.config.username, postgres.config.password and postgres.config.database were removed. Put the values your database was initialized with into the database credentials secret under Prerequisites (keys username, password and database), set postgres.config.credentialsSecretName to its name, and remove the three keys. Then move the Redis password as described in Upgrading from 1.1.0 (1.0.0 kept it in the same RELEASE_NAME-docmost-creds secret).

Upgrading from 1.1.0

postgres.credentials was removed: the database credentials are now a prerequisite secret, the same one the postgres template requires on its own. redis.auth.password was removed too: the Redis password is now a prerequisite secret named by redis.credentialsSecretName. Carrying either old key forward fails the render. 1.1.0 created both secrets itself, so this upgrade deletes them. Before upgrading, create secrets under new names holding the values your release uses today — not new ones, or Docmost loses its database and Redis connections:

cpln secret reveal my-docmost-db-credentials -o yaml   # default name: use your credentialsSecretName if you changed it
cpln secret create-dictionary --name RELEASE_NAME-docmost-db \
  --entry username='YOUR_CURRENT_USERNAME' \
  --entry password='YOUR_CURRENT_PASSWORD' \
  --entry database='YOUR_CURRENT_DATABASE'

cpln secret reveal RELEASE_NAME-docmost-creds -o yaml   # redisPassword is the CURRENT Redis password
cpln secret create-dictionary --name RELEASE_NAME-docmost-redis \
  --entry password='YOUR_CURRENT_REDIS_PASSWORD'

The current values are also in postgres.credentials and redis.auth.password of the 1.1.0 release. Then upgrade with postgres.config.credentialsSecretName and redis.credentialsSecretName set to the new names, and with postgres.credentials and redis.auth removed from your values. The upgrade restarts the bundled PostgreSQL too (it now reads the new secret), so Docmost briefly loses its database; it reconnects by itself. The new version of a workload can also wait several minutes with is not allowed to reveal the secret in get-deployments while access to the new secret propagates; the previous version keeps serving meanwhile, and it clears by itself.

The first helm upgrade after an install can restart the bundled PostgreSQL even when its values are unchanged, so expect a brief interruption.

Scaling and Availability

docmost.replicas sets how many Docmost replicas run. Replicas coordinate through the bundled Redis, which carries both the job queues and the collaborative-editing updates, so a document edited on one replica appears live for a reader connected to another, and no sticky sessions are needed.

docmost:
  replicas: 2
storage:
  type: s3
  s3:
    bucket: my-docmost-bucket
    region: us-east-1
    cloudAccountName: my-s3-cloud-account
    policyName: my-docmost-s3-policy

docmost.replicas above 1 requires storage.type: s3. Local attachments live on per-replica volumes, so a file uploaded through one replica would return a 404 from another. The chart refuses to render the combination.

The bundled PostgreSQL and Redis are single-instance by design: Docmost has no Sentinel support, so the highly-available Redis template is not used. Their data lives on persistent volume sets and survives restarts, redeploys, and upgrades under the same release name.

Troubleshooting

Deployment never becomes ready and the logs are empty

Symptom: cpln helm install reported success, cpln logs returns nothing, and cpln workload get-deployments RELEASE_NAME-docmost --gvc GVC_NAME -o yaml shows

The secret APP_SECRET_NAME no longer exists. Workload updates are paused until the secret is added or the reference to the secret removed.

under status.versions[].message.Cause: A prerequisite secret does not exist — the APP_SECRET secret named by secrets.name, the database credentials secret named by postgres.config.credentialsSecretName, or the Redis password secret named by redis.credentialsSecretName. The message names the missing one.Fix: Create it (see Prerequisites). The deployment recovers on its own once the secret exists; cpln workload force-redeployment RELEASE_NAME-docmost --gvc GVC_NAME skips the wait.

Render fails because replicas above 1 require s3 storage

Symptom:

docmost: docmost.replicas > 1 requires storage.type: s3 — local attachments live on per-replica volumesets and would scatter/404 across replicas

.Cause: docmost.replicas is above 1 while storage.type is local.Fix: Complete Attachment Storage on S3 and set storage.type: s3, or keep a single replica.

Render fails because static keys are only for S3-compatible servers

Symptom: docmost: static keys (storage.s3.auth.secretName) are only for S3-compatible servers (storage.s3.endpoint set).Cause: storage.s3.auth.secretName is set without a storage.s3.endpoint. AWS S3 is keyless-only in this template.Fix: For AWS, clear storage.s3.auth.secretName and set storage.s3.cloudAccountName and storage.s3.policyName. For an S3-compatible server, set storage.s3.endpoint too.

Upgrade from 1.0.0 fails asking you to create a dictionary secret

Symptom: The render fails with the postgres template’s message about config.credentialsSecretName and a prerequisite dictionary secret.Cause: Your values file still carries postgres.config.username, postgres.config.password, or postgres.config.database.Fix: Put the three values into the database credentials secret and remove the keys, as described in Upgrading from 1.0.0.

Member invitations never arrive

Symptom: An invitation created in the UI reaches no one, and the workload logs contain no invitation link.Cause: smtp.enabled is false. The production image sends no mail and writes no fallback link to the logs.Fix: Configure Email with smtp.enabled: true (and smtp.auth.secretName for an authenticated relay), then re-send the invitation.

Uploaded attachment is incomplete

Symptom: A large upload succeeds with no error but the stored file is cut off.Cause: The file exceeded storage.fileUploadSizeLimit. Docmost stores the upload truncated at the limit instead of rejecting it.Fix: Raise storage.fileUploadSizeLimit (for example 200mb) and upload the file again.

Important Notes

Create the three prerequisite secrets before installing — secrets.name must name an existing opaque secret (plain encoding) with a random payload of at least 32 characters, and postgres.config.credentialsSecretName and redis.credentialsSecretName existing dictionary secrets. A missing secret wedges the deployment silently; status.versions[].message from cpln workload get-deployments RELEASE_NAME-docmost --gvc GVC_NAME -o yaml names it.
Treat APP_SECRET as write-once — rotating it logs out every user and invalidates outstanding invitation and share links. Back the value up outside Control Plane.
Claim the workspace right after install — the first visitor to complete the setup form becomes the workspace owner, and the form is reachable by anyone who can reach the endpoint.
With SMTP off, member invitations cannot be delivered — configure smtp.* before inviting anyone.
docmost.replicas above 1 requires storage.type: s3 — local attachments are per-replica.
AWS S3 is keyless only — a cloud account plus a bucket-scoped IAM policy; static keys are accepted only with an S3-compatible storage.s3.endpoint.
Uploads larger than storage.fileUploadSizeLimit are truncated, not rejected — raise the limit before importing large attachments.
Rotating a password needs a forced redeployment — the database password also needs ALTER ROLE first; see Rotating the Database Password and Rotating the Redis Password.
Give each release its own database credentials secret — secret names are org-wide.
Uninstalling deletes the volume sets and every page and local attachment in them; your prerequisite secrets are yours and survive.
Docmost is licensed under the AGPL — this template deploys the open-source edition.

External References

Docmost Documentation

Official Docmost documentation

Environment Variables

Every setting the Docmost server reads from its environment

Self-Hosting Configuration

File storage and email configuration options

Docmost on GitHub

Source code and release notes

Docmost Template

View the source files, default values, and chart definition

Template Catalog

Templates

Overview

What Gets Created

Prerequisites

Installation

UI

CLI

Terraform

Pulumi

Configuration

Docmost Server

Prerequisite Secret

Attachment Storage

Email

Access

Bundled PostgreSQL

Bundled Redis

Connecting

First Run

Operations

Attachment Storage on S3

Backing Up

Restoring a Backup

Rotating the Database Password

Rotating the Redis Password

Upgrading from 1.0.0

Upgrading from 1.1.0

Scaling and Availability

Troubleshooting

Important Notes

External References

Docmost Documentation

Environment Variables

Self-Hosting Configuration

Docmost on GitHub

Docmost Template