Still pre-1.0, with Ultimate-only IDE support

A pre-1.0 library sits underneath a service that generates projects at scale

The most important sentence in this README is the caveat, and it is worth reading before the module list. Spring Initializr is available on Maven Central, it is still in a pre-1.0 state, major refactoring is still possible, and there is a link to a milestones page for an overview of the changes. Every version number bears that out. The release history runs 0.22.0, then 0.23.0, then 0.24.0, none of which crosses the 1.0 line that would signal a stable API. The cadence is also uneven, with about eight months between the first two and six weeks between the last two. Commits have continued since the last release, most recently on 2026-10-02, so the working branch is ahead of any published artifact by roughly six and a half months. If you depend on this library directly rather than through a generated project, the practical advice is to pin an exact version and read the milestone notes before upgrading, because the maintainers have told you in advance that the shape may change.

The configuration of the production service is in a different repository

This repository is the library. The thing people actually visit, start.spring.io, is configured somewhere else, and the README says so without coyness. It points at a companion project for the configuration of the production instance, and at a specific file inside it, an application configuration under the service's start-site resources. That separation is the single most useful thing to understand about the architecture. Everything you can choose in the web form, which languages and build tools and dependency groups appear, is data in that other repository rather than code here. What lives here is the machinery that turns such a description into a project: the metadata model, the generator, and the web endpoints. It also means you can learn the mechanism from this repository without being able to reproduce the production service from it, because the defaults that make start.spring.io look the way it does are not in the tree.

IntelliJ support means the Ultimate edition, and the other IDEs need outside plugins

The supported-interface list names four IDEs, and they are not equivalent. Two of them are first-party: STS, and IntelliJ IDEA Ultimate, which is the commercial edition. The qualifier is doing real work in that sentence, since the free community edition of IntelliJ is not on the list. The other two are community-maintained: NetBeans needs a plugin maintained by an outside contributor, and VS Code needs one maintained by Microsoft as a separate repository. So the officially blessed list contains one paid product and two third-party plugins whose maintenance and update cadence this project does not control. The command-line story is more open than the IDE story. The library is usable with the Spring Boot CLI, and equally with cURL or HTTPie directly against the endpoints, which is what the custom-web-UI line points at. There are no first-party IDE integrations in this repository at all.

Spring Boot is a replaceable convention set, not a dependency of the engine

The easy misreading is that this is a Spring Boot project generator. It is not. Spring Boot support arrives as an optional module described as defining the conventions for a typical Spring Boot project, and that module can be reused or replaced by your own conventions. The core generator underneath knows about languages, build systems and resources, not about Spring. What the conventions module contributes is the shape of the opinionated output: which dependencies a web application gets, what the generated application class looks like, which files appear. If your organisation has different opinions, you swap that module rather than fighting the generator, which is the extension point the design is built around. Underneath that sit two more extension mechanisms the README calls out directly, a metadata model expressing the available options and several hook-points for custom resource generation. The metadata model is the more fundamental of the two, since it is what defines the menu in the first place.

Eleven module directories, ten of them documented

The modules section lists ten. The tree carries eleven directories with module names. The one absent from the list is initializr-parent, which is the conventional Maven aggregator holding the shared configuration for the build rather than shipping anything, so its omission from a feature-oriented list is defensible even if it will surprise anyone counting directories. The ten that are documented divide into three kinds. Four are infrastructure you would not use directly: a bill of materials for dependency management, the documentation module, a metadata module, and a test-infrastructure module for exercising project generation itself. Three are the optional extensions, an actuator module for additional information and statistics on project generation, the version-resolver that extracts version numbers from an arbitrary POM, and the web module that exposes endpoints for third-party clients. The remaining three are the core generator, the Spring Boot conventions, and the sample custom instance. Three other root directories, eclipse/, git/ and src/, are not modules and are not explained in the README.

Building needs Java 25, and the documentation needs a profile

The build prerequisites are two lines: Java 25 and a bash-like shell. Twenty-five is a demanding floor for a build you might expect to run on whatever JDK is installed, and the repository pins its own expected version in a toolchain file, so a mismatch is likely to be the first thing you hit. The build itself is a wrapper invocation at the root of the project:

$ ./mvnw clean install

and the documentation is generated by a profile rather than by the default path:

$ ./mvnw clean install -Pfull

That second command is worth noting because the failure mode is silent in the sense that nothing tells you the docs were skipped. A plain install gives you a working library and no reference documentation, which is a reasonable trade for build speed. The web module is where the auto-configuration story lives: because initializr-web is a Spring Boot module, adding it to a project is enough to deploy the service, with no manual wiring described. The sample module exists to show the smallest possible custom instance with its own dedicated metadata, and the actuator module is opt-in, so a self-hosted instance that does not add it exposes no generation statistics.

The metadata document is the contract, and it is served over HTTP

There is no fixed list of options in this codebase. The available dependencies, the supported JVM versions and the supported platform versions are all expressed through a metadata model, which means the menu a user sees is data rather than compiled-in behaviour. That same model is served as a web endpoint in a well-known format, and the README names third-party clients as the reason: clients need to discover what is available in order to offer the necessary assistance. So the real integration surface is a metadata document plus a generation endpoint, and the sample custom instance shows how little you need to stand up your own. Two smaller signals about how this is deployed. The repository carries a Cloud Foundry ignore file at the root, which is not mentioned anywhere in the README, suggesting the service is deployed to that platform as well as to whatever start.spring.io runs on. And the version-resolver module, which extracts version numbers from an arbitrary POM, exists so the metadata can stay current against upstream projects without a manual bump.

Editorial conclusion

Spring Initializr suits anyone generating a JVM project from a form or a command line, and anyone who wants to run their own instance with their own dependency catalogue. Four things to check before depending on the library itself rather than through the service. Pin an exact version, because the project has not crossed 1.0 and says major refactoring remains possible. Expect the documentation to be absent from a default build, since generating it needs a separate profile. Decide which IDE story you are on, because the first-party support list contains one paid edition and two plugins maintained elsewhere. And read the milestone notes before an upgrade, since the maintainers have flagged the change set themselves as the thing to look at.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. spring-io/initializr on GitHub