Skip to main content
Wiki.js is an open-source wiki and knowledge base — a modern editor, Markdown, access control, and full-text search. You manage everything from its web UI, served at your *.suji.fr address. This guide covers configuring Wiki.js on Suji. Check the version and release notes shown in the marketplace before installing or upgrading. Wiki.js is maintained upstream; Suji provides the marketplace packaging.

Before you install

Nothing to prepare for the default setup — the template uses a local SQLite database, and you’ll create your admin account in the browser on first run. If you’d rather use your own PostgreSQL or MySQL database, have its host, port, database name, user, and password ready — and make sure it’s reachable from the VM.
Wiki.js has no generated password — the first person to complete the setup wizard becomes the administrator. Do it immediately after install.

Install

Dashboard → Apps → Wiki.js → Install: If you choose PostgreSQL or MySQL, additional fields appear — host, port (5432 for PostgreSQL, 3306 for MySQL), database name, user, and password. The template declares 1 GiB minimum and 2 GiB recommended memory, with a 2 GiB container limit. Small is a starting point if it has enough spare capacity. See Recommended size. Click Deploy. Once the install is running, open its assigned URL, for example https://wikijs-<random>.suji.fr, served over HTTPS through the tunnel.

First connection — set up your wiki

  1. Open the install URL (https://wikijs-<random>.suji.fr).
  2. Wiki.js shows its setup wizard on first run.
  3. Create the administrator account (email + password) and confirm the site URL.
  4. You land in the editor, ready to create your first page.
The URL is public the moment the install is running. Until you finish the wizard, anyone who reaches it can claim the administrator account. Do it right after deploy.
Later visits follow the wiki’s access settings; public pages may be visible without signing in.

Using an external database

The template defaults to SQLite. Check Wiki.js database requirements against the needs of your deployment. If you prefer your own database, pick PostgreSQL or MySQL / MariaDB at install and fill in the connection details.
  • The database must already exist and be reachable from the VM.
  • Grant the database user the permissions required by Wiki.js to create and maintain its own tables; do not use a server-wide administrator account.
  • Changing the database fields does not migrate existing pages or accounts. Plan and test an export/import or database migration before changing a working install.
  • The form defaults to port 5432; change it to 3306 when using a standard MySQL/MariaDB endpoint.

Day-to-day management


Troubleshooting

The setup wizard runs until the admin account is created. Complete it once; afterwards the wiki should retain its configuration. If it keeps reappearing, the database isn’t persisting — check that the install’s volume (SQLite) or your external database is healthy.
Confirm the host is reachable from the VM, the port is right (5432 PostgreSQL / 3306 MySQL), and the user/password/database are correct. The Logs tab shows the exact connection error.
Wiki.js needs an SMTP provider, which isn’t configured by default. Use your mail provider’s documented SMTP settings; port 587 with STARTTLS is a common option. Check outbound connectivity from your VPS. Configure mail in the Wiki.js admin area.
Wiki.js isn’t reachable through the tunnel yet — usually still starting (wait ~30 s, especially after an upgrade). If it persists, the Logs tab shows why the container isn’t up.

Where things live

Back up the configured database and the wikijs-data volume. If you use an external database or storage integration, its data is outside the VPS snapshot and needs its own backup. Uninstalling deletes the volume by default; choose keep data during uninstall to preserve it.
  • The template declares 1 GiB minimum and 2 GiB recommended memory, with a 2 GiB container limit. Start with Small only when there is spare capacity, then measure your workload.
  • Memory scales with concurrent editors, search indexing, and large media uploads. Big, busy wikis → size up.
  • If you run other apps on the same VM, remember the VM’s total CPU/memory is shared.

Reporting issues