LoginSign Up
← Back to all sparks
E

Eureka

DEVOPS
Velocity2.5

REST-based service registry for resilient load balancing and failover

github.com/Netflix/eureka ↗

Eureka broke a two-and-a-half-year silence with a release candidate, not a release.

service-discoverymaintenance-modecve-patchingjvm-performancenetflix-oss
◆Current state
Netflix's service registry had been quiet since early 2024, when three release candidates for 1.10.19 were cut in a single day with identical commit lists and never promoted. A fourth candidate in August 2026 finally moved: allocation-reduction work backported from the 2.x line, VIP address lookup metrics, servo replaced with spectator in the client, and xstream and jettison upgraded for known CVEs. The 2.x branch's last visible activity, 2.0.2, was two dependency-level changes.
◆Where it's heading
The shape of this release is maintenance by a project that still has production weight but no active feature agenda. The work that landed is dependency hygiene, allocation reduction and observability — what you ship to keep an existing fleet running, not what you ship to win new adoption. That 1.10.19 has sat in candidate state for over two years while the 2.x line stalled tells its own story.
◆Prediction
The entries do not support a confident call on whether 1.10.19 is promoted to a final release; the pattern so far is candidates that expire rather than ship.

◆Recent moves

  1. 2d ago

    First movement in two years: perf backports and CVE upgrades

    The first substantive Eureka change since early 2024. Allocation-reduction optimisations backported from 2.x, VIP lookup metrics and the servo-to-spectator client swap are real improvements, but they arrive as another release candidate on a version that has been in candidate state since 2024.

    View source ↗
  2. 2y ago

    Two-change patch on the 2.x line

    An instance-info copy avoided and a jettison upgrade. The last visible activity on the 2.x branch.

    View source ↗
  3. 2y ago

    Third 1.10.19 candidate, same commit set

    One of three candidates cut within hours of each other with an identical commit list. It restates the ENI/EIP support and allocation work rather than adding to it.

    View source ↗
  4. 2y ago

    Second 1.10.19 candidate, same commit set

    Identical content to the candidates either side of it; the sequence reads as retag attempts rather than distinct releases.

    View source ↗
  5. 2y ago

    First 1.10.19 candidate, same commit set

    The first of the three same-day candidates, carrying the ENI/EIP support and ResponseCacheImpl allocation fix that all three list.

    View source ↗