English

Node.js, Docker and Go: Three Quiet Changes That Can Break Your Pipeline

Three small changes landed in the last two weeks. None is a crisis. Each can quietly break a pipeline or leave a service on a runtime that no longer gets fixes.

By Prasad KukkalaDevOpsWhat changed9 min read

Read in: English · తెలుగు · हिन्दी

Sign in to save

Illustration of a pipeline of three linked machine modules joined by pipes: a green hexagonal module, a blue shipping-container module and a blue module with a small display plate, each with an amber warning light, standing for runtime, container and language changes that can quietly disrupt a software pipeline.

What changed without your pipeline knowing

Some of the most frustrating breakages after an update come from small changes that nobody planned for. A default value moves. A support date passes. A version number means something different from last year.

AI-generated conceptual illustration of a pipeline with three linked modules. It is not a diagram of any real system or product.

Three changes like this arrived in the last two weeks. Node.js is changing how it numbers and supports its releases. Docker Desktop changed how it stores container logs by default. And Go 1.25 stopped getting security fixes just as a large batch of them shipped.

None of these is a crisis. Each is easy to miss, and each is a short check.

All three share one thread: support dates and defaults. A tool you did not touch can still change under you, because the thing it depends on moved. This article takes each change in turn, says who is affected, and ends with a short checklist.

Node.js: a new release model takes effect

The Node.js project announced earlier this year a new release schedule, with one major release a year instead of two. That change now begins to take effect. Node.js 26 is the last release under the old model. From version 27 onward, there is one major release each April, and every release becomes a long-term support (LTS) release.

LTS means the project promises to keep fixing serious bugs and security problems for a long time. Under the old model, only even-numbered releases got LTS, and odd-numbered releases were short-lived. Many teams skipped the odd ones, yet the volunteers who run Node.js still had to maintain them.

The new model removes the odd/even split. Version numbers will also match the year: 27.0.0 arrives in 2027, 28.0.0 in 2028.

There is also a new early-testing stage called Alpha. Each future version spends six months in Alpha, then six months as Current, then 30 months in LTS. Alpha builds carry names like 27.0.0-alpha.1. They are meant for testing, not production, and the project says their behaviour can change between builds.

For the next few weeks, the dates matter more than the model. These come from the Node.js release schedule:

Node.js release lines and the dates they enter Long-Term Support, Maintenance and end of life, from the Node.js release schedule
VersionEnters LTSEnters MaintenanceEnd of life
2229 Oct 202421 Oct 202530 Apr 2027
2428 Oct 202520 Oct 202630 Apr 2028
2628 Oct 202620 Oct 202730 Apr 2029

Maintenance is the last stage before end of life. A release in Maintenance still gets critical fixes, but new work stops. Node.js recommends that production applications run only on an Active LTS or Maintenance release, so Node.js 24 is still a safe place to be on 20 October.

My reading of this schedule is that for eight days, from 20 to 28 October, no Node.js line is in Active LTS. Node.js 22 and 24 are both in Maintenance, and Node.js 26 is still Current. That is not a problem in itself. It does mean that anyone who says “just use the Active LTS” has to wait until 28 October for a clear answer.

What to do. If you run Node.js 24 in production, you are fine, but start planning the move to 26 after it becomes Active LTS on 28 October. If you run Node.js 22, note that it ends on 30 April 2027. If you maintain a library, add the Alpha line to your tests early. The project’s own advice is that testing only on LTS means you hear about bugs after your users do.

Docker Desktop: the default log driver changed

This one is the most likely to cause a surprise, so it gets the most space.

Every container writes messages to its output. Docker stores those messages through a logging driver. For years, the default on most setups was json-file, which writes each message as a line of JSON in a plain file.

That file grows without limit unless you set one. Log collectors, which are programs that read container logs and send them somewhere else, often read these files directly.

Docker Desktop 4.94, released on 5 October, changed the default for new Linux containers to a driver called local. The release notes give the reason: to enable automatic log rotation. Rotation means old logs are removed or compressed so they do not fill the disk. By default local keeps up to five files of 20 MB each and compresses the older ones, which is about 100 MB per container.

That is sensible, but the local driver does not store logs in the same shape. Docker’s own documentation says its files are designed to be used only by the Docker daemon, and warns that outside tools touching them may interfere. The files are in a binary format, not JSON lines.

A third-party test shows what this can mean for a collector that reads files. The DevOps Daily team ran Fluent Bit, a common log collector, with its standard setup for Docker log files. Against json-file containers with no size limit it read all 500,000 test lines. Against local containers it read none, because its usual file pattern does not match the files the local driver writes.

When they pointed it at the local file directly, it read records but could not decode any of them. This is one test run on Docker Engine 29.9.0 on a Raspberry Pi, not on Docker Desktop, and it covered only Fluent Bit. Collectors that read logs through the Docker API, rather than from files, were not tested.

