# Blossom: a self-hosted markdown editor with cloud sync and a built-in image host

> Blossom is a Java-based markdown editor you deploy on your own server, bundling note sync, image hosting and a dynamic blog. It suits people who want Obsidian-style local ownership without giving up multi-device access, and it asks you to run MySQL behind it.

**blossom-editor/blossom** — A markdown editor that you can deploy on your own servers to achieve cloud storage and device synchronization（支持私有部署的云端存储双链笔记软件）

- Repository: https://github.com/blossom-editor/blossom
- Website: https://www.wangyunf.com/blossom-doc/index
- Stars: 3,797 · Forks: 336
- Language: Java
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/blossom-editor-blossom

## The problem Blossom targets: notes you own, reachable from every device

Most markdown editors force a choice. Local-first tools keep your files on disk and make synchronization somebody else's problem. Cloud note services synchronize well but hold the data. Blossom takes the third position: a markdown editor you deploy on your own servers, so the storage and the sync endpoint are both yours. The README describes it as a cloud double-linked note application supporting private deployment, where notes, images and personal plans live on your server and synchronize in real time across devices. The stated clients are Windows, Mac, a web client and a web mobile client.

The second problem is images. Anyone who writes markdown with screenshots eventually wires up a third-party image host, and that host becomes a dependency with its own availability and link-rot profile. Blossom's README states it does not depend on any third-party storage or image host, that it is itself the image host, and that it provides image management, accidental-deletion protection and bidirectional binding between images and articles. That binding is the part worth noting: an image is not just a URL pasted into a document, it is a record with a relationship to the article that references it.

Who is this for? People who already run a server, who write in markdown, and who want a blog generated from the same corpus as their notes. The README lists planning, to-do items, quick notes, a pomodoro timer, multi-user support, word counts, word-count charts, an editing heatmap, weather and theme settings. That is a wider scope than a note editor, and it tells you the intended user is treating this as a daily workspace rather than a scratchpad.

## How the pieces fit: backend, editor, web client and a MySQL dependency

The repository layout is the clearest statement of the architecture. At the top level there are three application directories: blossom-backend/, blossom-editor/ and blossom-web/, alongside doc/ and docker/. The primary language is Java, which places the backend in the JVM ecosystem and, given the deployment command, in a container with a MySQL 8 database beside it.

That split explains the data flow. The backend owns the database and the image files. The editor is the client you write in. The web module serves the browser and mobile-web experience, which is why the README can list a web client and a web mobile client as separate surfaces from the desktop editor. Synchronization happens against the backend, not peer to peer, so the server is the source of truth and every device is a replica.

The markdown itself is deliberately plain. The README states there are no destructive syntax extensions, and that what you write displays correctly in any markdown software. That is a real constraint on the feature set: double-linked notes and image relationships live in Blossom's own metadata and database, not in syntax that would break when you open the same file elsewhere. It also means the export story is credible. The README says all images and articles support one-click backup and export, that migration out takes minutes, and that exported files open normally in local software such as VS Code or Obsidian.

## Installing Blossom with Docker Compose and MySQL 8

The README gives a single deployment command under the heading Docker Compose one-click deployment. It points at a compose file inside the repository rather than a published image reference, so you need the repository checked out first, and the compose file name tells you it expects MySQL 8.

```bash
docker compose -f docker/compose/blossom-mysql8.yaml up -d
```

Run that from the repository root. Because the -f flag names the file explicitly, docker compose will not look for a default compose.yaml, and the -d flag leaves the stack running in the background. What you should see is the containers starting; the README does not print expected log output or a default port, so check the compose file itself for the published ports and the initial credentials before you open a browser.

The README points to two external links for documentation and downloads, both at the project's site, and those are the right place to look for the client installers for Windows and Mac since the repository does not carry them. There is also a third-party migration tool listed under extension tools, wiz2blossom, for moving from WizNote. It is a separate repository, not part of this project, so treat its behaviour as its own author's responsibility.

One practical note on first use: the README advertises multi-user support, so the initial setup is an account on your own instance rather than a sign-up against somebody else's service. The README does not document the bootstrap account or the first-login flow, so read the compose file and the linked documentation before exposing the instance to a network.

## Where Blossom stops being the right tool

The deployment story assumes you can run a database. Blossom's documented path is a Docker Compose stack with MySQL 8, which is a heavier operational commitment than a folder of markdown files. If your goal is a single machine and a single user, that stack is overhead you will maintain for no benefit. A plain editor over a synced directory does the same job with fewer moving parts.

There is also a gap between what the README promises and what it documents. It promises one-click backup and export, and it promises migration out in minutes, but the README does not document the export command, the export file format, or a rollback procedure for a failed upgrade. The release history shows why that matters: v1.16.0 in April 2024, v1.17.0 in July 2025, v1.17.1 in August 2025. A gap of more than a year sits between two of those releases. Anyone running this in production should assume they are the one testing the upgrade, and should verify that a database dump and an export exist before pulling a new version.

