"Docmost: The Notion Alternative That Makes You Pay for SSO — and Why That Is the Right Question to Ask"

Notion ate the wiki market by making documentation feel like a canvas instead of a filing cabinet. The cost of that fluency is that your team's institutional memory now lives in a US-hosted SaaS whose export format is a leverage point. Docmost is the open-source answer to that trade: a self-hosted, real-time collaborative wiki that looks and feels like Notion, runs on infrastructure you control, and is licensed AGPL-3.0 at its core. At 21,000 stars and shipping releases every few weeks, it is one of the most actively developed entries in the self-hosted knowledge-base category.

But "open source" here needs the asterisk it always needs: Docmost is open-core. The core is genuinely AGPL-3.0, and you can run a real, multi-user, real-time-collaborating wiki on it for free forever. The enterprise features — SSO, audit logs, SCIM — live in a proprietary /ee folder behind a paid tier. That is not a scandal; it is the business model that keeps the project alive. But it is a line you must understand before you deploy, because "free self-hosted wiki" and "free self-hosted wiki with the identity features my compliance team requires" are two different products, and Docmost charges for the second.

This review explains what Docmost actually is, what v0.96.0 (September 2026) shipped, where the open-core line falls, what it costs to run honestly, how it compares to the other wikis in this series (BookStack's MIT simplicity, Wiki.js's Git-backed AGPL), and the data-sovereignty story that the "Notion alternative" framing tends to flatten. By the end you should know whether Docmost is your knowledge base or whether the collaboration tax is more than your team wants.

1. What Docmost Is, and the Job It Takes From Notion

Docmost is a collaborative documentation and wiki platform: spaces contain pages, pages contain a rich block editor with text, tables, callouts, embeds, and native diagrams (Mermaid and Draw.io). Multiple people edit the same page in real time, with cursors and changes syncing through a collaboration engine (Hocuspocus, upgraded to v4 in the 0.96 line). It is the direct spiritual successor to the Notion/Confluence experience, rebuilt to be owned.

The job it takes from Notion is "the team's brain." Onboarding docs, runbooks, product specs, meeting notes, internal wikis — the loose collection of things a team needs to know but does not want in a chat history. Docmost organizes these into spaces (think teams or topics) and pages (the documents), with a sidebar, search, and cross-links. For a self-hosted shop, the appeal is obvious: the brain lives on your Postgres, not on a vendor's.

What it does not try to be is a project manager or a database app. There is no Notion-style relational database with linked views as a first-class, deeply featured system; Docmost is a wiki and documentation tool, not a build-your-own-CRM. If your team uses Notion primarily for docs, Docmost covers the use case. If you use Notion as a lightweight app platform, you will feel the absence. Name that boundary before migrating.

2. The Stack: Postgres, Redis, and a Collaboration Engine

Docmost is a TypeScript application (NestJS on the backend, React on the front) backed by PostgreSQL and Redis. The stack choice explains both its strengths and its operational profile. Postgres is the system of record — your pages, spaces, users, and history live there, which is good news for backups (a standard pg_dump captures everything). Redis handles caching, the real-time collaboration channel, and job queues, so it is not optional for a smooth experience; the official deployment expects it.

The collaboration engine is the interesting bit. Real-time co-editing requires operational-transform or CRDT sync between clients, and Docmost uses Hocuspocus (a Yjs-based server) for this, fronted through the app. The 0.96 release upgraded it to v4, which the project says improves co-editing reliability. This is the component that makes "two people typing in the same page" work without one overwriting the other, and it is why Redis is in the stack — the collaboration state rides there.

Operational implication: Docmost is a three-container reality (app, Postgres, Redis) at minimum, and it wants decent resources. The project rates complexity moderate and the app itself is lighter than legacy Java wikis, but you are running a database and a cache, not a single binary. For a homelab that already runs Postgres for other tools, Docmost slots in beside them; for someone who wanted "one container and done," it is heavier than that. The trade is real-time collaboration, which is exactly what Notion-trained teams expect.

3. v0.96.0: What Actually Shipped in September 2026

The September 8, 2026 release (v0.96.0) is worth a section because it shows where the project is investing, and because it quietly closed gaps that made Docmost feel unfinished next to hosted competitors. The headline editor features: footnotes (real citations for technical and policy docs), side-by-side page version comparison (diff two revisions instead of just seeing "version 12 exists"), an attachments gallery, and a media lightbox. None of these are sexy; all of them are the difference between "good enough" and "I stopped noticing the missing thing."

