* feat(updater): scheduled execution state + graceStartTag dedupe field (#7607) Preparation for Tier 3 of the auto-update subsystem: - ExecutionStatus gains `scheduled` (targetTag, scheduledFor, startedAt). - EmailSendLog gains `graceStartTag` for one-shot grace-start email dedupe. - state validator accepts the new shape, requires per-status fields, and backfills graceStartTag=null on a Tier 1/2 state file. Plus the implementation plan at docs/superpowers/plans/2026-05-11-auto-update-pr3-tier3-auto.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(updater): decideSchedule pure decision function (#7607) Adds src/node/updater/Scheduler.ts with the Tier 3 pure decision logic: - schedules when canAuto + idle/verified/terminal-cleared - reschedules when a newer tag appears mid-grace - emits a grace-start email (once per tag) when adminEmail is set - cancels a stale schedule when policy flips canAuto off - no-ops during in-flight / terminal states - clamps preApplyGraceMinutes to [0, 7 days] Also extends Notifier's EmailKind union with 'grace-start' so the decision result types correctly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(updater): scheduler timer runner with arm/cancel (#7607) Adds createSchedulerRunner to Scheduler.ts: - arm(): clears any prior timer, sets a fresh one for scheduledFor - cancel(): clears the pending timer, idempotent - past scheduledFor → fires with delay=0 (rehydrate after restart-in-grace) - single-fire-per-arm semantics; armedFor cleared on fire Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(updater): extract apply pipeline shared by HTTP + scheduler (#7607) Lifts the preflight → drain → execute orchestration out of the /admin/update/apply HTTP handler into src/node/updater/applyPipeline.ts. The HTTP handler keeps its 4xx status mapping; the pipeline owns the state transitions, lock release, drain coordination, and rollback hand- off. The new ApplyPipelineDeps interface accepts an onAccepted callback so the HTTP path can still 202 mid-flow while the Tier 3 scheduler path (next commit) can no-op. Adds `scheduled` to the apply allowed-entry list so an admin can "Apply now" during the Tier 3 grace window. 13 vitest cases cover happy / preflight-failed / cancelled / busy / lock-held / scheduled-entry / rollback / lock-release. Existing 12 mocha integration tests still pass without change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(updater): wire Tier 3 scheduler into boot + performCheck (#7607) - expressCreateServer instantiates the scheduler runner and rehydrates the timer when a prior boot left state.execution = scheduled - performCheck evaluates decideSchedule after the notifier pass: schedule transitions state + sends grace-start email + arms timer; cancel-schedule resets to idle + cancels timer - shutdown cancels the timer - exposes cancelScheduler() so the cancel endpoint (next commit) can drop the pending schedule - buildSchedulerApplyDeps() supplies the full production-wired pipeline deps (preflight, executor, rollback) for the scheduler-triggered apply Adds tests/backend/specs/updater-scheduler-integration.ts covering boot-rehydrate fire-on-past and the decision-to-state round-trip. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(updater): cancel handler supports Tier 3 scheduled state (#7607) POST /admin/update/cancel now accepts execution.status === 'scheduled' in addition to preflight/draining. The handler calls cancelScheduler() to drop the pending in-process timer, then transitions state to idle with lastResult.outcome = 'cancelled' (mirroring the existing pattern). Adds a Tier 3 integration test that seeds a scheduled state, calls /admin/update/cancel, and asserts the state machine landed correctly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(admin): countdown + cancel UI for Tier 3 scheduled updates (#7607) - store.ts: extend Execution union with the scheduled variant - UpdatePage.tsx: render countdown panel during scheduled; Apply button is relabelled "Apply now" so the admin can skip the remaining grace; Cancel button accepts scheduled state - UpdateBanner.tsx: dedicated scheduled banner with live remaining time - en.json: new i18n keys (execution.scheduled, banner.scheduled, page.scheduled.{title,countdown,apply_now}) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(updater): playwright spec for Tier 3 scheduled UI (#7607) Three cases against a mocked /admin/update/status: - countdown panel + Apply now + Cancel render when execution is scheduled - Cancel button posts /admin/update/cancel and triggers re-fetch - /admin (banner) shows "Auto-update to <tag> scheduled" copy Mirrors the existing update-page-actions.spec.ts mock pattern (page.route). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(updater): document Tier 3 auto with grace window (#7607) - doc/admin/updates.md: flip Tier 3 from "designed, not yet implemented" to current; expand preApplyGraceMinutes table row; add a Tier 3 section explaining schedule / cancel / Apply now / restart-in-grace and the grace-start email - settings.json.template: clarify the preApplyGraceMinutes comment - CHANGELOG.md: Unreleased entry for Tier 3 - runbook §11: full Tier 3 smoke (happy, cancel, apply-now, restart-in- grace, email) plus the additional sign-off checkboxes Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(admin): UpdatePage handles missing execution field; scope spec locator (#7607) Two CI fixes for PR #7720: 1. UpdatePage.tsx — optional-chain us.execution.status. Integration test stubs (update-banner.spec.ts) ship payloads without the Tier 2/3 execution / lastResult / lockHeld fields; without optional chaining on the new scheduled-derivation line the whole page crashed before the h1 rendered, breaking the unrelated "renders current version" test. 2. update-scheduled.spec.ts — scope the v2.7.2 assertion to the .update-scheduled section. The regex was matching three elements (banner, countdown panel, changelog link) and tripped Playwright's strict-mode locator check. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(updater): address Qodo review (Tier 3 race conditions + tier-off bypass) (#7607) Four fixes for bugs flagged by Qodo's review of PR #7720: 1. **Tier=off bypasses scheduler** (correctness). expressCreateServer used to instantiate the scheduler and rehydrate any persisted `scheduled` state regardless of `updates.tier`. A user who set `tier: "off"` after a schedule had been persisted would still see the timer fire after restart. The boot path now skips scheduler creation when tier is off and explicitly clears a stale scheduled state to idle (logged so the admin sees what happened). 2. **Timer fire skips state recheck** (reliability). The scheduler's timer callback called applyUpdate() directly. Race: admin clicks Cancel at the same instant the timer fires, or the tier flips during the grace window. Now schedulerTriggerApply re-loads state and re-evaluates policy via a new pure decideTriggerApply() helper in Scheduler.ts. If state is no longer scheduled (or scheduled for a different tag), aborts. If policy now denies auto, persists state back to idle and aborts. 3. **Apply-now leaves scheduler timer armed** (correctness). The apply endpoint accepts `scheduled` as an entry status but didn't cancel the in-process scheduler timer. After the admin clicks Apply now, the still-armed timer could later fire and attempt another apply (especially if the manual one finishes in preflight-failed, which is also an allowed-entry status). Apply handler now calls cancelScheduler() when entering from `scheduled`. 4. **scheduledFor not validated as timestamp** (reliability). State validator only required scheduledFor / startedAt etc. to be non-empty strings; a hand-edited "scheduledFor": "garbage" would pass validation and yield NaN delay → immediate fire. The validator now requires known timestamp fields to be parseable via Date.parse(). Tests: 6 new decideTriggerApply cases + 3 new state.ts validation cases. 189 vitest pass / 29 mocha integration pass / ts-check clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .github | ||
| admin | ||
| bin | ||
| doc | ||
| docs/superpowers | ||
| local_plugins | ||
| packaging | ||
| snap | ||
| src | ||
| ui | ||
| var | ||
| .dockerignore | ||
| .editorconfig | ||
| .env.default | ||
| .env.dev.default | ||
| .gitattributes | ||
| .gitignore | ||
| .npmrc | ||
| .pr_agent.toml | ||
| AGENTS.MD | ||
| best_practices.md | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| docker-compose.dev.yml | ||
| docker-compose.yml | ||
| Dockerfile | ||
| LICENSE | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| README.md | ||
| SECURITY.md | ||
| settings.json.docker | ||
| settings.json.template | ||
| tests | ||
Etherpad — the editor for documents that matter
Real-time collaborative editing where authorship is the default, your server is the only server, and you decide what AI (if any) ever touches your text.
About
Etherpad is a real-time collaborative editor for documents that matter.
Every keystroke is attributed to its author. Every revision is preserved. The timeslider lets you scrub through a document's entire history, character by character. Author colours make collaboration visible at a glance — not buried in a menu.
Etherpad runs on your server, under your governance. No telemetry. No upsells. AI is a plugin you install, pointed at the model you choose, running on infrastructure you control — not a feature decided for you in a boardroom you weren't in.
The code is Apache 2.0. The data format is open. It scales to thousands of simultaneous editors per pad. Translated into 105 languages. Extended through hundreds of plugins. Used by Wikimedia, governments, public-sector institutions, and self-hosters worldwide since 2009.
Full data export is built in. The history is yours.
Try it out
Try out a public Etherpad instance
Project Status
Etherpad has been doing the same thing — well — since 2009. No pivots, no acquisitions, no enshittification. Maintained by a small volunteer team.
We are actively looking for maintainers. If you have experience with Node.js, real-time systems, or institutional collaboration tooling and you want to work on infrastructure that thousands of organisations quietly depend on, please open an issue or contact John McLear.
Code Quality
Testing
Engagement
Who uses Etherpad
For more than a decade, Etherpad has quietly underpinned the documents that matter to:
- Wikimedia Foundation — collaborative drafting across editor communities.
- Public-sector institutions across the EU — including organisations that legally cannot use US-cloud SaaS for sovereignty and GDPR reasons.
- Universities and schools worldwide — including jurisdictions where Google Workspace is no longer permitted in education.
- Civic-tech and democratic-deliberation projects — citizen assemblies, participatory budgeting, public consultations.
- Newsrooms and investigative journalism teams — where authorship and editing history matter for legal and editorial integrity.
- Tens of thousands of self-hosted instances worldwide, run by IT teams who chose Etherpad because it is theirs.
Installation
Quick install (one-liner)
The fastest way to get Etherpad running. Requires git and Node.js >= 22.
macOS / Linux / WSL:
curl -fsSL https://raw.githubusercontent.com/ether/etherpad/master/bin/installer.sh | sh
Windows (PowerShell):
irm https://raw.githubusercontent.com/ether/etherpad/master/bin/installer.ps1 | iex
Both installers clone Etherpad into ./etherpad-lite, install dependencies, and
build the frontend. When the installer finishes, run:
cd etherpad-lite && pnpm run prod
Then open http://localhost:9001.
To install and start in one go:
# macOS / Linux / WSL
ETHERPAD_RUN=1 sh -c "$(curl -fsSL https://raw.githubusercontent.com/ether/etherpad/master/bin/installer.sh)"
# Windows
$env:ETHERPAD_RUN=1; irm https://raw.githubusercontent.com/ether/etherpad/master/bin/installer.ps1 | iex
Docker-Compose
The official image is published to both Docker Hub (etherpad/etherpad) and GitHub Container Registry (ghcr.io/ether/etherpad) with identical tags. Use whichever suits your environment; GHCR avoids Docker Hub's anonymous pull rate limits.
services:
app:
user: "0:0"
image: etherpad/etherpad:latest # or: ghcr.io/ether/etherpad:latest
tty: true
stdin_open: true
volumes:
- plugins:/opt/etherpad-lite/src/plugin_packages
- etherpad-var:/opt/etherpad-lite/var
depends_on:
- postgres
environment:
NODE_ENV: production
ADMIN_PASSWORD: ${DOCKER_COMPOSE_APP_ADMIN_PASSWORD:-admin}
DB_CHARSET: ${DOCKER_COMPOSE_APP_DB_CHARSET:-utf8mb4}
DB_HOST: postgres
DB_NAME: ${DOCKER_COMPOSE_POSTGRES_DATABASE:-etherpad}
DB_PASS: ${DOCKER_COMPOSE_POSTGRES_PASSWORD:-admin}
DB_PORT: ${DOCKER_COMPOSE_POSTGRES_PORT:-5432}
DB_TYPE: "postgres"
DB_USER: ${DOCKER_COMPOSE_POSTGRES_USER:-admin}
# For now, the env var DEFAULT_PAD_TEXT cannot be unset or empty; it seems to be mandatory in the latest version of etherpad
DEFAULT_PAD_TEXT: ${DOCKER_COMPOSE_APP_DEFAULT_PAD_TEXT:- }
DISABLE_IP_LOGGING: ${DOCKER_COMPOSE_APP_DISABLE_IP_LOGGING:-false}
SOFFICE: ${DOCKER_COMPOSE_APP_SOFFICE:-null}
TRUST_PROXY: ${DOCKER_COMPOSE_APP_TRUST_PROXY:-true}
restart: always
ports:
- "${DOCKER_COMPOSE_APP_PORT_PUBLISHED:-9001}:${DOCKER_COMPOSE_APP_PORT_TARGET:-9001}"
postgres:
image: postgres:15-alpine
environment:
POSTGRES_DB: ${DOCKER_COMPOSE_POSTGRES_DATABASE:-etherpad}
POSTGRES_PASSWORD: ${DOCKER_COMPOSE_POSTGRES_PASSWORD:-admin}
POSTGRES_PORT: ${DOCKER_COMPOSE_POSTGRES_PORT:-5432}
POSTGRES_USER: ${DOCKER_COMPOSE_POSTGRES_USER:-admin}
PGDATA: /var/lib/postgresql/data/pgdata
restart: always
# Exposing the port is not needed unless you want to access this database instance from the host.
# Be careful when other postgres docker container are running on the same port
# ports:
# - "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
volumes:
postgres_data:
plugins:
etherpad-var:
Requirements
Node.js >= 22.12.
Windows, macOS, Linux
- Download the latest Node.js runtime from nodejs.org.
- Install pnpm:
npm install -g pnpm(Administrator privileges may be required). - Clone the repository:
git clone -b master - Run
pnpm i - Run
pnpm run build:etherpad - Run
pnpm run prod - Visit
http://localhost:9001in your browser.
Docker container
Find here information on running Etherpad in a container.
Plugins
Etherpad is very customizable through plugins.
Available Plugins
For a list of available plugins, see the plugins site.
Plugin Installation
You can install plugins from the admin web interface (e.g., http://127.0.0.1:9001/admin/plugins).
Alternatively, you can install plugins from the command line:
cd /path/to/etherpad-lite
pnpm run plugins i ep_${plugin_name}
Also see the plugin wiki article.
Suggested Plugins
Run the following command in your Etherpad folder to get all of the features visible in the above demo gif:
pnpm run plugins i \
ep_align \
ep_comments_page \
ep_embedded_hyperlinks2 \
ep_font_color \
ep_headings2 \
ep_markdown \
ep_webrtc
For user authentication, you are encouraged to run an OpenID Connect identity provider (OP) and install the following plugins:
- ep_openid_connect to authenticate against your OP.
- ep_guest to create a "guest" account that has limited access (e.g., read-only access).
- ep_user_displayname to automatically populate each user's displayed name from your OP.
- ep_stable_authorid so that each user's chosen color, display name, comment ownership, etc. is strongly linked to their account.
Upgrade Etherpad
Run the following command in your Etherpad folder to upgrade
- Stop any running Etherpad (manual, systemd ...)
- Get present version
git -P tag --contains
- List versions available
git -P tag --list "v*" --merged
- Select the version
git checkout v2.2.5
git switch -c v2.2.5
- Upgrade Etherpad
./bin/run.sh
- Stop with [CTRL-C]
- Restart your Etherpad service
Next Steps
Tweak the settings
You can modify the settings in settings.json. If you need to handle multiple
settings files, you can pass the path to a settings file to bin/run.sh
using the -s|--settings option: this allows you to run multiple Etherpad
instances from the same installation. Similarly, --credentials can be used to
give a settings override file, --apikey to give a different APIKEY.txt file
and --sessionkey to give a non-default SESSIONKEY.txt. Each configuration
parameter can also be set via an environment variable, using the syntax
"${ENV_VAR}" or "${ENV_VAR:default_value}". For details, refer to
settings.json.template. Once you have access to your /admin section,
settings can be modified through the web browser.
If you are planning to use Etherpad in a production environment, you should use
a dedicated database such as mysql, since the dirtyDB database driver is
only for testing and/or development purposes.
Secure your installation
If you have enabled authentication in users section in settings.json, it is
a good security practice to store hashes instead of plain text passwords in
that file. This is especially advised if you are running a production
installation.
Please install ep_hash_auth plugin
and configure it. If you prefer, ep_hash_auth also gives you the option of
storing the users in a custom directory in the file system, without having to
edit settings.json and restart Etherpad each time.
Customize the style with skin variants
Open http://127.0.0.1:9001/p/test#skinvariantsbuilder in your browser and start playing!
Helpful resources
The wiki is your one-stop resource for Tutorials and How-to's.
Documentation can be found in doc/.
Development
Things you should know
You can debug Etherpad using bin/debugRun.sh.
You can run Etherpad quickly launching bin/fastRun.sh. It's convenient for
developers and advanced users. Be aware that it will skip the dependencies
update, so remember to run bin/installDeps.sh after installing a new
dependency or upgrading version.
If you want to find out how Etherpad's Easysync works (the library that makes
it really realtime), start with this
PDF
(complex, but worth reading).
Contributing
Read our Developer Guidelines
HTTP API
Etherpad is designed to be easily embeddable and provides a HTTP API that allows your web application to manage pads, users and groups. It is recommended to use the available client implementations in order to interact with this API.
OpenAPI (previously swagger) definitions for the API are exposed under
/api/openapi.json.
jQuery plugin
There is a jQuery plugin that helps you to embed Pads into your website.
Plugin Framework
Etherpad offers a plugin framework, allowing you to easily add your own features. By default your Etherpad is extremely light-weight and it's up to you to customize your experience. Once you have Etherpad installed you should visit the plugin page and take control.
Translations / Localizations (i18n / l10n)
Etherpad comes with translations into all languages thanks to the team at TranslateWiki.
If you require translations in plugins please send pull request to each plugin individually.
FAQ
Visit the FAQ.
Get in touch
The official channel for contacting the development team is via the GitHub issues.
For responsible disclosure of vulnerabilities, please write a mail to the maintainers (a.mux@inwind.it and contact@etherpad.org).
Join the official Etherpad Discord Channel.



