# spring-cloud-netflix: Eureka in Spring Cloud, and What the Repo Still Contains > Spring Cloud Netflix is the Spring integration for Netflix OSS components, and the repository today is mostly Eureka client and server modules. Here is what the build ships, how to add it, and where it stops being the right choice. **spring-cloud/spring-cloud-netflix** — Integration with Netflix OSS components - Repository: https://github.com/spring-cloud/spring-cloud-netflix - Website: http://cloud.spring.io/spring-cloud-netflix/ - Stars: 4,967 · Forks: 2,453 - Language: Java - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/spring-cloud-spring-cloud-netflix ## What spring-cloud-netflix actually covers in 2026 The README lists two features, and both are service discovery. Eureka instances can be registered and clients can discover those instances through Spring-managed beans, and an embedded Eureka server can be created with declarative Java configuration. That is the whole feature list in the document. The repository layout agrees. The top level holds spring-cloud-netflix-eureka-client, spring-cloud-netflix-eureka-server, spring-cloud-starter-netflix-eureka-client, spring-cloud-starter-netflix-eureka-server, and spring-cloud-netflix-eureka-client-tls-tests. There are no Hystrix, Ribbon or Zuul modules at the root, even though the repository topics still carry netflix-hystrix, netflix-zuul and ribbon. Treat the topics as history, not as a description of what a current build produces. So the audience is narrow and specific: teams running Spring Boot services that need a registry, and teams that want that registry to be an embedded Eureka server they control rather than a hosted one. If you arrived looking for the circuit-breaker and client-side load-balancing stack that made this project famous, the code for it is not here. ## How registration and discovery flow through Spring beans The mechanism described in the README is deliberately thin, and that is the point. A service starts, the Eureka client registers it with a Eureka server, and other services look instances up. The Spring-specific part is that both sides are exposed as Spring-managed beans, so injection is the interface rather than a hand-written HTTP call to a registry API. The embedded server is the second half. Instead of pointing every service at an externally operated registry, you can stand up a Eureka server inside a Spring application using declarative Java configuration. That keeps the registry inside your own deployment and inside your own upgrade cycle. The repository splits these concerns into separate Maven modules on purpose. A service that only consumes discovery pulls the client module or its starter. A service that hosts the registry pulls the server module or its starter. The tls-tests module exists because the client can talk to a server over TLS, and that path is exercised separately from the ordinary client tests. ## Building spring-cloud-netflix from source with Maven and JDK 17 The README pins the toolchain. You need JDK 17, and the project uses Maven for most build-related activities. Clone the repository and run the wrapper: ```bash ./mvnw install ``` The wrapper is checked in as mvnw and mvnw.cmd, so you do not need Maven on your PATH. If you prefer your own Maven, the README allows it provided the version is 3.3.3 or newer, and warns that you may need to add -P spring if your local settings do not declare the Spring pre-release repositories. That profile is not optional in practice: the README states plainly that Spring Cloud projects require the spring Maven profile to resolve milestone and snapshot repositories, and that without it you may see build errors. Memory is a real constraint. The README suggests raising the heap through MAVEN_OPTS with a value such as -Xmx512m -XX:MaxPermSize=128m, and notes the project tries to cover this in the .mvn configuration. If your build fails on memory, that is the lever. For the documentation site, the README gives a separate command that builds asciidoc sources with Antora from modules/ROOT/: ```bash ./mvnw -pl docs -P docs antora:antora ``` One module is not covered by the default build. The README notes that to build spring-cloud-netflix-hystrix-contract along with the entire Netflix project you run the build.sh script in the scripts directory. That module is the exception that proves the rule about what the root build produces. ## Adding the Eureka client to an application For application code, you consume the published starters rather than building the repository. The starter artifacts are named spring-cloud-starter-netflix-eureka-client and spring-cloud-starter-netflix-eureka-server, matching the module directories at the repository root. A Maven dependency on the client starter is the entry point, and the version must come from the Spring Cloud release train your Spring Boot version belongs to. The README does not print a dependency snippet, so take the coordinates and the version from the release train rather than copying a version out of this article. Once the starter is on the classpath, the registration and discovery behaviour runs through Spring-managed beans, which is what the README means by clients discovering instances without writing registry calls by hand. The README does not document the individual configuration properties for the client or the server, so read the reference documentation under docs/ for the keys rather than guessing at property names. ## Where this project is the wrong tool The first limitation is scope. If your architecture depends on a circuit breaker, client-side load balancing or an edge proxy, this repository does not supply them. Nothing in the README's feature list or the root module list provides those capabilities. Choosing spring-cloud-netflix for a greenfield system on the assumption that the full Netflix OSS stack is included is a mistake you will discover at integration time. The second is the build contract. JDK 17 and the spring Maven profile are stated requirements, not suggestions. A team pinned to an older JDK, or building in a network-restricted environment that cannot reach Spring milestone and snapshot repositories, will fight the build before writing any application code. The third is documentation coverage in the repository itself. The README explains how to build and how to generate docs. It does not document the client's configuration surface or the server's operational behaviour. For a registry that other services depend on for liveness, that gap matters: the README does not document rollback, failover semantics, or what happens to registered instances when a server restarts. You will be reading the asciidoc sources under docs/ and the module code, not the front page. ## Eureka versus a plain Spring Cloud DiscoveryClient setup The honest alternative is not a rival product but a different layer of the same stack. Spring Cloud provides a DiscoveryClient abstraction, and Eureka is one implementation behind it. If you write your services against the abstraction, the registry becomes swappable; if you write them against Eureka-specific beans and configuration, it does not. The difference in approach is operational. Running the embedded Eureka server, which the README describes as creatable with declarative Java configuration, means you own a stateful service that every other service depends on at startup. Consuming a registry that someone else operates removes that responsibility from your team but adds a dependency you do not control. The repository supports the first model directly and is neutral about the second. A second practical difference is what you get in the box. Because the current repository is Eureka-only, adopting it is a smaller commitment than the project's reputation suggests. You are adding discovery, not a whole resilience toolkit, and you should plan the rest of that toolkit separately. ## Maintenance, versions and the Apache 2.0 licence The repository is not archived, and the last push was on 2026-09-17. Recent releases are v5.0.2 and v4.3.3, both dated 2026-06-11, with v5.0.1 before them on 2026-01-28. Two maintained lines, 5.x and 4.3.x, are being released in parallel, which is the practical upgrade fact: you must know which line your Spring Boot generation tracks before you pick a version. Upgrade cost is dominated by that pairing. Spring Cloud release trains move with Spring Boot, and the README's JDK 17 requirement means a JDK upgrade may be a precondition for a Spring Cloud Netflix upgrade. Budget for the toolchain change, not just the dependency bump. The licence is Apache-2.0, and the README points to the LICENSE.txt file in the repository. That is a permissive licence, and the README explicitly calls it non-restrictive in the contributing section. This is a description of the licence text, not legal advice; check LICENSE.txt and your own obligations. ## Conclusion Adopt spring-cloud-netflix when you want Eureka service registration and discovery wired through Spring-managed beans, and you are comfortable on JDK 17 with Maven 3.3.3 or newer. Do not adopt it expecting working Hystrix, Ribbon or Zuul integration: the repository layout holds eureka-client, eureka-server, their two starters, and a TLS test module, and the README's feature list names service discovery only. Verify first that the artifact version you pick matches your Spring Boot line, then confirm the module you actually need exists under the repository root before you write any configuration. ## FAQ ### What is spring-cloud-netflix? It is the Spring integration with Netflix OSS components, per the repository description. The README's feature list covers service discovery only: Eureka instances can be registered and discovered through Spring-managed beans, and an embedded Eureka server can be created with declarative Java configuration. ### What is spring-cloud-netflix Eureka? Eureka is the service discovery component this repository integrates. The README states that Eureka instances can be registered and that clients can discover them using Spring-managed beans, and that an embedded Eureka server can be built with declarative Java configuration. ### How do I build spring-cloud-netflix from source? Install JDK 17, clone the repository, and run ./mvnw install. The README notes that you can use your own Maven at 3.3.3 or newer, but that you may need to add -P spring if your settings do not declare the Spring pre-release repositories. ### Which Maven artifacts does spring-cloud-netflix publish for Eureka? The repository root contains spring-cloud-starter-netflix-eureka-client and spring-cloud-starter-netflix-eureka-server alongside the underlying spring-cloud-netflix-eureka-client and spring-cloud-netflix-eureka-server modules. The README does not list dependency coordinates or versions, so take those from your Spring Cloud release train. ### Does spring-cloud-netflix still include Hystrix, Ribbon or Zuul? The repository topics mention netflix-hystrix, netflix-zuul and ribbon, but the root module list contains only Eureka client and server modules, their starters, a TLS test module and a hystrix-contract module built separately via scripts/build.sh. The README's feature list names service discovery only. ## Sources - [License: Apache-2.0](https://github.com/spring-cloud/spring-cloud-netflix/blob/main/LICENSE) - [Project website](http://cloud.spring.io/spring-cloud-netflix/) - [README](https://github.com/spring-cloud/spring-cloud-netflix/blob/main/README.md) - [Releases](https://github.com/spring-cloud/spring-cloud-netflix/releases) - [spring-cloud/spring-cloud-netflix on GitHub](https://github.com/spring-cloud/spring-cloud-netflix) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spring-cloud-spring-cloud-netflix