Confluence alternatives that use markdown, and where each one actually puts the file

Two tools can both claim markdown support and mean entirely different things by it. In one, markdown is a way of typing. In the other, markdown is the file. That difference never shows up in a feature table, and it is the only part of this decision that still matters the next time your team moves.

So the useful question is not "does it support markdown". It is: when the app is closed, where is the markdown? Baalda, the app this site is for, is one of two tools here that answer that with a path on your own disk. The other one is Wiki.js, and the honest version of this post has to say where Wiki.js is the better pick and where neither of them is the right call.

Does Confluence support markdown?

Only as an input, and only on the way in.

In the legacy editor you can choose Insert, then Markup, then Markdown, and paste. Atlassian's own documentation says what happens next: "Confluence Cloud will convert your markdown to the rich text editor format", and then, flatly, "You will not be able to edit your content using markdown."

Underneath, Confluence has never stored markdown. Atlassian's storage format documentation describes an XHTML-based format used "to store the content of pages, page templates, blueprints, blog posts and comments", and is candid that the name is generous: the format "does not comply with the XHTML definition" because Confluence adds custom elements for macros, so it is really XML with a lot of HTML in it.

That is not a criticism. A wiki with macros, inline comments and dynamic content needs a structured document model, and markdown has nowhere to put a macro. It just means a team saying "we want our docs in markdown" is asking to leave the storage format, not to change an editor setting.

Can you export Confluence to markdown?

Not with anything Atlassian ships.

A space admin can export a space, or a selection of pages in it, to PDF, CSV, HTML or XML. A single page or blog post exports to Word or PDF. Markdown is not on either list, and there is no "export to markdown" button anywhere in the product.

So the real path out is one of two things, and both are conversions:

• Export the space as HTML, then convert the HTML to markdown yourself. This is the route most migration guides describe, and it is where macros, panels, status lozenges and Jira links turn into something approximate or into nothing.
• Buy a Marketplace app that does the conversion inside Confluence and hands you markdown directly.

Either way you are translating a structured document into a flat one, once, by hand or by tool, and checking the result. That cost is real and it is worth saying out loud before anyone promises the migration will take an afternoon.

It is also the reason the next question matters more than it looks. If you pay that conversion cost to get into a new tool, and the new tool puts the markdown straight back into a database, you have bought exactly one migration. The one after it costs the same again.

Which Confluence alternatives actually store markdown?

Here is the set that comes up for this query, read by where the text sits while you are working, not by what the editor looks like.

Two things in that table deserve credit rather than a dismissal.

Outline and BookStack are genuinely not trying to trap you. Outline's documents are markdown on the backend and a collection or a whole workspace exports to markdown. BookStack's own content-storage documentation states the intent directly: "we want to avoid 'locking' users into our platform. We believe data should be portable and to common standard formats", and it keeps the HTML deliberately plain so it stays convertible. If your worry is "can I ever get this out", both are honest answers.

The distinction this post is drawing is narrower than lock-in, and it is this: an export is a moment, and a file is a state. With markdown in a database, the only thing that exists on disk is whatever you last exported, which is out of date the moment someone edits a page. Your grep, your scripts, your backup job, your editor, your local agent and every other tool that reads files are all looking at a snapshot of a thing that has moved on.

Wiki.js is the real alternative in this list, and nobody writing these round-ups seems to notice. Its storage modules connect the wiki "with a local or remote storage provider, to act as backup or source of truth for content", with three modes: sync pulls then pushes in both directions, push always writes out, pull always reads in. Point one at Git or at local disk and the markdown is on a filesystem, continuously, while people are working in the wiki. If what you want is a wiki with page trees and a navigation sidebar, and you want the content in Git, Wiki.js is the answer and you can stop reading here.

What does "the file lives on disk" actually buy you?

It buys you the ability to use the file like a file, while the app is running, without exporting anything.

Baalda is a team second brain rather than a wiki, and its markdown is not a sync target. Each note is one CRDT document reconciled both ways with a plain .md file in a vault folder on your own disk. The app's own bridge module describes the loop: edits in the editor are written out to the file, and edits made to the file by anything else are read back in, with two guards so the loop cannot feed itself.

The part that matters in practice is what happens when something outside the app touches the file. The write is a compare-and-swap. The bridge records the hash of the bytes it last saw on disk and passes that hash to the write:

writeFileAtomic(
  path: string,
  content: string,
  docId?: string,
  expectedSha?: string | null,
): Promise<void | WriteResult>;

If the file no longer hashes to what the app last observed, the write resolves "stale" instead of landing, and the app merges the newer file in rather than overwriting it. The source comment names the exact cases it exists for: "an external editor inside the 300 ms egest window, or a second doc on the same file (a symbolic link, a case variant)".

In plain terms: you can open the same note in vim while a teammate is typing in it, save, and neither of you loses the edit. The file is not a copy of the note. It is the note, on disk, at a path you chose, and the rest of the team has the same file at their own path, kept in step.

That is also what makes the permission layer meaningful rather than cosmetic, since the server decides what reaches each person's disk in the first place. We wrote that part up separately in Obsidian per-file permissions, and the real-time editing half in multiplayer Obsidian.

Where Baalda is the wrong answer

Three places, and they are all worth knowing before you spend a weekend on a migration.

There is no Confluence importer. None. You still export the space as HTML or XML, convert it yourself, and drop the markdown into a vault folder. Nothing about Baalda shortens that job, and a tool with a real Confluence importer will get you moved faster.

It is not a wiki. No macros, no page templates or blueprints, no Jira integration, no approval workflows, no space governance with the depth a large organisation expects. If the reason your team is on Confluence is that four hundred people need a navigable intranet with controlled publishing, this is not the replacement and nothing in this post should be read as suggesting it is. The comparison page is blunter about that than most vendor pages are.

Files on disk are only an advantage if you want them there. Some teams genuinely prefer a database and a web app with nothing to install, no vault folder to keep track of, and no local copies on laptops that walk out of the building. That is a defensible position, and for those teams Outline is a better fit than anything in this post.

What stays true regardless of which one you pick: ask where the file is while the app is running, not what the export menu offers. Most of the market answers that question with "a database, and here is an export button", which is the same answer Confluence gives, with better manners. If that answer is what sent you looking in the first place, there are only two tools above it, and owning the files is the only thing that actually separates them from the rest.