Ech0: a self-hosted personal timeline you publish instead of just capture
Ech0, An open-source, self-hosted lightweight publishing platform for personal idea sharing.
At a glance
- What is it?
- Ech0 is a Go-based, AGPL-3.0 self-hosted publishing platform for short posts, links and media. It is aimed at people who already capture notes and now want a public or semi-public timeline they own, and it ships as a single Docker image on port 6277.
- Who is it for?
- Adopt Ech0 if you want a personal timeline on your own domain with RSS, optional comments and an export path, and you are comfortable running a container and a SQLite file. Do not adopt it if you need bidirectional PKM syncing or a team documentation workspace; the README names both as poor fits.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 27, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap Ech0 targets between capture tools and publishing
Most lightweight note tools stop at capture. You write a thought, it lands in a private list, and nothing else happens. Ech0 is positioned one step later in the pipeline: the README describes it as built for "what comes next", publishing those ideas to a personal timeline that others can follow and interact with. The distinction matters because the two jobs pull in different directions. A capture tool optimizes for speed of input and private retrieval. A publishing surface needs stable URLs, an RSS feed, comment moderation and some notion of an audience.
The intended user is one person, not a team. The README's fit list is explicit: run a personal public or semi-public timeline on your own domain, publish short posts, links and media from one interface, keep data ownership while still getting RSS and optional comments. The anti-list is just as explicit. If you need a bidirectional knowledge base workflow in the Obsidian style, a team-first collaborative docs workspace in the Notion style, or a pure memo tool with no timeline or publishing at all, the README says Ech0 is probably not for you. That is an unusually honest scope statement, and it is worth taking at face value rather than treating as marketing humility.
The practical consequence is that Ech0 assumes you already have a place to think and now want a place to speak. It does not try to be the inbox and the stage at once.
How Ech0 is put together: Go binary, Gin, SQLite, VireFS and Busen
The repository layout and go.mod make the architecture legible. Ech0 is a Go 1.27 module at github.com/lin-snow/ech0, with cmd/ holding the entrypoint, internal/ holding application code, pkg/ holding reusable pieces, and web/, site/ and hub/ as separate modules driven from the justfile. The HTTP layer is Gin, the API schema layer is Huma v2, and dependency wiring is done with Google Wire, which explains the wire_gen.go file excluded from coverage in the justfile. Persistence goes through GORM with the SQLite driver. That combination produces the deployment shape the README advertises: one binary, one data directory, no external database to operate.
Two in-house components are named in the feature list. VireFS is described as a unified storage layer that mounts and manages both local storage and S3-compatible object storage, which is why the same attachment code path can write to a local volume or to a bucket. Busen is described as a data bus providing decoupled module communication and reliable message delivery, sitting between modules rather than letting them call each other directly. Neither is documented in the README beyond those sentences, so the internal contracts are something you would read from internal/ rather than from the docs.
The feature list also shows where Ech0 has grown past a simple blog. There is an OAuth2/OIDC client via coreos/go-oidc, WebAuthn passkeys via go-webauthn, JWT via golang-jwt, S3 via the AWS SDK v2, scheduled jobs via gocron and robfig/cron, RSS via gorilla/feeds, mail via go-mail, and both OpenAI and Anthropic SDKs for the Copilot features. An MCP server is listed as exposing post, file and stats operations over Streamable HTTP with scoped JWTs. The dependency list is the real feature list here: it tells you which integrations exist without relying on adjectives.
Installing Ech0 with Docker and making the first post
The README's "Try in 60 Seconds" section gives a single docker run command. It publishes port 6277, mounts /opt/ech0/data on the host to /app/data in the container, and sets JWT_SECRET. Run it on the machine that will host the timeline:
docker run -d \
--name ech0 \
-p 6277:6277 \
-v /opt/ech0/data:/app/data \
-e JWT_SECRET="Hello Echos" \
sn0wl1n/ech0:latestAfter the container starts, open http://ip:6277 in a browser, replacing ip with the host address. The README gives three first-run steps: register your first account, note that the first account becomes Owner with admin privileges, and note that publishing is restricted to privileged accounts by default. That third point is the one people miss. A fresh instance is not an open blog; the Owner account has to grant publishing rights before anyone else can post.
Replace the JWT_SECRET value before you expose the instance. The README's example uses the literal string "Hello Echos", which is fine for a local test and wrong for anything reachable from the internet. The same applies to the data path: /opt/ech0/data is a suggestion, and it is the only thing standing between you and your content, since SQLite and any locally stored attachments live under /app/data.
For anything beyond a trial, the README points at DEPLOYMENT.md for Docker Compose and Helm options, and the repository carries a charts/ directory for the Helm path. The justfile is the other entrypoint, aimed at people building from source rather than pulling an image. It defines run, which starts the server in debug mode, and build, which produces ./bin/ech0:
just run
just buildBoth commands pass version metadata into github.com/lin-snow/ech0/internal/version via ldflags, so a binary built this way reports its commit and build time. The justfile also wires up test, test-race, test-cover, lint and fmt targets, and a dev target that installs and runs air with .air.toml for live reload.
Content capsules and the export path that keeps you portable
The most interesting design decision in the README is the content capsule. Ech0 can export everything you have written as a self-contained capsule, import that capsule into another instance, or compile it into a static site you can host anywhere. Backup is exposed through the web UI, the CLI and the TUI, and the README mentions background automatic backups as well. There is also a migration import path for historical data and snapshot export for archiving.
This matters more than it first appears, because the usual objection to self-hosted publishing tools is that your content is trapped in whatever schema the project chose. A capsule that can be re-imported or compiled to static HTML is a direct answer to that objection, at least on paper. It also gives you a migration route between instances, which is useful if you move from a VPS to a home server or change object storage providers.
What the README does not describe is the capsule format itself. The feature list links to docs/usage/capsule.md, so the schema exists in the repository, but the top-level README does not state whether a capsule is a zip of JSON and media, a single archive, or something else, and it does not describe what happens to attachments stored in S3 when you export. If portability is the reason you are choosing Ech0, read docs/usage/capsule.md and test an export-import round trip on a throwaway instance before you move real content in.
Where Ech0 is the wrong tool, and what it costs to run
The README's own exclusions are the clearest limitations, and they are structural rather than temporary. Ech0 is not a bidirectional knowledge base. There is no mention of syncing edits back into a local vault, no file-watching, no link graph for PKM workflows. It is not a collaborative docs workspace either; multi-account permission management exists, but the framing throughout is a personal timeline with optional comments, not a team wiki. If your notes need to flow both ways between a local editor and a server, Ech0 is the wrong layer.
There is a second class of limitation that comes from the deployment model. SQLite plus a mounted volume means the /app/data directory is the whole system state. Lose it and you lose the instance, including the Owner account. The README documents automatic backups but does not document rollback, point-in-time recovery, or what happens if you restore a backup taken from an older release into a newer binary. Upgrades are the place where self-hosted projects usually hurt, and the README's upgrade section is a pointer to DEPLOYMENT.md rather than a procedure.
The licence is AGPL-3.0, and the repository also carries a COMMERCIAL.md file and a NOTICE file. AGPL-3.0 is a copyleft licence with a network clause: if you modify Ech0 and let users interact with it over a network, the licence's terms about offering the corresponding source apply. That is a real consideration if you plan to run a modified Ech0 as a service for other people. The presence of COMMERCIAL.md suggests the maintainers have a separate track for commercial use, and its terms are the thing to read, not this article. Nothing here is legal advice; if the distinction between personal hosting and offering a service matters to your situation, read LICENSE, NOTICE and COMMERCIAL.md directly.
Maintenance is the easier question. The last push to the default branch was on 2026-08-28, and releases v5.7.0 and v5.6.0 landed on 2026-08-27 and 2026-08-28. The project is not archived and it is being released, but the upgrade cost is not documented in the README, so the honest position is that you should check CHANGELOG.md and the release notes for each version you cross rather than assume a smooth path.
Ech0 compared with Memos, the tool its README names
The README draws its own comparison: tools like Memos are described as great for capturing quick thoughts, with Ech0 built for what comes next. That is a fair summary of the difference in approach. Memos is a memo tool first, with a timeline as one view over your notes. Ech0 inverts the priority: the timeline is the product, and the capture interface serves it. That shows up in the feature list, where the social and publishing features (comments with moderation, likes, sharing, RSS, rich media cards for links and GitHub projects, embedded Bilibili and YouTube video) sit alongside the writing features rather than being bolted on.
The trade-off is that Ech0 carries more surface area than a pure memo tool. OIDC, WebAuthn passkeys, scoped access tokens, an MCP server, an AI Copilot, a TUI, a CLI and a webhook system are all in the repository. A single-user instance that only wants to publish short posts will not use most of that, and every extra integration is another thing that can break during an upgrade. If your actual need is a private place to dump thoughts with no audience, Ech0 is heavier than the job requires, and the README says as much. If your need is a public timeline with a feed and comments that you host yourself, the extra surface is the point.
Editorial conclusion
Adopt Ech0 if you want a personal timeline on your own domain with RSS, optional comments and an export path, and you are comfortable running a container and a SQLite file. Do not adopt it if you need bidirectional PKM syncing or a team documentation workspace; the README names both as poor fits. Before committing, verify the COMMERCIAL.md terms if you plan to host it for other people, and confirm the JWT_SECRET and /app/data mount survive your upgrade routine, since the README does not document rollback.
Frequently asked questions
What is Ech0 and who is it for?
Ech0 is an open-source, self-hosted publishing platform for short posts, links and media, written in Go and licensed AGPL-3.0. The README frames it for people who want a personal public or semi-public timeline on their own domain while keeping data ownership and RSS output.
How do I install Ech0 with Docker?
The README's 60-second path is a single docker run command that pulls sn0wl1n/ech0:latest, publishes port 6277, mounts a host directory to /app/data and sets JWT_SECRET. You then open http://ip:6277, register the first account, and that account becomes Owner.
Does Ech0 support exporting my content to another instance?
Yes. The README describes exporting everything you have written as a self-contained capsule, importing it into another instance, or compiling it into a static site. Backup and export are available from the web UI, the CLI and the TUI, and the capsule format is documented in docs/usage/capsule.md.
Is Ech0 a note-taking app like Memos?
The README positions it differently: it says tools like Memos are great for capturing quick thoughts, while Ech0 is built for publishing those ideas to a timeline others can follow and interact with. It also states Ech0 is probably not for you if you want a pure note-taking tool with no timeline or publishing.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/lin-snow-ech0)