What changed in Notion's pricing
On 13 May 2025, Notion announced Notion AI for Work and a new price grid: full AI — today the Notion Agent, AI meeting notes and enterprise search — is reserved for the Business and Enterprise plans. The Free and Plus plans now only get a limited number of trial responses. New subscriptions switched the same day; for existing customers whose price changed, the increase applied at their first renewal after 13 August 2025.
As of 7 November 2026, the notion.com/pricing page shows, for a visitor in the euro area and on annual billing, €9.50 per member per month for Plus and €19.50 for Business. An agency of 15 people on Business therefore pays €292.50 a month, whether AI is used or not. A line that did not exist before comes on top: Notion credits, an add-on for the Business and Enterprise plans that funds custom agents and AI usage beyond the allowance included in each seat, billed at $10 per 1,000 credits per month.
For an agency that did not use AI, this is an imposed increase with no perceived benefit. If it also keeps separate workspaces for its clients — each billed per seat — the bill follows the number of active clients on the platform directly.
What makes the increase non-linear for an agency
- Separate client workspaces — each distinct Notion workspace consumes its own seats; a portfolio of 10 clients with 2 users each means 20 extra Business seats.
- AI built into the seat — the Business plan price includes Notion AI whether the team uses it or not; there is no cheaper "AI-free" Business plan.
- No mid-tier plan with AI — Plus only offers a limited trial; an agency whose workflows depend on AI has to move every member to Business.
- Billing on actual seats — at the start of each billing period, the number of paid seats is synchronised with the number of workspace members; there are no floating licences or quotas shared between workspaces.
- Agents billed separately — custom agents consume Notion credits bought on top, at workspace level: one more line, independent of the seat count.
- Portfolio growth = linear bill growth — there are no economies of scale: going from 10 to 20 clients mechanically doubles the Notion cost if workspaces stay separate.
Docmost: what the AGPL-3.0 licence covers
Docmost's core is published under the AGPL-3.0 licence, whose LICENSE file is available in the github.com/docmost/docmost repository; version 0.97.0 was released there on 25 October 2026. This licence allows commercial use without royalties: an agency can deploy Docmost for its teams and for its clients without paying a licence fee to the publisher. The only AGPL constraint relevant to this use is the following: if the agency modifies Docmost's source code and exposes that code as a network service, it must publish its changes under the same licence. In a standard deployment, without a fork, this constraint does not apply.
Watch the scope, however. The README states that the apps/server/src/ee, apps/client/src/ee and packages/ee directories fall under a separate enterprise licence. According to the official price grid, the paid editions, unlocked by a licence key, add SSO (SAML 2.0, OIDC, LDAP), multi-factor authentication, API keys, the Confluence importer, databases ("Bases") and attachment search in the Business edition — $6 per seat per month on annual billing, ten seats minimum — then audit logs, SCIM and SIEM integration in Enterprise. The path described here — Notion import, spaces, groups, permissions, comments and full-text search — needs none of them.
Docmost vs Notion: the honest table
Scroll the table
| Feature | Notion Business | Docmost |
|---|---|---|
| Nested pages and rich editing | Yes | Yes — real-time collaborative editor |
| Team wiki / knowledge base | Yes | Yes — main use case |
| Multi-team spaces | Yes | Yes — isolated spaces with permissions |
| Page history and restore | Yes | Yes — version history |
| Comments and annotations | Yes | Yes |
| Diagrams (Draw.io, Mermaid, Excalidraw) | Limited (embed) | Yes — built-in editors |
| Relational databases | Yes — core feature | Paid edition only (Bases: table and kanban; relations not documented) |
| Kanban, gallery, calendar views | Yes | Kanban in paid edition; no gallery or calendar |
| Formulas and computed properties | Yes | Paid edition (Bases Formula property) |
| Public API | Yes (official REST API) | Paid edition (API keys) |
| Native Slack integration | Yes | No — no native integration |
| Native GitHub integration | Yes | No — no native integration |
| Notion AI (summaries, agents) | Included in Business, agents via credits | Not in the free edition |
| Monthly cost (15 people) | 15 Business seats (€292.50 on annual billing, euro area) | VPS cost only (free edition) |
Which use cases migrate well — and which do not
The distinction matters and deserves a clear answer before you commit to a migration.
Docmost covers well: the internal knowledge base (procedures, onboarding, technical guides), documentation delivered to clients (specifications, meeting reports, product tutorials), project wikis where pages are the unit of work, and technical documentation (code, API, architecture). These are cases where Notion is used as a structured collaborative text editor — and that is exactly what Docmost does.
In its free edition, Docmost does not cover: project portfolio management in databases with filtered views, dashboards with formulas and rollups, light CRMs built on relational databases, and workflows that rely on the Notion API to synchronise external data. The paid edition closes part of the gap with its Bases (table and kanban views, computed properties), without documented relations or calendar views. If your Notion usage relies on these features, Docmost is not a replacement — it is a different tool. In that case, looking at NocoDB or Grist for the data layer, and Docmost for documentation, is a more realistic architecture.
Prerequisites for hosting Docmost on a VPS
Docmost runs with three containers: the application itself, PostgreSQL for persistence, and Redis for real-time collaboration and job queues. The repository's official Compose file uses postgres:18 and redis:8, the latter started with AOF persistence and the noeviction policy. These three services run comfortably on a VPS with 2 vCPU and 4 GB of RAM for a typical agency team; with many simultaneous editors, 8 GB gives comfortable headroom. Storage depends on the volume of files attached to pages — plan at least 20 GB outside the databases. Files go by default into the container's /app/data/storage volume, or into an S3 or Azure bucket (STORAGE_DRIVER).
Three settings deserve attention before the migration. The official Compose publishes port 3000 on every interface: restrict it to the loopback so that only the reverse proxy is exposed.
ports:
- "127.0.0.1:3000:3000"Docmost then caps uploads at 50 MB and imports at 200 MB by default; an agency's Notion export quickly exceeds the second threshold. Raise both limits in the environment (official list of variables) and align nginx's client_max_body_size:
FILE_UPLOAD_SIZE_LIMIT=100mb
FILE_IMPORT_SIZE_LIMIT=500mbFinally, configure an SMTP server (MAIL_DRIVER=smtp, SMTP_HOST…): without it, member invitations are not sent.
Other prerequisites: Docker and Docker Compose, a reverse proxy (nginx or Caddy) for HTTPS, and a domain name pointing to the server (wiki.yourdomain.com). The complete installation guide is documented in the article hosting Docmost on a VPS — this article focuses on the migration decision and the import procedure, not on system configuration.
Migrating Notion content to Docmost
Export the Notion workspace
In Notion, open Settings → General → Export all workspace content (from the web or the desktop app). Choose Markdown & CSV or HTML, with subpages and files. Notion emails you a download link: it expires after 7 days, and exporting a large workspace can take up to 30 hours (official help). The resulting ZIP contains the pages, the databases as CSV and the uploaded files: this is the file Docmost imports.
Check the ZIP contents before importing
Unzip the archive locally and browse the structure. Each page becomes a
.md(or.html) file. Notion databases (tables, kanban boards, calendars) are exported as.csv— Docmost will not import them as databases, but as static content. Identify at this stage what will be lost (views, formulas, relations) and what will survive (text, headings, structure). Also spot the links that still point to Notion — those are the ones to fix after the import:unzip -q notion-export.zip -d notion-export grep -rl 'notion.so/' notion-export grep -ro 'notion.so/[^) "]*' notion-export | wc -lCreate the spaces in Docmost
In Docmost, create one space per team or per client before importing. A Docmost space carries permissions and isolation, like a Notion workspace. Naming spaces consistently with the Notion exports makes matching easier.
Run the import in Docmost
In the target space, click the … menu next to the Pages header in the sidebar, then Import pages. Choose Notion — the dedicated option, not the generic Markdown import — and upload the exported ZIP as is, without re-compressing it. Docmost processes the archive and rebuilds the page tree, preserving parent-child relationships.
Check the import page by page
After the import, go through the critical pages. Things to check: internal links between pages, starting with those spotted in step 2; images and attached files, which should come from the ZIP; and blocks that used to be Notion databases, which appear as text or simple tables — rework them manually if needed. A link that still points to
notion.sowill stop working the day the Notion workspace is closed: replace it with the URL of the Docmost page.Configure permissions per space
Docmost manages permissions at space level: a space can be restricted to its invited members or open to the organisation. For client spaces, create one group per client (
client-x-group), invite the relevant members by email, and assign that group to the space with the Editor or Reader role as needed. Page-level permissions and SSO belong to the paid edition.Phase out the Notion workspaces gradually
Do not delete the Notion workspaces straight away. During a transition period (two to four weeks depending on team size), keep Notion accessible read-only while teams find their feet in Docmost, and have two or three people work in both tools to spot what is missing. Put a banner in each Notion workspace announcing the final switch-over date, then run one last full export — Notion lets you export as many times as you need — before cancelling.
Back up PostgreSQL before every large import
A large Notion ZIP import writes many pages to the database in a short time. Before importing a major space, take a PostgreSQL backup from the Compose directory:
cd /opt/docmost
docker compose exec -T db pg_dump -U docmost docmost > backup-before-import.sqlIf the structure is imported badly, restore this file into an empty database (after recreating it) rather than on top of the existing one: you return exactly to the previous state without reinstalling the instance.
What the migration does not solve — an informed decision
Two trade-offs deserve to be laid out before committing.
First trade-off: if your teams use Notion databases to run projects (task tracking, client pipeline, operational dashboard), free Docmost does not replace that part. The migration solves the cost of documentation, not the management of structured data. These are two distinct needs that deserve distinct tools. AppFlowy is often cited as the closest alternative to Notion's databases, but check its model before committing: the AGPL AppFlowy-Cloud repository is archived, and self-hosting now goes through a "SelfHost-Commercial" repository and Docker images built from a commercial server codebase.
Second trade-off: the migration has a real cost in time. Reorganising imported content, reconfiguring permissions, training teams and clients on a new interface is a non-trivial investment. For an agency with a stable portfolio and mostly documentary content, the maths is generally favourable from 10 Business seats. For an agency whose Notion is deeply embedded in its operational workflows, a partial migration (Docmost for documentation + another tool for data) is the most realistic path.
To structure the decision before starting, the SaaS to self-hosting migration checklist raises the right questions in the right order.
Troubleshooting: common errors during installation and import
Four errors come up regularly in Docmost's GitHub issues and in migration feedback.
Error: connect ECONNREFUSED 127.0.0.1:5432 — Docmost cannot find PostgreSQL. With Docker Compose, first check that DATABASE_URL targets the service name (db) and not localhost, then that the Docmost container does not start before PostgreSQL has finished initialising: a depends_on directive with condition: service_healthy and a PostgreSQL healthcheck (pg_isready) in docker-compose.yml solve the problem.
Import rejected, or stuck on "Processing…" — A sign of a ZIP that exceeds FILE_IMPORT_SIZE_LIMIT (200 MB by default), a reverse proxy cutting the request (client_max_body_size, timeout) or a stopped Redis. Raise the limit, check that Redis is running (docker compose ps) and retry the import on a subset of pages first.
Markdown import fails while HTML works — Reported as early as 2024 (issue #91 in the repository, closed since): the Markdown parser can stumble on Notion exports containing non-standard extensions (nested metadata, special blocks). Redo the export in HTML: Docmost accepts both formats from the same dialog, and HTML gives more reliable results on complex exports.
Pages imported without images, or co-editing that does not sync — The Notion workspace export includes uploaded files: if images are missing, check that you imported the original ZIP and not an archive re-compressed without its folders. If two writers do not see each other's changes live, it is almost always the reverse proxy: it must forward the WebSocket Upgrade and Connection: upgrade headers.