Accessibility landed too: right-to-left text support, auto-detected, for Arabic and Hebrew teams who previously had a broken editing experience. Search got a labels filter and direct-result jumping. Under the hood, the client bundle was split and lazy-loaded for faster loads on large wikis, and a global AES-256-GCM encryption module was added at the server level for sensitive data handling.

Two enterprise-only items in 0.96 matter for the open-core conversation: MCP OAuth (so AI agents authenticate against Docmost properly instead of with static tokens) and SIEM integration (Splunk, Datadog, generic HTTP) for shipping audit events to centralized logging. These are paid-tier features, and they tell you exactly what Docmost, Inc. sells: the enterprise compliance and AI-governance surface, not the wiki. The core wiki in 0.96 is genuinely more complete than a year prior, and the paid features are genuinely enterprise-grade — the line is drawn where a CISO cares, not where a team gets started.

4. The Open-Core Line, Drawn Precisely

This is the section most "open source Notion alternative" posts skip, and it is the one that matters for a sovereignty-minded operator. Docmost's core is AGPL-3.0 and includes: multi-user auth, spaces, member-level RBAC, the editor, real-time collaboration, diagrams, search, and version history. You can run a real team wiki on that for $0 forever. The proprietary /ee folder holds: SAML 2.0, OIDC, and LDAP single sign-on; audit logs; and SCIM user provisioning. Those three are the enterprise identity and compliance stack, and they are paid.

Why this matters: if your team can live with email/password or the free auth, you owe nothing. If your security policy requires SSO (most enterprises do) or audit trails (most compliance frameworks do), you buy the Business or Enterprise tier — roughly $3.50 per user per month at the Business level, according to the project's own positioning, versus Notion's ~$15 Business seat. So the "free" claim is true for the wiki and false for the compliant wiki; the honest framing is "free to start, paid to govern."

The AGPL detail is the sovereignty guarantee. Because the core is AGPL-3.0, any hosted competitor that modifies it and offers it over a network must release their changes — so Docmost, Inc. cannot take the core private or abandon it to the community and close the forks. The EE features are a separate proprietary layer, not a fork of the core, which is the cleanest open-core structure: the commons stays free and copyleft, the enterprise add-ons are a separate commercial product. For an operator, that means the wiki you run free today cannot be rug-pulled into a paid-only binary.

5. Data Sovereignty: What Self-Hosting Actually Buys

The sovereignty headline is the storage layer. When you self-host Docmost, your pages, history, attachments, and user data live in your Postgres and your file storage (local or S3-compatible). Docmost, Inc. never sees your content. That is the direct answer to "why not just use Notion" — there is no vendor between your team's knowledge and your team. For a sovereignty-minded operator, that removal is the product.

The nuance the marketing flattens: Docmost, Inc. is a US entity (Delaware), so the company is subject to US jurisdiction — but that only matters if you use their SaaS or their paid tiers. Self-hosted on your own infrastructure, the jurisdiction over your data is yours, not theirs. The CLOUD Act risk that hangs over US SaaS vendors does not apply to data you store on hardware you control. The compliance posture (GDPR ready, HIPAA eligible for the self-hosted build) follows from you owning the stack, not from Docmost granting it.

The shared-responsibility shift is the honest cost: you are now responsible for encryption at rest, OS hardening, Postgres backups, and Redis availability. Docmost gives you the tools (the AES module, the standard Postgres backend) but not the operation. For a team that already runs infrastructure, this is background; for a team that wanted "sign in and forget it," it is the tax they were avoiding by considering Notion. The sovereignty is real; the responsibility is real too.

6. Migration: Leaving Notion Without the Friction

Docmost ships native importers for Notion and Confluence, which is the pragmatic reason teams pick it over wikis that make migration a CSV nightmare. The importer handles the common page structures, so a first pass of your existing docs lands in Docmost with most formatting intact. Advanced migration features (larger workspaces, finer mapping) sit in the paid Business tier, which is a deliberate reduction of exit friction for bigger teams — and a soft nudge toward paying once you are committed.

