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	—
Secret	`RELEASE_NAME-docmost-creds`	Dictionary secret the chart creates with the PostgreSQL and Redis credentials Docmost uses to assemble `DATABASE_URL` and `REDIS_URL`	—
Secret	the name in `postgres.config.credentialsSecretName`	Dictionary secret the chart creates (`username`, `password`, `database`) and hands to the bundled PostgreSQL	—
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: the credentials secret, your `APP_SECRET` secret, 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 secret is not created by the template — see Prerequisites.

Prerequisites

Docmost signs sessions, invitation links, and share links with an APP_SECRET that you supply through an opaque secret created before installing. The value never passes 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 secret before installing. Installing without it 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.

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 APP_SECRET secret exists, install from the marketplace registry, pointing secrets.name at it and replacing both bundled-component passwords:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/docmost \
  --version 1.1.0 --gvc GVC_NAME \
  --set secrets.name=APP_SECRET_NAME \
  --set postgres.credentials.password='YOUR-DB-PASSWORD' \
  --set redis.auth.password='YOUR-REDIS-PASSWORD'

Installing a second Docmost release in the same org? Also set postgres.config.credentialsSecretName to a name no other release uses — secret names are org-wide. 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 chart builds the credentials secret from postgres.credentials.* for you — nothing to create before installing.

postgres:
  image: postgres:18
  credentials: # the chart writes these into the secret named below
    username: docmost
    password: change-me-docmost-pg # change before installing — seeds the database on first boot
    database: docmost
  config:
    credentialsSecretName: my-docmost-db-credentials # chart-created; secret names are org-wide, so give each release its own
  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
  auth:
    password: change-me-docmost-redis # change before installing — wired into REDIS_URL
  resources:
    minCpu: 100m
    maxCpu: 400m
    minMemory: 256Mi
    maxMemory: 512Mi
  volumeset:
    capacity: 10 # GiB (minimum 10); AOF at /data

Both bundled passwords seed their component on first boot and are not updated by later value edits. 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 `redisPassword` key of `cpln secret reveal RELEASE_NAME-docmost-creds -o yaml`.

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.

Upgrading from 1.0.0

Version 1.1.0 adopted the postgres 3.4.1 template, which stopped taking database credentials as values. Docmost absorbed that change rather than passing it on — the chart now creates the credentials secret itself — so there is no new prerequisite, only a rename of three keys:

Removed key (1.0.0)	Replacement (1.1.0)
`postgres.config.username`	`postgres.credentials.username`
`postgres.config.password`	`postgres.credentials.password`
`postgres.config.database`	`postgres.credentials.database`

Move the three keys, keep the same values so the running database still matches, and upgrade in place. A values file that still carries an old key fails the render with the postgres template’s message, which tells you to create a dictionary secret yourself — ignore that advice here; this template creates it.

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: The APP_SECRET prerequisite secret named by secrets.name does not exist.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.

Second install refused as managed by a different release

Symptom: Installing a second Docmost release fails with cannot be updated because it is being managed by a different release and creates nothing.Cause: Both releases use the same postgres.config.credentialsSecretName. Secret names are org-wide, and the first release owns that one. Nothing is shared, overwritten, or deleted.Fix: Set postgres.config.credentialsSecretName to a distinct name for the second release and install again.

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: Rename them to postgres.credentials.* as described in Upgrading from 1.0.0. Do not create a secret yourself — this template creates it.

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 APP_SECRET secret before installing — secrets.name must name an existing opaque secret (plain encoding) with a random payload of at least 32 characters. A missing secret wedges the deployment silently.
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.
Change postgres.credentials.password and redis.auth.password before installing — both seed their component on first boot and are not updated by later value edits.
Give each release its own postgres.config.credentialsSecretName — secret names are org-wide, and a second release on the same name is refused at install.
Uninstalling deletes the volume sets and every page and local attachment in them; your APP_SECRET secret is yours and survives.
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

Upgrading from 1.0.0

Scaling and Availability

Troubleshooting

Important Notes

External References

Docmost Documentation

Environment Variables

Self-Hosting Configuration

Docmost on GitHub

Docmost Template

​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

​Upgrading from 1.0.0

​Scaling and Availability

​Troubleshooting

​Important Notes

​External References

Docmost Documentation

Environment Variables

Self-Hosting Configuration

Docmost on GitHub

Docmost Template

Overview

What Gets Created

Prerequisites

Installation

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

Upgrading from 1.0.0

Scaling and Availability

Troubleshooting

Important Notes

External References