So this moves the published image off an LTS line onto Current. Node 26 is due to become Active LTS in October 2026, about a month out, and nothing in ihasmail needs 26 over 24 — if the LTS line is preferred, every pin here is a single number and I will happily redo it as 24. Dependabot proposed 26 because it tracks latest, not because anything required it.
engines stays at >=20.19. That field is the floor for running ihasmail, not the version we build it on, and self-hosters on 20 or 22 are unaffected by this. The README's "recommended" figure follows CI to 26.
Verified on the runtime, not just in CI
npm run typecheck passes against the Node 26 types.
npm test — 1153 web tests across 113 files, 168 server tests.
npm run build passes.
docker build on node:26-alpine succeeds locally; the resulting image reports v26.8.2, starts, and answers /api/health with {"ok":true,...}.
The login, SSE (/api/events) and body-carrying POST /api/jmap checks from #323 all pass against a server running on Node 26.8.1.
Supersedes #313 (`node:22-alpine` → `26-alpine`) and #315 (`@types/node` → 26), which cannot safely land separately.
## Why one change
Four places describe the Node version, and moving any one alone leaves the build somewhere the others are not:
| | was | now |
|---|---|---|
| `.github/workflows/ci.yml` | 22 | 26 |
| `.github/workflows/publish.yml` | 22 | 26 |
| `.github/workflows/release.yml` | 22 | 26 |
| `Dockerfile` (build + runtime stages) | `node:22-alpine` | `node:26-alpine` |
| `server` `@types/node` | `^22.13.10` | `^26.5.1` |
#315 alone would typecheck against APIs the runtime does not have. #313 alone would ship a major that CI never exercised. Together they are coherent.
## Read this before deploying it
**Node 26 is Current, not LTS.** I checked the images rather than assuming:
```
node:26-alpine -> v26.8.2 lts=none
node:24-alpine -> v24.21.0 lts=Krypton
node:22-alpine -> v22.23.2 lts=Jod
```
So this moves the published image off an LTS line onto Current. Node 26 is due to become Active LTS in October 2026, about a month out, and nothing in ihasmail needs 26 over 24 — **if the LTS line is preferred, every pin here is a single number and I will happily redo it as 24.** Dependabot proposed 26 because it tracks latest, not because anything required it.
`engines` stays at `>=20.19`. That field is the floor for *running* ihasmail, not the version we build it on, and self-hosters on 20 or 22 are unaffected by this. The README's "recommended" figure follows CI to 26.
## Verified on the runtime, not just in CI
- `npm run typecheck` passes against the Node 26 types.
- `npm test` — 1153 web tests across 113 files, 168 server tests.
- `npm run build` passes.
- `docker build` on `node:26-alpine` succeeds locally; the resulting image reports `v26.8.2`, starts, and answers `/api/health` with `{"ok":true,...}`.
- The login, SSE (`/api/events`) and body-carrying `POST /api/jmap` checks from #323 all pass against a server running on Node 26.8.1.
**Merged** 2026-09-10 as coffey-labs/ihasmail@f2aaa9cea401
<sub>Rebuilt from: git history, session transcript.</sub>
This repo is archived. You cannot comment on issues.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Supersedes #313 (
node:22-alpine→26-alpine) and #315 (@types/node→ 26), which cannot safely land separately.Why one change
Four places describe the Node version, and moving any one alone leaves the build somewhere the others are not:
.github/workflows/ci.yml.github/workflows/publish.yml.github/workflows/release.ymlDockerfile(build + runtime stages)node:22-alpinenode:26-alpineserver@types/node^22.13.10^26.5.1#315 alone would typecheck against APIs the runtime does not have. #313 alone would ship a major that CI never exercised. Together they are coherent.
Read this before deploying it
Node 26 is Current, not LTS. I checked the images rather than assuming:
So this moves the published image off an LTS line onto Current. Node 26 is due to become Active LTS in October 2026, about a month out, and nothing in ihasmail needs 26 over 24 — if the LTS line is preferred, every pin here is a single number and I will happily redo it as 24. Dependabot proposed 26 because it tracks latest, not because anything required it.
enginesstays at>=20.19. That field is the floor for running ihasmail, not the version we build it on, and self-hosters on 20 or 22 are unaffected by this. The README's "recommended" figure follows CI to 26.Verified on the runtime, not just in CI
npm run typecheckpasses against the Node 26 types.npm test— 1153 web tests across 113 files, 168 server tests.npm run buildpasses.docker buildonnode:26-alpinesucceeds locally; the resulting image reportsv26.8.2, starts, and answers/api/healthwith{"ok":true,...}./api/events) and body-carryingPOST /api/jmapchecks from #323 all pass against a server running on Node 26.8.1.Merged 2026-09-10 as coffey-labs/ihasmail@f2aaa9cea4
Rebuilt from: git history, session transcript.