The realistic migration is two-phase. Phase one: import, accept that some blocks need cleanup, and rebuild the few that did not map. Phase two: re-point your team's muscle memory from the Notion URL to the Docmost URL, which is the actual hard part of any wiki migration and no tool solves it. Docmost lowers the technical barrier; it cannot lower the human one. Budget a week of "why is this page empty" Slack messages regardless of which tool you choose.

For teams coming from Markdown or Git-backed wikis, Docmost is a different model — it is a database app, not a file tree. You do not get the "every page is a Markdown file in git" property that Wiki.js (covered in this series) gives you. If version-controlling your docs in git is a hard requirement, Docmost's Postgres-backed model is the wrong shape, and you should read the Wiki.js entry instead. If real-time collaboration is the hard requirement, Docmost is the stronger pick. The two wikis optimize for different truths.

7. Real-Time Collaboration: The Feature That Justifies the Stack

The reason Docmost runs Postgres plus Redis plus a collaboration server is real-time editing, and it is the feature that most distinguishes it from the lighter wikis in this category. Multiple cursors, live typing, no "someone else is editing this" lock — the Notion experience — is the default, not a plugin. For a team that writes together (specs, runbooks, meeting notes), this is not a nice-to-have; it is the reason they abandon a static wiki.

The cost of that feature is operational: the collaboration engine must stay healthy, Redis must stay up, and the app must handle concurrent writes without corrupting a page. The 0.96 upgrade to Hocuspocus v4 is the project hardening exactly this path. For a solo operator or a docs-only team, real-time is overkill and the stack is heavier than you need — which is the argument for BookStack (covered earlier), a MIT wiki with no collaboration engine and a dramatically simpler deploy. Docmost is the choice when the collaboration is the point; BookStack is the choice when the simplicity is.

There is also a conflict-resolution reality: concurrent edits to the same block can collide, and while CRDT sync resolves most, messy simultaneous edits still need a human to reconcile. Version history (and in 0.96, side-by-side diffing) is your safety net — you can see what changed and roll back. The collaboration is robust; it is not magic, and the version tools are what make it safe in practice.

8. Diagrams and Rich Content: More Than Text

Docmost's native diagram support (Mermaid for text-defined charts, Draw.io for visual whiteboarding) is a genuine differentiator for technical teams. Architecture diagrams, flowcharts, and decision trees live inside the doc next to the prose, not in a separate tool someone forgets to update. For engineering and ops docs — the kind this blog's readers write — that integration is the difference between a wiki people use and a wiki people screenshot from Lucidchart.

The Draw.io integration means a non-technical author can drag shapes, while Mermaid means a technical author can define a diagram in code and have it render. Both are first-class in the editor, which is rarer than it should be in self-hosted wikis. Combined with callouts, tables, and embeds, Docmost covers the "rich internal documentation" use case that plain-Markdown tools under-serve. If your docs are mostly narrative text, this does not matter; if your docs are half diagrams, it matters a lot.

Attachments (receipts, PDFs, images) get a gallery view in 0.96, and media opens in a lightbox — small UX wins that, aggregated, are why a team sticks with a tool. The pattern across Docmost's releases is exactly this: close the hundred small gaps that make a hosted tool feel finished, so the self-hosted option stops feeling like a compromise. That is the right product strategy for an open-core wiki, and it is why Docmost keeps gaining stars.

9. Search and Structure at Scale

A wiki is only as good as finding things in it, and Docmost's search improved in 0.96 with label filters and direct-result jumping. For a wiki that grows to thousands of pages, search quality is the difference between a knowledge base and a graveyard. The labels filter lets you narrow by tag, and jumping straight to a result (not just previewing a snippet) shortens the path from "I need the runbook" to "I have the runbook."

Structure comes from spaces and pages. Spaces are the top-level containers (a team, a product, a topic); pages nest within. It is less rigid than BookStack's Shelves→Books→Chapters→Pages four-layer hierarchy and more structured than a flat Markdown folder. For most teams that middle ground is right: enough organization to scale, not so much that authorship becomes paperwork. The sidebar navigation and cross-links keep a large wiki navigable, which is the actual test of a wiki's information architecture.

One caveat at scale: very large wikis (tens of thousands of pages) will want the performance tuning the 0.96 lazy-loading and bundle-splitting address, and you should index your Postgres properly. The app is modern and fast for normal team sizes; if you are documenting a multinational, validate before you commit. For the homelab and small-business audience this series serves, it is comfortably within spec.

