How to Self-Host Kanboard in 2026: SQLite, Plugins and Safe Upgrades

A failed Kanboard deployment does not always crash. It may serve a login page while SQLite cannot write because the mounted data directory has the wrong owner. Start with an end-to-end check instead: replace the default login, create a project and task, move it across columns, upload a file and exercise one installed plugin.

That check matches the cataloged purpose of Kanboard: minimal kanban board backed by SQLite. It also exposes missing dependencies, wrong proxy assumptions and ephemeral data earlier than an uptime probe can.

Separate Kanboard from its dependencies

The smallest responsible Kanboard topology contains one private listener on 80, an ingress route and a documented state boundary. The local runtime requirement is a writable data volume and optional SMTP. Keep its lifecycle explicit so moving Kanboard between hosts does not silently change behavior.

Validate the topology by asking a clean client to replace the default login, create a project and task, move it across columns, upload a file and exercise one installed plugin. Watch SQLite locking, attachment volume, background actions and plugin behavior under simultaneous users while it runs. The result tells you whether the next improvement belongs in memory, storage, networking or a separate worker instead of encouraging arbitrary container sizing.

Domains, proxy headers and port 80

TLS issuance is only half of the Kanboard route. Serve the board over HTTPS and set the application URL if plugins need it. Send traffic internally to 80 and forward the external scheme so generated URLs and secure cookies remain consistent.

Use the complete Kanboard scenario from a clean network, not merely the root page. A 502 or certificate failure can be isolated with automatic domain and TLS setup. If traffic reaches the process and SQLite cannot write because the mounted data directory has the wrong owner, diagnose that condition where it occurs instead of stacking redirects.

Make Kanboard startup reproducible

A production-shaped launch is intentionally boring: named state, explicit port and no secret inside the image.

docker run -d \
  --name kanboard \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v kanboard-data:/var/www/app/data \
  kanboard/kanboard:latest

The example is a baseline rather than a complete supporting stack. Confirm the local requirement before exposure: a writable data volume and optional SMTP. Check the effective mounts and listener, then try to replace the default login, create a project and task, move it across columns, upload a file and exercise one installed plugin. Pin the working image before the next restart.

Watch the workload, not only the container

For Kanboard, monitor a transaction rather than a process: replace the default login, create a project and task, move it across columns, upload a file and exercise one installed plugin. Combine its latency and error rate with SQLite locking, attachment volume, background actions and plugin behavior under simultaneous users so an alert identifies the constrained component.

The upgrade rehearsal must cover that database migrations and plugin compatibility deserve a snapshot before a Kanboard image update. Restore, migrate and run the transaction before production replacement. If SQLite cannot write because the mounted data directory has the wrong owner, do not erase data to make startup green; compare version, variables, mounts and dependency reachability in that order.

Prove the Kanboard deployment end to end

A production gate for Kanboard should be executable by someone who did not build the deployment. Give that person the pinned version, a non-sensitive test account and this task: replace the default login, create a project and task, move it across columns, upload a file and exercise one installed plugin. If the instructions require undocumented shell access, the service is not yet operationally ready.

Repeat the gate after replacing only the container. Then restore SQLite database, uploaded files, plugins and configuration into blank infrastructure and prove that projects, task history, users, attachments and plugins return and the restored board accepts a new task. Measure SQLite locking, attachment volume, background actions and plugin behavior under simultaneous users during both successful runs; unexpected differences often reveal a missing cache, index, worker or data mount.

Add a failure drill: submit harmless input near the resource or format limit associated with this boundary: SQLite cannot write because the mounted data directory has the wrong owner. Kanboard should emit a useful error, preserve existing state and recover when the valid condition returns. Save the timestamps and relevant log lines, with secrets redacted. That evidence becomes the reference for the next image or configuration change.

Volumes are only the first recovery layer

Make a recovery manifest for Kanboard: SQLite database, uploaded files, plugins and configuration. Mount /var/www/app/data before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Check ownership and free space now, because a mounted but unwritable path behaves like no persistence at all.

Back up to a failure domain separate from the running server. Recreate Kanboard from its pinned image and verify that projects, task history, users, attachments and plugins return and the restored board accepts a new task. The persistent-volume guide helps translate that exercise into snapshot and retention policy.

Protect the valuable part of Kanboard

A secure Kanboard deployment starts by removing authority. Avoid keeping the default admin/admin credentials; instead, remove admin/admin immediately, restrict project access and review plugins before granting them production data.

Kanboard has no mandatory bootstrap secret in this baseline; protect its actual administrator account or upstream authentication instead. Restrict administrative routes, use private DNS for dependencies and review every bind mount. When logs are shipped centrally, filter secrets and private content before they leave the server.

Where Dockup removes work for Kanboard

A Dockup template should encode the image, port 80, mounts, health timing, domain, TLS and secret delivery. Dockup should preserve the Kanboard runtime settings while the operator confirms this local requirement: a writable data volume and optional SMTP. The same deployment can target Dockup servers or customer-attached capacity.

After the route is live, apply the public setting and try to replace the default login, create a project and task, move it across columns, upload a file and exercise one installed plugin. Back up SQLite database, uploaded files, plugins and configuration and keep the restore exercise in the operating plan; those are Kanboard responsibilities that remain visible after infrastructure provisioning.

Frequently asked questions

What does Kanboard need for a production deployment?

Route the Kanboard container on port 80 through one HTTPS origin. The local runtime requirement is a writable data volume and optional SMTP. Do not call Kanboard ready until you can replace the default login, create a project and task, move it across columns, upload a file and exercise one installed plugin.

Which Kanboard data belongs in a backup?

Persist /var/www/app/data and include SQLite database, uploaded files, plugins and configuration in the same recovery manifest. A clean Kanboard restore passes only when projects, task history, users, attachments and plugins return and the restored board accepts a new task.

Does Kanboard require HTTPS behind a reverse proxy?

Use HTTPS for the public Kanboard origin and keep port 80 on the internal route. Apply the Kanboard setting correctly: serve the board over HTTPS and set the application URL if plugins need it. For Kanboard, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a Kanboard upgrade be tested?

Restore current Kanboard state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because database migrations and plugin compatibility deserve a snapshot before a Kanboard image update. Keep the previous Kanboard image until its data-migration and rollback boundary are understood.