Scope is the third limit. The README lists a pomodoro timer, weather, an editing heatmap and word-count charts. Those are pleasant, and they are also surface area that has nothing to do with note durability. If you want a markdown editor and nothing else, the extra modules are code you carry without using.

Finally, client coverage is what the README says it is: Windows, Mac, web and web mobile. There is no Linux desktop client or mobile app listed, so a Linux-only user is working through the web client or not at all.

## Blossom against Obsidian and VS Code as local-first alternatives

The natural comparison is Obsidian, and the README invites it by promising that exported files open in Obsidian or VS Code. The difference is architectural. Obsidian keeps a vault as a directory of files on your machine and treats sync as an add-on you configure. Blossom inverts that: the server and its database are the primary store, and your devices are clients that synchronize against it. Obsidian's approach means the files exist whether or not any service is running. Blossom's approach means the server is a dependency for access, and in exchange you get the image hosting, the article-to-image relationships, multi-user accounts and the blog from one deployment.

VS Code with a markdown extension is the lighter comparison. It is a general editor that happens to render markdown, with no server, no database and no synchronization of its own. It wins on install cost and loses on everything Blossom's README lists beyond editing: image management, the double-link graph, the plan and to-do modules, and the published blog.

The honest framing is that Blossom is not competing on editor features. It is competing on consolidation. If you were going to run a note app, a separate image host, a to-do tool and a blog engine, Blossom's pitch is that one self-hosted stack replaces four services and keeps the data in one database you control. If you were not going to run any of those, the comparison does not apply.

## Maintenance, licensing and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-06-27. That is recent enough that the project is not dormant, but the release tags tell a different story about cadence: v1.16.0 in April 2024, v1.17.0 in July 2025, v1.17.1 in August 2025. Development activity and tagged releases are not moving at the same rate. Plan upgrades around the tags rather than around commit activity, because a tag is what you can pin.

Upgrade cost is dominated by the database. The documented deployment is a MySQL 8 container, so any version bump that touches schema means you want a dump before you redeploy. The README does not document a migration command or a rollback path, so the safe sequence is your own: dump the database, export your articles and images through the application, then run the compose command again. If the new version fails, you restore from the dump. That procedure is not in the README; it is what the absence of a documented one implies.

The licence is MIT. That is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are preserved. It says nothing about the hosted documentation site, the client binaries distributed through the project's download page, or the third-party migration tool, which is a separate repository under its own terms. If you plan to redistribute a modified build, read the LICENSE file in the repository root rather than relying on the licence identifier alone. None of this is legal advice.

## Conclusion

Adopt Blossom if you want your notes, images and blog on hardware you control, you are comfortable running MySQL and a Docker Compose stack, and you accept that the README ships one deployment command rather than a written upgrade path. Do not adopt it if you need a managed service with an SLA, a documented rollback procedure, or a client for a platform the project does not list. Before committing, verify three things: that the docker/compose/blossom-mysql8.yaml file matches your MySQL 8 setup, that the export path actually produces files your current editor opens, and that the release cadence between v1.16.0 and v1.17.1 fits how often you are willing to redeploy.

## FAQ

### What is Blossom, the self-hosted markdown editor?

It is a markdown editor you deploy on your own servers, described in its README as a cloud double-linked note application supporting private deployment. Notes, images and plans are stored on your server and synchronize across Windows, Mac, web and web mobile clients.

### How do I install Blossom?

The README gives a single Docker Compose command pointing at docker/compose/blossom-mysql8.yaml, run with the -f and -d flags from the repository root. The compose file expects MySQL 8, and the README does not list a default port or initial credentials, so read that file before opening the app.

### Does Blossom need a third-party image host?

No. The README states Blossom does not depend on any third-party storage or image host, that it is itself the image host, and that it provides image management, protection against accidental deletion and bidirectional binding between images and articles.

### Can I move my notes out of Blossom later?

The README says all images and articles support one-click backup and export, that migration out takes minutes, and that exported files open normally in VS Code or Obsidian. The README does not document the export command or the file format it produces, so verify the output before you rely on it.

### What licence does Blossom use?

The repository is MIT licensed, which permits use, modification and redistribution provided the copyright and permission notices are kept. The licence covers the code in the repository; the documentation site, the client downloads and the separate wiz2blossom migration tool are not addressed by that identifier.

## Sources

- [blossom-editor/blossom on GitHub](https://github.com/blossom-editor/blossom)
- [License: MIT](https://github.com/blossom-editor/blossom/blob/dev/LICENSE)
- [Project website](https://www.wangyunf.com/blossom-doc/index)
- [README](https://github.com/blossom-editor/blossom/blob/dev/README.md)
- [Releases](https://github.com/blossom-editor/blossom/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/blossom-editor-blossom