Apache Solr's four examples, its Gradle dev build and its two container routes

Lucene underneath, a service and an interface on top

Solr describes itself as an open source, multi-modal search platform built on Apache Lucene, and says it powers full-text, vector and geospatial search at many of the world's largest organizations. The code is Java and the licence is Apache-2.0. The top-level tree tells you more than the prose does. platform/ and solr/ carry the server work, ui/ is a separate directory for the web layer, dev-docs/ holds developer documentation, and dev-tools/ and build-tools/ sit next to a Gradle build described by build.gradle, settings.gradle and the gradlew wrapper. Two dependency lockfiles are checked in, gradle.lockfile and settings-gradle.lockfile, and a kotlin-js-store/ directory is present as well. The project does not explain that layout anywhere in its own text, so treat it as a structural observation rather than an architecture claim: this is a multi-module build with the server, the interface and the documentation kept in separate trees.

Four bundled examples decide what Solr looks like to you

The fastest way to read Solr's shape is the set of examples the project ships. Each one is started with the same script and the -e flag, and each exists to show a different mode. The cloud example runs SolrCloud, the distributed mode. The techproducts example illustrates many of Solr's core capabilities, so it is the right pick when you want a single command to expose a wide surface. The schemaless example shows a schema being inferred from data during indexing. The films example starts from the _default configset and adds explicit fields dynamically. If you want to run the techproducts example, enter:

bin/solr start -e techproducts

After the process starts, the admin interface is reachable at http://localhost:8983/solr/ in a browser, and that URL is the first place to confirm the server is live. The choice among the four is worth a minute of thought, because the examples differ in what they teach: cloud is about deployment topology, schemaless is about how documents arrive, and films is about evolving a configuration.

The Gradle dev build lands under solr/packaging/build/dev

Solr uses Gradle for its build system, and the project documents two commands for working on it rather than for installing a release. The first builds a Solr dev distribution:

./gradlew dev

The second runs that distribution locally:

cd ./solr/packaging/build/dev
bin/solr start

The path in the second block matters more than it looks. The dev distribution is not the top-level solr/ directory, it is the build output under solr/packaging/build/dev, and that is where the bin/solr script ends up. gradlew.bat sits next to gradlew for Windows shells. If you want to run Solr without downloading a distribution, this is the route the project documents, and the source build guide is referenced as dev-docs/solr-source-code.adoc, with wider notes in the dev-docs tree.

bin/solr manages collections, and post handles the first documents

Once the server is up, the useful part of the script shows itself. The project states that you can use the bin/solr script to create and manage Solr collections, and that the same script carries a post tool for indexing sample data. Those two verbs shape the whole first session. Collection management stays inside one tool rather than a set of hand-edited config files, and posting data is a first-class command rather than a request you assemble by hand. The interface that shows what happened is fixed at http://localhost:8983/solr/. The quickstart path does not explain how to move that port or change the context path, so treat 8983 and the /solr/ prefix as the defaults the quickstart shows.

Docker and Kubernetes are two routes, and one of them needs the operator

Solr has two container paths and they are not interchangeable. For plain containers there is an official image on Docker Hub, with a guide page for Solr in Docker inside the reference guide. For Kubernetes the wording is specific: Solr has official support for running on Kubernetes in the official Docker image, and the details, tutorials and instructions live at the Solr Operator home at solr.apache.org/operator. That distinction has practical consequences. Running the image directly and running Solr as a managed workload on a cluster are separate setups, and the second one leans on the operator. The project gives no shell command for either case, so there is nothing to copy out of the source tree; the deployment guide and the operator documentation are where the commands live.

No GitHub releases, so the changelog lives in the tree

Maintenance signals here are unusual in one specific way: the repository has no GitHub releases. Change records sit in the tree instead, with a top-level CHANGELOG.md and a changelog/ directory beside it. The last push was on 2026-10-17 and the repository is not archived, so the code is moving. What you cannot get from the tree is the upgrade story. The README does not document rollback, does not state a supported version-to-version upgrade path, and does not publish a compatibility matrix. Installation detail is pointed at the Deployment Guide and its system requirements page rather than kept in the source. If your evaluation depends on what a Solr upgrade costs, that guide is the first page to read, because nothing in the repository answers it.

Solr wants to be a server, and its install steps are not in the repository

Two limits show up without running anything. First, everything about running Solr as a service is documented on a website rather than in the source tree: the deployment guide, the system requirements page, the Docker page and the tutorial series all live at solr.apache.org, and the README only links to them. The repository is enough to build the code and to read it, which is what dev-docs/ is for, but not enough to install from. Second, the shape of the project assumes a network-facing service with collections, an HTTP interface and an admin interface. If you want a search library that a single process embeds and where nothing listens on a port, you picked the wrong category of tool, and no configuration change turns a server into a library. A top-level THREAT_MODEL.md and SECURITY.md also indicate that the exposure of a running instance is something the project expects to be examined.

Apache-2.0, and where the questions actually get answered

The licence is Apache-2.0, with LICENSE.txt and NOTICE.txt at the top level, and the project headers carry the same terms. If you ship Solr inside a product, the notice obligations that come with that licence travel with it, though how that lands in your own distribution is a question for your legal review and not something to settle from a source tree. Support for users runs through the users mailing list, the Solr Community Channel on Slack, and IRC on #solr at libera.chat. Contributors work through a parallel set: the #solr-dev channel in the the-asf Slack organisation, the JIRA tracker under the SOLR project, and #solr-dev on libera.chat. CONTRIBUTING.md is the stated starting point for anyone intending to contribute, and AGENTS.md and dev-tools/ sit alongside it for tooling conventions.

Editorial conclusion

Adopt Apache Solr when you need full-text, vector or geospatial search served over HTTP with collection management and an admin interface, and when someone on your team will read the reference guide. Do not adopt it if you want a search library embedded in a single process with nothing listening on a port. The repository does not state an upgrade path, a rollback procedure or a compatibility matrix, so open the Deployment Guide system requirements page, the Solr-in-Docker page and the Solr Operator home before committing, and confirm there that the upgrade story you need is written down.

Frequently asked questions

Official sources

1. apache/solr on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README