Etherpad: a self-hosted collaborative editor where authorship is the default

What Etherpad solves, and who ends up running it

Most collaborative editors are services. You get an account, a URL you do not control, and a data model you cannot export in full. Etherpad inverts that. The README describes it as an editor for documents that matter, and the design choices follow from that framing: every keystroke is attributed to its author, every revision is preserved, and the timeslider lets you scrub through a document's entire history character by character. Author colours are visible by default rather than hidden behind a menu.

The intended audience is not a single person taking notes. The README lists Wikimedia Foundation, public-sector institutions across the EU, universities and schools in jurisdictions where Google Workspace is no longer permitted in education, civic-tech and democratic-deliberation projects, and newsrooms where editing history matters for legal and editorial integrity. The common thread is an organisation that cannot or will not put its drafting process inside someone else's cloud. If you are a solo user who wants a free online notepad, Etherpad is more machinery than you need, and the self-hosting burden lands entirely on you.

Authorship, the timeslider, and the data format behind them

The mechanism that makes Etherpad different from a plain text area is that the document is not stored as a blob of current text. The README states that full data export is built in and links to a wiki page on the export capabilities, and that the data format is open. The timeslider is the user-facing surface of that: instead of a save history, you get a continuous record you can move through, with each change tied to an author.

AI is deliberately not part of that core. The README says AI is a plugin you install, pointed at the model you choose, running on infrastructure you control, and that this is not a feature decided for you elsewhere. That is a real architectural stance, not marketing: the editor ships without a model dependency, and a deployment that never installs such a plugin never sends document text to a model provider.

The README also points to PRIVACY.md, which documents what it calls the two opt-out network calls Etherpad's own code makes and how to disable each. Two calls is a small number, but the phrasing matters: they exist, they are documented, and disabling them is a configuration change rather than a build patch. If your threat model forbids any outbound call, read that file before you deploy rather than after.

Installing Etherpad and starting a first pad

The quickest path is the installer script. The README states it requires git and Node.js 24 or newer, and that it clones Etherpad into ./etherpad-lite, installs dependencies, and builds the frontend. On macOS, Linux or WSL the one-liner is:

curl -fsSL https://raw.githubusercontent.com/ether/etherpad/master/bin/installer.sh | sh

On Windows the README gives a PowerShell equivalent that downloads and runs installer.ps1. Either way, when the installer finishes you start the server from the cloned directory:

cd etherpad-lite && pnpm run prod

After that the README says to open http://localhost:9001. That is the default port, and it is the address you should expect to see respond. If you would rather install and start in one step, the README documents an ETHERPAD_RUN=1 environment variable that the installer honours.

The container route is the one most teams will actually take, because it brings its own Node and pnpm. The repository's docker-compose.yml defines an app service on the etherpad/etherpad:latest image with a Postgres dependency, and it deliberately has no fallback for two secrets. ADMIN_PASSWORD and DB_PASS are both written with the ${VAR:?message} form, so a missing value stops the stack at docker compose up rather than at runtime. The compose file also notes that DEFAULT_PAD_TEXT cannot currently be unset or empty. Two named volumes, plugins and etherpad-var, hold installed plugins and the var directory.

One detail in that file deserves attention before you edit anything through the admin UI. The compose file explains that settings.json lives in the image's writable layer unless you mount it, so docker compose restart preserves your edits but docker compose down && up, a pull, or watchtower reverts them to the image template. The commented-out volume mount for ./settings.json is the fix, and the file links issue 7819 for the full story.

Where Etherpad is the wrong tool

Etherpad is a text editor. It is not a spreadsheet, not a slide deck, and not a document format converter. The repository topics mention PDF generation and video conferencing, but those are plugin territory, and the README is explicit that extensions come through hundreds of plugins rather than the core. If your team's real need is a shared spreadsheet with formulas, adopting Etherpad means adopting a plugin and accepting that its maintenance is not the core team's problem.

The operational cost is the second constraint. The README says the project is maintained by a small volunteer team, and it states plainly that they are actively looking for maintainers. That is unusual candour and it should shape your risk assessment. A small volunteer team means security reports and plugin compatibility move at volunteer speed, and it means you should read SECURITY.md and know how to reach the maintainers before you put a pad in front of a legal team.

Finally, the default install is a single process on port 9001 with no authentication in front of it. The README's quick install gets you to a working pad, not to a hardened deployment. Put it behind your own reverse proxy and access control, or keep it on a private network, before you treat it as production.

Etherpad against a hosted cloud document suite

The obvious alternative is a hosted suite like Google Docs or Microsoft 365, and the difference is not feature parity. It is where the document lives and who can read it. A hosted suite gives you zero installation, automatic upgrades, and a mature mobile experience. Etherpad gives you a server you patch, a database you back up, and a settings file you can break.

What you get in return is the thing the README keeps returning to: your server is the only server. For an EU public-sector body that legally cannot use US-cloud SaaS for sovereignty and GDPR reasons, that is not a preference, it is the constraint that decides the tool. The same logic applies to a newsroom protecting a source, or a school district in a jurisdiction that has banned a particular cloud provider in education.

A closer comparison is a wiki or a shared drive with version history. Those preserve revisions too, but they are not built around simultaneous character-level editing with visible authorship. Etherpad's timeslider and author colours exist because the editing process itself is the artefact. If you only need a final document, you are paying for machinery you will not use.

Maintenance, upgrades and the licence

The repository is not archived, and the last push was on 2026-09-21, the same day as the v3.3.6 release. Recent releases are close together: v3.3.6 on 2026-09-21, v3.3.5 on 2026-09-17, v3.3.4 on 2026-09-16. That cadence suggests active release work, but the README's own statement that the team is looking for maintainers is the more useful signal about long-term capacity.

Upgrade cost depends on how you installed it. The container path is a tag change plus a restart, with the caveat already noted about settings.json reverting on recreate. The source path means pulling the repository and rebuilding the frontend, which the package.json scripts expose as build:ui and build:etherpad. Plugin compatibility is the variable you cannot predict from the repository alone: plugins live in the plugin_packages volume, and a core upgrade that changes an internal API can leave a plugin behind. Test upgrades on a copy of your data before touching the instance your colleagues are typing into.

On licensing, Etherpad is Apache-2.0. That permits commercial and closed-source use and modification, and it includes an explicit patent grant. It does not remove the obligations: you keep the licence and notices, and you state significant changes. This is a summary of the licence text, not legal advice, and if you are redistributing a modified Etherpad inside a product you should have counsel read the file rather than this paragraph.

Editorial conclusion

Adopt Etherpad if you need a collaborative editor whose data, history and plugin surface stay on infrastructure you control, and if you can run Node.js 24 or newer with pnpm 12 or newer, or the published container image. Skip it if you want a hosted service with zero operational work, or if your collaboration needs are really spreadsheet or presentation work. Before committing, verify three things on your own instance: that the admin password and database credentials are set as required variables, that your chosen database backend is actually reachable from the app container, and that the settings you change through the admin UI survive a container recreate rather than reverting to the image template.

Frequently asked questions

Official sources

1. ether/etherpad on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases