Beyond jobs and workflows, there is setup work: branding, permissions, storage, and the hardening that keeps a wiki healthy for years. These ten customizations are where the agent’s access to files and configuration pays off. Some take an afternoon; a few need the paid Docmost edition, and we say so.

1. Brand the workspace as yours

Docmost is plain out of the box — fine for testing, forgettable for a team. The agent sets your workspace name and logo in the settings, switches the default appearance, and can inject a little custom CSS through the reverse proxy to match your brand color. The surface is small, but the wiki starts feeling like company property instead of a tool someone installed. Try: “Rename the workspace to Acme Wiki, set our logo, and tint the header bar our brand color with custom CSS.”

2. Harden the web front end properly

The most common self-hosting failure with Docmost: the collaborative editor loads read-only because the reverse proxy drops WebSocket upgrade headers. The agent writes the proxy configuration with the right headers, forces HTTPS, and disables telemetry in the environment. Then it opens the same page in two browser sessions to prove co-editing works before calling the job done. It also pins the Docmost version in your compose file so updates are a choice instead of a surprise. Try: “Put Docmost behind our reverse proxy with WebSocket support, force HTTPS, and turn off telemetry.”

3. Move attachments to S3

Local disk is fine until the server dies holding the only copy of your files. Docmost can store attachments in any S3-compatible bucket. The agent flips the storage driver in your environment, migrates existing uploads with a sync tool, and verifies that old pages still serve their images. Do this early — the longer you wait, the more files the migration has to move. Try: “Switch attachments to our S3 bucket, migrate the files already uploaded, and check a few old pages still show their images.”

4. Design the permission matrix before it designs itself

Spaces with ad-hoc member invites become unreadable to the wrong people within months. The agent plans it properly: one space per team or project, groups instead of individual invites, edit access for contributors and view for everyone else. Then it creates the groups and memberships and writes the whole matrix into a private admin page so future-you can check who sees what. Try: “Design a permission matrix — a space per department, groups mapped to teams, edit vs view — then implement it and document it in a wiki page.”

5. Build a label taxonomy and backfill it

Labels only work if everyone uses the same ones. The agent proposes a small scheme per space — status, audience, product area — documents it in a style-guide page, and backfills existing pages, querying the database for stragglers. Search and filtering get sharper because the vocabulary got smaller. Try: “Give the Support space a label scheme — status, product, audience — and apply it to all existing pages.”

6. Wire up SSO or LDAP login

Passwords in a wiki are one more thing to reset and one more door left open. With the paid edition’s SAML and OIDC support, the agent configures Docmost against your identity provider — Google Workspace, Entra ID, Okta — registers the callback URLs, and test-logs in with your account before rolling it out to the team. On the free edition, it can tighten password practice and review accounts instead. Try: “Connect Docmost to our Google Workspace login, test it with my account, and keep one fallback admin on password login.”

7. Build a template library people actually use

Consistent pages come from starting points, not discipline. The agent builds your core page types — meeting notes, runbook, decision record, incident review — as well-formatted pages in a Templates space that anyone can duplicate, with the right sections, callouts, and empty tables already in place. If your edition includes Docmost’s built-in templates, it loads them there instead and you skip the duplication dance. The Templates space gets view access for everyone and edit access only for whoever owns each format. Try: “Build me meeting-notes, runbook, and decision-record templates as pages in a Templates space, ready to duplicate.”

8. Wall off the sensitive runbooks

Some pages should not be visible to the whole company: incident playbooks, security contacts, contract details. With page-level permissions in the paid edition, the agent locks specific pages or subtrees to the ops group; on the free edition it moves them to a restricted space with its own membership. Either way, it audits who had access before the change and reports the list. Try: “Lock the incident-response pages so only the ops group can see them, and show me who had access before.”

9. Set the language and make mail trustworthy

A German team should not get an English default, and invitation emails from a generic address land in spam. The agent sets the workspace default language, fixes the sender name and from-address to match your domain, and sanity-checks your SPF and DKIM records so notifications arrive looking like yours. These are details, but they decide whether people trust — or even see — the emails. If your team spans countries, it can also standardize date formats in page titles and templates so “03/04” never starts an argument. Try: “Set the default language to German, make emails come from wiki@ourcompany.com, and check our SPF and DKIM records so they stop landing in spam.”

10. Turn on page verification for policy documents

The paid edition can require pages to be reviewed and re-approved on a schedule. For policies, safety procedures, and anything legal cares about, the agent enables verification on those spaces and sets the review interval, so every page gets a named reviewer and an expiry date instead of rotting confidently. Expired pages surface in a queue rather than misleading someone during an audit. The agent can seed that queue by listing which policy pages have never been reviewed at all, so nothing hides in grandfathered territory. Try: “Turn on page verification for the Policies space so each page needs a named reviewer every six months.”

You do not need all ten. Pick the two or three that close gaps you already feel, and let the agent handle the fiddly parts. See Docmost on OpenSysLab.