A second kind of breakage has already appeared in code. The Docker library for Python returns nothing from containers.run() when the container uses the local driver, because it only reads output for json-file and one other driver. A tool called DataHub hit this in its setup check and pinned json-file for its short-lived container as a workaround. A fix has been proposed in the library.

The people affected are mainly developers on Docker Desktop 4.94 or later whose local setup copies a production logging pipeline. Servers running Docker Engine are not changed by this release.

The change also applies only to new containers. Containers you already have keep the driver they were created with until you recreate them.

What to check. Run this to see the default on your machine:

docker info --format '{{.LoggingDriver}}'

And this to see the driver of each container you already have:

docker ps -aq | xargs docker inspect --format '{{.Name}} {{.HostConfig.LogConfig.Type}}'

If you find local and your collector reads log files, you have two choices. You can switch the collector to one that reads through the Docker API. Or you can set json-file with a size limit, which keeps the old file format. The limit does throw away the oldest lines:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Set it in the Docker daemon settings, then recreate your containers so they pick it up. For one service, you can set the same options in a Compose file instead.

A short note on a different release. Docker Engine 29.9.1, released on 14 October, is a separate update from Docker Desktop 4.94. It moves containerd, the component that runs containers, to version 2.4.2.

That fixes a crash when pulling an image whose descriptor carries a malformed annotation digest (CVE-2026-95839) and two other problems that a hostile registry could use to crash containerd or fill a disk. If you run Docker Engine on servers, that update is the one to schedule.

Go: version 1.25 has no fixes coming

On 8 October the Go team released versions 1.27.2 and 1.26.9. Together they fix 15 security problems. Most are in the standard library’s web server and client code, in net/http. The Go announcement lists eight there, with others in crypto/tls, the go command, HTML templates, text and multipart parsing, and one for Windows.

The one most teams will hear about is CVE-2026-97032. In an HTTP/2 server, two parts of the code changed the same table at the same time without coordination. A hostile client can use this to crash the server. A crash caused by a remote client is called a denial of service.

It was reported by RyotaK of GMO Flatt Security. The fix is in Go 1.26.9, Go 1.27.2, and version 0.60.0 of the golang.org/x/net package for programs that use its HTTP/2 code directly.

Go supports each major release until two newer major releases exist. Go 1.27.0 shipped on 19 August, so Go 1.25 is now outside that window. Its last release is dated the same day. That means these fixes will not be added to Go 1.25.

The vulnerability record does not say whether Go 1.25 itself is affected by the HTTP/2 problem. You do not need to find out. A service on an unsupported runtime does not get fixes for the next problem either.

Two warnings before you upgrade. Some of these fixes change behaviour on purpose:

  • The HTTP/1 client and server now close the connection after any CONNECT request.
  • The reverse proxy in net/http/httputil now answers incoming CONNECT requests with 405 Method Not Allowed.
  • Requests with more than 200 byte ranges in a Range header are now ignored by the built-in file-serving helpers. A setting named GODEBUG=httpservecontentmaxranges=0 turns this off.

If you run proxies or anything that touches CONNECT, test after upgrading. Everyone else can treat it as a routine update.

What to check. Run go version on your build machines and in your container images. If it says 1.25 or older, plan the move. If you can, run Go’s govulncheck tool on your code, which reports only the known problems your code actually calls.

How much you need to know

Know. Every developer should know that support dates and defaults change, and that these three changes exist. You do not need the details of each one.

Use. People who own a pipeline, a base image, or a runtime need working knowledge. That means knowing which Node.js line you run, which Docker logging driver your containers use, and which Go version your services were built with.

Master. Platform leads who set version policy for many teams need to understand the trade-offs. That includes how long to stay on a Maintenance release, when to pin a default so it cannot move, and how to test early against Alpha or release-candidate builds.

What you can ignore for now

You can skip the Node.js 27 Alpha unless you maintain a library. You can skip the details of the individual Go problems unless you run HTTP/2 servers facing the internet. And you can ignore Docker’s log changes if your containers run on Docker Engine and your logs already go through the Docker API.

What to do next

Pick the three lines that apply to you and run them this week:

  • node -v, and compare the result with the table above.
  • docker info --format '{{.LoggingDriver}}', and check your collector.
  • go version, and look for 1.25 or older.

If your team has no list of runtime versions in use, that is the real finding. A short table of “what we run and when it ends” will catch the next quiet change before it catches you.

For related reading, see GitHub Actions Is Changing, which covers another platform change that affects pipelines, and OpenTelemetry: Why Owning the Telemetry Pipeline Matters, which looks at where logs and other signals should flow.

Go Deeper

Report a correction

Corrections go to the editor and are never published automatically. No account needed.

Written by Prasad Kukkala

Related · DevOps

More in this topic