Deploy Apache Solr | (Just Updated) Search Platform, REST API, Password Auth On, Index Survives Redeploys

Apache Solr search server with REST API, password auth on, core ready

Deploy Apache Solr | (Just Updated) Search Platform, REST API, Password Auth On, Index Survives Redeploys

Just deployed

/var/solr

Deploy and Host Apache Solr on Railway

Built for an LLM agent to deploy and use. There is no setup wizard and nothing to fill in: a 32-character admin password is generated at deploy time, a search core named main already exists, and every admin, update and query call must present the password. A stock Solr container serves its whole API to anyone who can reach the port; this template switches that off from the first boot. The contract below lists every URL, variable name and the one script that proves it works.

Apache Solr is the open-source Lucene-based search platform: full-text search, faceting, filtering, highlighting, geospatial search and vector search over JSON documents, all through an HTTP API. This template runs Solr in standalone mode, one node, one core.

About Hosting Apache Solr

This template runs one service, solr, built from the official Apache Solr 10.1.0 image (solr, pinned by digest). Upstream's image runs as uid 8983 and Railway mounts the volume root-owned, so a small boot script (embedded in the start command) fixes ownership, drops privileges with setpriv, and starts Solr with the stock entrypoint. It also writes security.json from the generated password on every boot (BasicAuth plus role-based authorization, so a changed SOLR_PASSWORD takes effect on redeploy), sizes the JVM heap to half the container memory limit and the processor count to the container's CPU quota (the JVM otherwise reads the host's), and listens on the port Railway injects, on IPv4 and IPv6. The first boot creates the core main from Solr's _default configset, which has a managed schema and guesses field types, so you can post JSON documents immediately. Data, configuration and logs live on the volume at /var/solr and survive redeploys. The core takes a few seconds to load after the service turns healthy; retry the first call.

Agent contract

  • Public URL: https:// plus the RAILWAY_PUBLIC_DOMAIN of the solr service, as SOLR_PUBLIC_URL. The API is under /solr, the admin UI at /solr/.
  • Private URL: http://solr.railway.internal:8080 (variable SOLR_PRIVATE_URL), same paths.
  • Credentials: user admin, password in SOLR_PASSWORD.
  • Auth: HTTP Basic (curl -u admin:$SOLR_PASSWORD). Without credentials every call except health returns 401.
  • Health: GET /solr/admin/info/health returns 200 with no credentials. Core readiness: GET /solr/main/admin/ping with credentials returns 200 once the core main is loaded.
# run with SOLR_PUBLIC_URL and SOLR_PASSWORD set; needs curl
A="admin:$SOLR_PASSWORD"
curl -s -o /dev/null -w 'health %{http_code}\n' "$SOLR_PUBLIC_URL/solr/admin/info/health"
curl -s -o /dev/null -w 'anonymous %{http_code}\n' "$SOLR_PUBLIC_URL/solr/admin/cores"
until curl -fs -o /dev/null -u "$A" "$SOLR_PUBLIC_URL/solr/main/admin/ping"; do sleep 3; done
echo core ready
curl -fsS -u "$A" -H 'Content-Type: application/json' -d '[{"id":"1","title_t":"Solr search on Railway"},{"id":"2","title_t":"Agent memory index"}]' "$SOLR_PUBLIC_URL/solr/main/update?commit=true" | grep -o '"status":0'
curl -fsS -u "$A" -G --data-urlencode "q=title_t:railway" --data-urlencode "fl=id,title_t" "$SOLR_PUBLIC_URL/solr/main/select" | grep -o '"numFound":[0-9]*'

A fresh deploy prints health 200, anonymous 401, core ready, "status":0 and "numFound":1. Documents are JSON arrays posted to /solr/main/update?commit=true; queries use /solr/main/select with q, fq, fl, sort, facet and rows. Create more cores with a GET to /solr/admin/cores carrying the query parameters action=CREATE, name (your core name) and configSet=_default, using the same credentials. Official clients (pysolr, SolrJ, solr-client for Node) take the base URL SOLR_PUBLIC_URL/solr or SOLR_PRIVATE_URL/solr and the user and password.

Why Deploy Apache Solr on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Apache Solr on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

  • Agent-ready - generated password, a ready core, contract block and one working script; no setup step.
  • Closed by default - the admin API, updates and queries all need the password, unlike a stock Solr container.
  • Current release - Solr 10.1.0, pinned by digest, so a redeploy never changes the server underneath you.
  • Right-sized - heap and processor count come from the container limits, not from the host.
  • Index survives redeploys - cores, configuration and index files live on a volume.

Common Use Cases

  • Site and product search - full-text search with facets, filters and highlighting over your own documents.
  • Retrieval for AI agents - keyword and vector search over notes, tickets or documents.
  • Log and catalogue search - index JSON records and query them over HTTP.

Dependencies for Apache Solr Hosting

  • None. Solr stores its own data on the volume at /var/solr.

Deployment Dependencies


Template Content

More templates in this category

View Template
RustFS | (Just Updated) S3 Object Store, Public URL and Keys Set
S3-compatible object store, keys and public URL preset, volume kept

SuperSlowSloth
0
View Template
TimescaleDB
A PostgreSQL-based time-series database for analytics on Railway.

Rakit
1
View Template
Garage S3 Storage
Ultra-light S3 server: fast, open-source, plug-and-play.

PROJETOS
8