On 18 September ClewWiki had no releases at all. When I wrote about page claims, there was no image and no npm package: you built it from source or not at all. Seventeen days later version 0.9.0 is out. That is the tenth tag in a row, the image is on GHCR, and the MCP server installs with npx.
This article is for people choosing a wiki for their team who want to keep it on their own hardware. No agents, no MCP here; they get their own article. This one covers what people need: how to install it, how to bring colleagues in, how to move existing pages over, and where the project is still weaker than tools with years behind them.
What it takes to run#
Docker with Compose, git and openssl. That's it. No Redis, no mail server, no account with a third-party sign-in provider. The whole stack is the application and PostgreSQL 16.
git clone https://github.com/Dodecaidr/clewwiki.git
cd clewwiki
cp .env.example .env && chmod 600 .env
sed -i "s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=$(openssl rand -hex 32)|" .env
sed -i "s|^BETTER_AUTH_SECRET=.*|BETTER_AUTH_SECRET=$(openssl rand -base64 48)|" .env
docker compose up -d
docker compose logs web | grep "setup token"On macOS, write sed -i '' instead of sed -i. Then open http://localhost:3000, paste the setup token from the log and create the first administrator. There are no default passwords, so there is nothing to guess.
On a server you need two more things: BETTER_AUTH_URL set to your public https:// address, and a reverse proxy in front of the app. The application speaks plain HTTP and publishes its port on 127.0.0.1 only, so TLS stays your job. docs/deploy.md walks through Caddy, Traefik and nginx.
The short dependency list is deliberate. In a small team the wiki is often set up by someone with neither the time nor the wish to run four services. Every extra container is one more thing that goes down on a Saturday.
Bringing people in without a mail server#
There is no open sign-up. A person gets into the wiki one of three ways.
An invitation link. An administrator enters an address and a role under Members and gets a link. It is shown once, works once and lives for seven days. No email goes out: you hand the link over yourself, in a chat or in person. That is why an instance without SMTP is a complete one. Only a hash of the link is stored.
A request to join. If administrators switch it on, the sign-in page offers Ask to join. The person leaves a name, an address, a password and a note, then sees "waiting for approval" until an administrator approves them with a specific role or rejects them. Nobody lets themselves in. Five requests an hour per client address.
Single sign-on over OpenID Connect. Three variables (OIDC_ISSUER, OIDC_CLIENT_ID, OIDC_CLIENT_SECRET) put a button on the sign-in page. Password sign-in keeps working, so a provider that goes down does not lock the administrator out. The provider decides who someone is, not whether they get in: a profile without email_verified is refused, OIDC_ALLOWED_EMAIL_DOMAINS narrows it by domain, and membership stays an administrator's call until you explicitly turn on OIDC_SIGN_UP.
There are three roles. An administrator manages members, agent tokens and spaces. An editor writes pages, takes part in discussions and reviews what agents changed. A viewer, added in 0.6, is for the people a wiki is written for: a product manager, a tester, a client's engineer. A viewer reads everything they can see (pages, discussions, history, search, exports) and changes nothing. The limit sits where a read-only agent token's does: a request that needs more gets 403. The last administrator can be neither demoted nor removed.
A forgotten password used to mean removing the person and inviting them again, which made a new account. Now an administrator makes a reset link: single use, valid for 24 hours, stored as a hash, and it ends every session of that account once used.
Several teams on one server#
Version 0.8 added organizations. One instance holds several, each with its own members, spaces, agent tokens, administrators and settings. One account can belong to several and switch between them from the menu next to the logo, and every organization has its own entrance at /o/<address>.
Inside an organization there are spaces per project, including restricted ones that only their members can see. Removing a person from one organization keeps their account and their membership elsewhere.
For a studio or agency that keeps documentation for several clients, this is exactly the case that used to mean one wiki per client.
Moving what you already have#
Nobody picks a wiki they cannot move into. Every import into ClewWiki goes through a staging step: you see the page tree it would create, each page's path, its Markdown and a note on anything that did not convert. Nothing exists until you press the button.
Where you can move from:
- A Confluence space: Cloud over REST API v2, your own Server or Data Center over v1. The hierarchy, headings, lists, tables, code blocks with their language, info panels, expand blocks, links between imported pages and images all come across. With files switched on, attachments come too, with their earlier versions, dates and comments.
- A Notion export and a Markdown archive, with the images and files their pages link to.
- PDF files up to 200 MB.
The way out is just as wide: a page exports to Markdown or HTML, a space to a ZIP, optionally with its files. Pages are stored as Markdown, so leaving ClewWiki means downloading an archive.
The limits matter here, so I'll name them. Comments, labels, restrictions and page history are not read from Confluence. A macro with no Markdown equivalent (Jira lists, page trees, includes, charts) becomes a visible note with its name instead of working content. The Server and Data Center importer was checked against a live public instance and against fixtures, but it has no years of use behind it. If your wiki runs on macros and the Marketplace, the move will not be painless, and docs/compare.md in the repository says exactly that.
Why this is a live question at all: Atlassian ends Data Center on 28 March 2029, when such installations become read-only, and has not sold it to new customers since spring 2026. Teams that kept their wiki in-house for security or legal reasons still have those reasons. The product is what's leaving.
Files next to the documentation#
Since 0.7 a page can carry files of any type: a build, an installer, a specification. I modelled it on how teams actually publish releases.
Upload a file with a name the page already has and you get the next version behind the same link. The link always serves the latest, so you can paste it into release notes once and forget it; ?version=3 pins a specific one. The same bytes a second time add nothing. Restore makes an old version the latest by adding it as a new one, so a version that someone has downloaded never changes.
Whoever watches the page or the space sees the new version in their inbox. Files live on a local disk or in any S3-compatible bucket. A build pipeline publishes one with a single command:
curl -fsS -X PUT --data-binary @dist/app-2.4.1.apk \
-H "Authorization: Bearer $CLEWWIKI_TOKEN" \
"https://wiki.example.com/api/v1/pages/$PAGE_ID/files/app-2.4.1.apk?note=Signed%20build"The token needs the pages:write scope and nothing else. Repeating the same request returns 200 instead of 201 and creates no new version, so CI retries are safe.
Issues and spreadsheets inside pages#
In 0.8 the wiki learned to look outward.
Issue trackers. YouTrack, Jira and any tracker with KEY-123 style keys. An organization administrator gives the address, the project keys and the name of an environment variable that holds a read token. The token itself never enters the database. From then on, issue keys in text become links, and a page lists the issues it mentions with their status and assignee. From the editor you can insert an issue in full, with its description and comments, or a table of issues from a YouTrack query or JQL.
One caveat I won't hide: the YouTrack and Jira clients are tested against recorded API responses, not yet against a live instance. If you have a test project, feedback would be very welcome.
Spreadsheets. The Import table or document dialog takes an Excel workbook (.xlsx), CSV and TSV, including semicolon-separated files the way Russian or German Excel saves them, and inserts the sheets as tables. Cells come across as they are shown: a formula as its result, a date as a date, hidden sheets skipped. A Google Sheets or Google Docs link shared with "anyone with the link" works too. The other way, a page with tables exports to .xlsx: one sheet per table, named after the heading above it, with a bold, frozen header row. All of it is the project's own code, with no spreadsheet library. The old binary .xls is not read.
Where the team sees what ships#
Version 0.9.0, released on 5 October, adds a Development section to every space. It answers the question small teams ask on every call: "is this in the release yet?"
The section reads the git repository linked to the space and keeps a line of work for every branch: its last commit, how far it is ahead of and behind the default branch, whether it is merged, whether it was deleted. Each line carries a goal, its tracker issues with their state, a documentation page and "problems", which are discussions about whatever blocks it. When a problem is resolved, the decision is written as a page in that line's documentation.
The part I find most useful is the highlighted list of work merged with no release: changes already in the default branch that no planned release picked up. Those are exactly the things that later surface as "did we ever actually ship that?". A release refuses to be marked shipped while any of its lines are unmerged. You can ship anyway, but that goes into the audit log together with what was left out.
What is not there yet#
An honest list, the same one the README has:
- SAML and LDAP. Single sign-on speaks OpenID Connect only, with no directory sync.
- A mobile app. The web interface works on a phone; there is no native client.
- Years in production. The first tag is from 18 September 2026. The neighbours in
docs/compare.mdhave between three and twenty-plus years. Migrations between 0.x versions are frequent for now, and backing up the database before an upgrade is not a formality. - A community or a company behind it. This is an open-source project by one author. If you need a vendor with an SLA, ClewWiki is not for you right now.
What you get in return: one edition under AGPL-3.0, where everything above is free and not hidden behind a per-seat tier, and a stack that comes up with one command. The interface is in English and Russian.
Where to start#
Bring up an instance on a laptop with the commands above, import one small space and look at the staging screen. Ten minutes with it tell you whether your wiki will move or hit a wall of macros. The code, docs and issue tracker are in the GitHub repository, and the project overview is on the ClewWiki page.
If your team has AI agents connected to its wiki, or soon will, the next article covers what they get in 0.9.
