Does anyone run a wiki software in EE?

Hello,

I am still looking for a self hosted alternative to Atlassian Confluence.

The TrueCharts catalog had quite a few options but the iX one does not. I’m interested not only in features but also operational simplicity, so I am asking here if anyone already deployed a complete solution via a custom app?

Bluespice looked promising but they discontinued their “single container” image.

I am a bit at a loss on how to do e.g. LAMP plus wiki with multiple containers.

Thanks and kind regards
Patrick

I run TrueCharts’ wiki.js under Dragonfish. Obviously the TC app doesn’t help you, but wiki.js publishes a Compose file that pulls up just fine in EE:

Discover apps → Kebab menu → Install via YAML, paste it in.

If you want TLS termination and the like, a reverse proxy will take care of it, something like NPM:

1 Like

I have Caddy on OPNsense - thanks :wink:

wiki.js is one product I tried extensively back in the TC days. Unfortunately the attachment handling is not yet fit for my use case. General usability is the best I have seen so far - after Confluence.

Waiting for 3.0 … :frowning:

Lots of ways of handling the “reverse proxy” point, of course.

Agree that this aspect is kind of rough.

The only other wiki software I’ve spent much time with is Dokuwiki, and I’d consider wiki.js considerably better.

BookStack might be worth a look? Afaik it isn’t super flexible, but if what it does fits your use case it offers a very Confluence-esque WYSIWYG editor.

Very interesting. Might be a great fit for a project my wife is working on (currently in MS Word with all the usual limitations).

But looks like it’s not quite for me. We use Confluence as a collaboration tool in the board of directors for a parent-teacher organisation.

Absolute must haves:

  • user management and authentication first, home page should be a login dialog, no visible content for unauthenticated connections
  • hierarchical page tree with navigation to the left, no orphaned pages - every page is somewhere in the tree
  • attachment name space per page - we have dozens of PDF documents named “invoice-foo” and the discerning factor is whether they are on the page “invoices 2024-12” or the page “invoices 2025-01”; I cannot train my users to use fully qualified names

Typical workflow

  • new month, I create a new page “invoices 2025-01” beneath the page “2025” in the tree, beneath the page “finances” in the tree
  • I have something that must be paid
  • I upload the invoice, write a header and a paragaraph of documentation like “for the printed yearbook as agreed on the board of directors meeting in November → link to meeting notes”
  • task (Confluence has these) for person X: authorise
  • task for person Y: make payment

This works great for us and I would love to get it back out of Atlassian’s cloud again. We were perferctly happy with self hosted Confluence …

Main things many wikis get wrong for the “collaboration” use case:

  • all pages public by default (not really a problem, but …) combined with clumsy configuration to enforce a login
  • flat page namespace - pages can be “anywhere” and must be manually linked; no worky with my users; everything MUST be rooted in a page tree like a filesystem tree
  • global namespace for assets - nope; again, they drag & drop attachments from their email inbox into the proper page which is all I can ask for

wiki.js is really really nice. I hope they fix the asset/attachment issues soon.