10. Limitations: Where Docmost Stops

No honest review ships a tool without its edges. First, the enterprise identity features are paid — if SSO or audit logs are mandatory, budget for the tier. Second, it is a wiki, not a database app; if you need Notion's relational views as a core workflow, you will feel the gap. Third, the stack is heavier than a single-binary wiki; you run Postgres and Redis, and you back them up.

Fourth, the project is young (first commit 2023) and moving fast, which is exciting and slightly risky: APIs and features shift between releases, and a fast-moving open-core project can change its paid line. The AGPL core protects you from a rug-pull, but not from having to read release notes. Fifth, multi-database support is Postgres-only (no MySQL/MariaDB option as of this writing), so if your stack is MySQL-based, Docmost does not fit without running a second database. Name these before you migrate a team.

Finally, the collaboration model assumes trusted users. Docmost's RBAC is space/member-level, not the fine-grained field-level permissions an enterprise might want; for a self-hosted team wiki that is usually enough, but for "different departments must not see each other's spaces" with audit trails, you are in paid-tier territory again. The limitations are bounded and mostly honest; the paid line is the one to internalize.

11. Docmost vs BookStack vs Wiki.js

This is the comparison operators in this series actually make, because all three are self-hosted wikis and they optimize for different truths. BookStack (covered earlier) is MIT, PHP/Laravel, no real-time collaboration, simplest deploy, bus-factor one — the pick when you want docs you control with the least operational weight. Wiki.js is AGPL-3.0, Node with a Git backend (every page is a file in git, version-controlled), slower maintenance, Apollo Server EOL baggage — the pick when git-backed docs and the strongest copyleft matter more than real-time editing. Docmost is AGPL-3.0 core, TypeScript, Postgres+Redis, real-time collaboration, diagrams — the pick when the Notion experience and live co-editing are the point.

License-wise, BookStack's MIT is the most permissive (no copyleft at all), Wiki.js's AGPL is the strongest network copyleft, and Docmost's AGPL core sits with Wiki.js on copyleft while adding the proprietary EE layer BookStack and Wiki.js do not have. So Docmost is the most "open-core" of the three, BookStack the most purely open, Wiki.js the most copyleft-without-commercial-trap. Your priority — simplicity, copyleft purity, or collaboration features — picks the tool.

Data model is the other axis: BookStack is a database app with a rigid hierarchy; Wiki.js is a Git-backed file system with a DB index; Docmost is a database app with a flexible space/page tree and real-time. If "docs in git" is non-negotiable, Wiki.js. If "lightest deploy" wins, BookStack. If "my team edits together live," Docmost. They are not enemies; they are points on a spectrum, and Docmost sits at the collaboration-heavy end.

12. What It Honestly Costs to Run

Docmost the core is free (AGPL-3.0). The infrastructure cost is a small container stack: the app, Postgres, and Redis. For a team wiki, a 2 vCPU / 4 GB RAM node runs it comfortably alongside other tools; the database is the heavier neighbor but modest for doc volumes. Reverse-proxy it behind your existing Caddy or Traefik, add TLS, and the marginal cost is near zero if you already run a server.

The paid cost appears only if you need the EE features: SSO, audit logs, SCIM. At the Business tier's per-user pricing, a 20-person team pays a fraction of a Notion Business bill for the same compliance surface — so the "save money vs SaaS" argument holds even when you pay. The honest framing: Docmost is cheaper than Notion at every tier, free at the bottom, and the paid tier buys governance not the wiki. For a sovereignty operator who runs free core, the cost is infrastructure plus the responsibility of backups and hardening, same as every self-hosted tool.

The time cost is the familiar one: deploy the stack, enable SSO only if you pay, configure spaces and permissions, migrate content, and retrain the team. An afternoon to stand up, a week to migrate and adopt. Lower than a from-scratch wiki, higher than signing into SaaS. The trade is ownership, and for this blog's reader that trade is the point.

13. Backups and Disaster Recovery

Because Docmost is a database app, your backup unit is Postgres plus the attachment storage. A nightly pg_dump captures all pages, history, users, and structure; the attachments (local disk or S3) get backed up by whatever backs up your object storage. Redis is mostly cache and collaboration state — you can usually rebuild it, but snapshot it too if you want zero friction on restore.

