Up and running before the kettle boils.
Cardinal.js needs PostgreSQL 16 or later. Set the first admin in the environment and you skip the forced password change on first login.
services: db: image: postgres:18 environment: POSTGRES_DB: cardinal POSTGRES_USER: cardinal POSTGRES_PASSWORD: change-me volumes: [ db-data:/var/lib/postgresql ] wiki: image: registry.gitlab.com/ingentis/cardinaljs:0.1.0 depends_on: [ db ] environment: DATABASE_URL: postgres://cardinal:change-me@db:5432/cardinal ADMIN_EMAIL: [email protected] ADMIN_PASS: a-long-passphrase volumes: [ wiki-data:/wiki/data ] ports: [ "3000:3000" ] volumes: db-data: wiki-data:
Run docker compose up -d, put a TLS-terminating proxy in front, and sign in with the admin you set. Building from source? The README on GitLab has the steps.
Sign in
ADMIN_EMAIL and ADMIN_PASS are read once, on first boot against an empty database. Set both and you land in an already-secured instance; leave ADMIN_PASS out and a random password is printed once to the startup log.
Connect your sign-in
Local accounts work out of the box. Add OIDC, SAML, LDAP or another provider under Admin, with passkeys and TOTP alongside.
Connect an agent
Profile → API keys issues a personal access token with an expiry, narrowed if you like to permissions, one site and the classification levels it may read. Point any MCP client at /_mcp with it.
Bring your existing wiki
Build the migrate command for your 2.5 database, dry run included.
Backups, upgrades, TLS, air-gapped installs
The operations guide on docs.cardinal.wiki, itself a Cardinal.js instance.
Sign-in, classification, tokens
How access is decided, and how to scope what an agent can see.