The version history is your in-app safety net: a bad edit is recoverable via history (and diffable in 0.96), so user error is rarely catastrophic. A dropped database is, which is why the dump is the real net. Test a restore quarterly — spin up a throwaway Docmost, load the dump, confirm pages render. An untested pg_dump is a hope, not a backup. For a team wiki that is the system of record for institutional knowledge, the restore test is the single most important operational habit, and it is the same discipline as every other tool in this series.

14. Upgrading and Staying Current

Docmost moves fast, and upgrades need attention because the stack includes a Node runtime bump. The 0.96 line jumped to Node 26 and pnpm 11; if you build from source, match your environment before upgrading, or use the official Docker image (which bundles its own runtime and is unaffected). Docker users have the easier path: pull the new image, recreate the container, run migrations. The app auto-migrates the database on boot, but read the notes first — a fast-moving project occasionally changes a default or a config key.

Pin your image tags in production rather than running :latest, so an unexpected release cannot ambush you. Take a pg_dump immediately before a major bump; if something is wrong, restore and roll the tag back. Because the data lives in Postgres, not the app container, a rollback is a container swap plus a restore, not a loss. The collaboration server (Hocuspocus) upgrades with the app, so keep them aligned to avoid sync weirdness. As everywhere in this series, the operator who plans the upgrade has a boring, reliable life.

15. The Sovereignty Verdict

Docmost is what a Notion alternative looks like when the core is honestly AGPL-3.0 and the enterprise layer is a separate, clearly-drawn commercial product. You get a real-time, diagram-rich, self-hosted wiki with your data in your Postgres and no vendor in the loop — for free, if you can live without SSO and audit logs. You pay only when governance requires it, and even then you pay less than the SaaS you are replacing. That is the right open-core shape, and the AGPL core is the sovereignty guarantee that keeps it honest.

For this blog's reader — someone already running a stack and willing to own it — Docmost slots in beside your other sovereign tools as the team's brain: backed by your database, fronted by your proxy, guarded by your SSO. The cost is a three-container deploy and the responsibility of backups; the return is institutional knowledge no vendor can read, monetize, or hold hostage. Pair it with BookStack when you want simple docs and Wiki.js when you want git-backed docs, and you have the self-hosted wiki spectrum covered. Run Docmost, own the pages, and your team's memory stays yours.

16. A Real Migration Scenario: Ten People Off Notion Business

Make the value concrete. A ten-person team on Notion Business pays roughly $150/month for seats plus the compliance surface they actually use (SSO, export). They migrate to Docmost self-hosted on a 2 vCPU / 4 GB node they already pay for. The core wiki costs $0. They accept email/password auth for the first quarter, then buy the Business tier only for the three admins who need SSO — a few dollars a month instead of $150. The docs now live in their Postgres; Notion never sees them again.

The migration itself: run the Notion importer, spend a day cleaning the 10% of blocks that did not map, and rebuild the team's diagram-heavy pages using Docmost's native Draw.io (which actually improves them). The hard part is the human one — the team keeps typing the old URL for a week. After that, the wiki is faster (no SaaS latency), the diagrams are inline, and the export is a pg_dump they control. The savings are real and the sovereignty is total; the only thing they paid for was governance they could have skipped. That is the Docmost deal in one scenario.

17. Security and Compliance: What the Layers Actually Protect

Docmost's security model has three relevant layers. At rest, the 0.96 release added a global AES-256-GCM encryption module at the server level, so sensitive data handled internally is encrypted — but this is application-level encryption, not a substitute for encrypting your Postgres volume at the OS or disk layer, which remains your job. In transit, you terminate TLS at your reverse proxy (Caddy or Traefik, both covered in this series) and keep the app internal. At identity, the free core offers email/password; SSO (SAML/OIDC/LDAP) is an EE feature, so if your policy requires SSO, that is the paid line, and it is where Docmost, Inc. earns its keep.

Audit logging is the other compliance hinge, and it is also EE. The free core tracks version history per page (you can see and diff changes), but it does not produce the centralized, user-action audit trail most frameworks (SOC 2, ISO 27001, HIPAA-eligible workflows) expect. The EE tier's SIEM integration (Splunk, Datadog, generic HTTP) in 0.96 ships those events out. So the honest compliance picture: self-hosting gives you data residency and GDPR-ready control; audit-trail completeness for formal frameworks requires the paid tier. Name that before a compliance review surprises you.

18. AI and MCP: The v0.96 Enterprise Surface

Docmost is leaning into AI-assisted documentation, and v0.96 shows exactly where the line is drawn. The core gets AI chat features (admins can configure the built-in assistant), but the enterprise-grade AI governance — MCP OAuth for agents, turbopuffer vector search as an AI-search backend alongside pgvector, and granular AI-chat admin controls — sits in the paid tier. MCP OAuth matters because it lets an AI agent authenticate against Docmost with a proper OAuth flow instead of a static token, which is the safe way to let tooling read or write your docs.

For a sovereignty operator, the takeaway is two-fold. First, the AI features exist and are usable, so "ask the wiki a question" is on the table without a third-party AI SaaS. Second, the governance around AI (who can the agent act as, how is it authenticated, where does the vector index live) is exactly the kind of control an enterprise wants and Docmost charges for. If you run core free, you get basic AI chat; if you want agentic, governed, vector-search-backed docs, that is the EE surface. The pattern repeats: the wiki is free, the enterprise AI governance is the product.

19. Operations: Health, Logs, and Living in Your Stack

Running Docmost day to day means treating it like any other containerized app in your stack. The app exposes standard health behavior your orchestrator can probe, and your reverse proxy's access logs are your first window into usage and abuse — wire them into CrowdSec (covered in this series) and a banned IP never reaches the editor. The real operational surface is Postgres and Redis: monitor the database size (it grows with attachments and history), monitor Redis availability (collaboration breaks if it drops), and alert on disk before the volume fills.

Backups, as covered, are a pg_dump plus attachment storage — automate both and test the restore. Log rotation matters because a busy wiki generates editor and collaboration logs; ship them to wherever your other logs go so a problem is findable. None of this is Docmost-specific; it is "you own a database app now," and if you already run Postgres for other tools in this series (Supabase, Metabase, Firefly III), Docmost shares the operational vocabulary. The learning curve is the familiar one, not a new paradigm.

20. Troubleshooting: The Three Things That Go Wrong

"When collaboration breaks," it is almost always Redis — the collaboration channel rides there, so if Redis is down or unreachable, edits stop syncing even though the app serves pages. Check Redis connectivity first; the app will run without live collaboration but will not co-edit. "When a migration looks empty," it is usually the importer mapping — re-run with explicit column/block mapping, or accept that some blocks need manual rebuild. "When SSO fails," it is an EE feature misconfigured or a tier that does not include it; confirm your tier before debugging the connector.

The reassuring property is that Docmost's failures are local and observable. A page corruption is recoverable via version history; a database problem is a restore; a config error is a container recreate. There is no vendor on the other end of a support ticket, which is the sovereignty bargain — you debug it, but you also own it, and nothing about the failure depends on a third party's uptime. For an operator who already runs a stack, that trade is the point, not a bug.

21. Who Should Run Docmost, and Who Should Not

Run Docmost if: your team wants a Notion-like experience with real-time collaboration and diagrams; you can self-host Postgres and Redis; you value data residency and will accept email/password auth or pay for SSO; you want the AGPL core's copyleft protection. It is the strongest self-hosted pick in its class for collaborative documentation.

Do not run Docmost if: you need a relational database app (use a different tool); you require SSO and will not pay (use BookStack or pair Authelia); you want every page as a file in git (use Wiki.js); you run only MySQL and will not add Postgres; or you want a single-binary, set-and-forget wiki (BookStack is lighter). The decision is "do I want collaborative docs I own, and will I run the stack that delivers them?" If yes, Docmost is mature, active, and honestly licensed. If no, the other wikis in this series fit better.

Related

For the rest of a sovereign, self-hosted stack, these pieces from our series travel with Docmost:

• BookStack: Documentation You Control — the lighter, MIT, no-collaboration wiki for when simplicity beats real-time editing.
• Wiki.js: The Git-Backed Wiki With a Maintenance Bill — the AGPL alternative when every page being a file in git matters more than live co-editing.
• Caddy: The Web Server That Encrypts for You — the reverse proxy to publish Docmost over TLS without touching Certbot.
• Authelia: SSO and 2FA for Everything Behind Your Reverse Proxy — the free SSO layer to put in front of Docmost core if you will not buy the EE tier.
• Penpot: The Open-Source Design Tool That Owns Its Formats — pair it so your docs and your designs both live on infrastructure you control.