# Logstash: a server-side pipeline for logs, events and other data

> Logstash is a JRuby-based data processing pipeline in the Elastic Stack. It is the right tool when you need to fan in many sources, transform events, and write them to a stash, but it is not a database and not a lightweight shipper.

**elastic/logstash** — Logstash - transport and process your logs, events, or other data

- Repository: https://github.com/elastic/logstash
- Website: https://www.elastic.co/products/logstash
- Stars: 14,949 · Forks: 3,495
- Language: Java
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/elastic-logstash

## What Logstash is for, and who ends up running it

Logstash is a server-side data processing pipeline. The README describes it as ingesting data from a multitude of sources simultaneously, transforming it, and sending it to a stash. The canonical stash is Elasticsearch, but the output is a plugin choice, not a hard requirement.

The problem it solves is fan-in. If you have application logs, Kafka topics, files on disk and a database, and each one needs the same enrichment before landing somewhere searchable, you write that logic once in a Logstash pipeline instead of once per source. The audience is platform and observability engineers who own that central hop, not application developers who just want to print structured logs.

It is part of the Elastic Stack alongside Beats, Elasticsearch and Kibana. That framing matters: Logstash is the processing stage, not the storage or the query layer. Teams that treat it as a database end up disappointed, because it is not one.

## How a Logstash pipeline actually moves data

The pipeline model is input, filter, output. Inputs read from sources, filters transform events, outputs write them onward. The README states Logstash has over 200 plugins, which is the practical reason the model works: most sources and sinks already have an input or output plugin, so the pipeline is assembled rather than written.

Plugins are not part of this repository. Each is a self-contained Ruby gem hosted under the logstash-plugins GitHub organization and published to RubyGems.org. That split has a direct consequence for anyone filing a bug: the README says to open issues and pull requests for a plugin under its own repository, and gives the Elasticsearch output as the example. Core Logstash stays here.

The core itself is Java plus JRuby. That combination is why the build prerequisites name both a JDK and a Ruby implementation, and why the repository contains both Gradle build files and a Gemfile.template. It also explains the startup characteristics people notice: a JVM boot plus Ruby runtime initialization, which is why the README bothers to document the Drip launcher for development.

## Installing Logstash and sending a first event

The README does not give install steps for end users. It points to the Elastic downloads page for officially released binaries and for debian and rpm packages on supported platforms, and to the elastic.co documentation for getting started guides. If you want a released build, that page is the only source the README names.

Building from source is documented. The prerequisites are JDK version 21 with JAVA_HOME set to the JDK installation directory, JRuby 10.0.5.0, and rake and bundler installed via gem. The README recommends a Ruby version manager such as RVM or rbenv, and notes that the printed output of ruby -v should match the .ruby-version file.

To build, the README sets source and path environment variables, then installs development and default gems through Gradle:

```bash
export LOGSTASH_SOURCE=1
export LOGSTASH_PATH=/YOUR/LOGSTASH/DIRECTORY
./gradlew installDevelopmentGems
./gradlew installDefaultGems
```

The first two exports tell the build where the source tree lives. The Gradle tasks pull in development dependencies and then the default plugins. Expect the second task to be the slow one, since it resolves the plugin set.

Verification is a one-liner that starts Logstash with a stdin input and a stdout output:

```bash
bin/logstash -e 'input { stdin { } } output { stdout {} }'
```

According to the README, Logstash starts and waits for you to enter an event. Typing hello world produces a line containing a timestamp, the host address, and the message text. That is the whole pipeline in miniature: read, pass through, write.

One caveat from the README applies if you adopt Drip for faster JVM startup during development. Drip does not work with STDIN, so a config using the stdin plugin cannot run under it. Set JAVACMD to the drip binary only for configs that do not read standard input.

## Where Logstash is the wrong tool

Logstash is a pipeline, so it holds state only as long as events are in flight. It is not a store and not a query engine. If you need to search what you ingested, that is Elasticsearch, and the README treats them as separate components of the same stack. Reaching for Logstash to answer questions about historical data is a category error.

The second limitation is operational weight. The build prerequisites are a JDK and a JRuby runtime, and the README documents Drip specifically because JVM startup is slow enough to be a problem during development. On every host that runs it, you pay that cost. For a simple file-to-Elasticsearch hop on hundreds of machines, a shipper that does not carry a JVM is the more reasonable choice, and the README itself places Beats in the same stack.

Third, plugin boundaries are a real support boundary. Because plugins live in separate repositories, a bug in the Elasticsearch output is not fixed here. The README is explicit that plugin issues belong in the plugin repository. If your team expects one issue tracker for the whole pipeline, that expectation will not survive contact with the project layout.

## Logstash and Elasticsearch are not substitutes

The most common confusion is treating Logstash and Elasticsearch as alternatives. They are not. Elasticsearch stores and indexes documents and answers queries against them. Logstash moves and reshapes events on their way to a store. The README lists them as separate parts of the Elastic Stack, with Logstash described as the processing pipeline and Elasticsearch named as the natural stash.

A more honest comparison is against other pipeline and shipping tools. The README's own stack answer is Beats: lightweight agents that sit on hosts, with Logstash as the heavier central processing tier. The split is about where the work happens. A shipper collects and forwards with minimal local processing. Logstash receives from many of those shippers at once, applies filters, and fans the result out. If your transformation needs are trivial, the central tier is an extra hop to operate.

On the plugin side, the difference from a monolithic tool is architectural. Because every plugin is a gem in its own repository, you can write and version your own without forking core Logstash. The README calls this out as the project's extensibility model and points to the contributing guide for developing and testing plugins. That is a genuine advantage for teams with proprietary formats, and it is also the reason the ecosystem is fragmented across repositories.

## Maintenance, releases and the licence split

The repository is not archived, and the last push was on 2026-09-18. Recent releases include v9.5.4 and v9.4.7, both dated 2026-09-15, and v9.5.3 dated 2026-09-03. Two maintained minor lines are receiving patch releases, which is the pattern to plan around: pick a line and expect to track its patches rather than jumping between majors.

Upgrade cost is concentrated in plugins, not core. Since plugins are separate gems, a plugin can lag a core release, and the README's instruction to file plugin issues in their own repositories is also a hint about where compatibility problems surface. Before upgrading, check the plugin versions you depend on rather than the core version alone.

Licensing needs care and is not something to resolve from a README. The repository licence field is NOASSERTION, the top level contains LICENSE.txt and NOTICE.TXT along with a licenses directory, and the README states that the source includes both OSS-licensed code and Elastic-Licensed X-Pack features and functions. It documents an OSS environment variable to build using only OSS-licensed code. If your policy depends on which licence applies to the artifact you deploy, that distinction is the thing to read up on, and a lawyer is the right person to ask, not this article.

## Conclusion

Adopt Logstash when you need a central pipeline that ingests from many sources at once, transforms events, and writes to Elasticsearch or another stash. Do not adopt it as an Elasticsearch replacement, and do not use it as a lightweight per-host shipper where Beats fits better. Before committing, verify the plugin you need exists under the logstash-plugins organization, check that your JDK matches the documented version 21, and confirm the licensing terms of the build you intend to run, since the repository ships both OSS-licensed code and Elastic-Licensed X-Pack features behind the OSS environment variable.

## FAQ

### What is Logstash used for?

It is a server-side data processing pipeline that ingests data from many sources at once, transforms it, and sends it to a stash such as Elasticsearch. It is part of the Elastic Stack with Beats, Elasticsearch and Kibana.

### What is the difference between Logstash and Elasticsearch?

Elasticsearch is the store in the Elastic Stack, while Logstash is the pipeline that moves and transforms events before they reach a stash. The README names Elasticsearch as Logstash's natural output, so they are complementary rather than competing.

### How do I install Logstash?

The README points to the Elastic downloads page for officially released binaries and for debian and rpm packages on supported platforms, and to the elastic.co documentation for getting started guides. It does not give end-user install steps in the repository itself.

### How do I install Logstash plugins?

Plugins are self-contained Ruby gems hosted under the logstash-plugins GitHub organization and published to RubyGems.org. For a source build, the README installs default plugins and other dependencies with the Gradle task installDefaultGems.

## Sources

- [elastic/logstash on GitHub](https://github.com/elastic/logstash)
- [Issues](https://github.com/elastic/logstash/issues)
- [Project website](https://www.elastic.co/products/logstash)
- [README](https://github.com/elastic/logstash/blob/main/README.md)
- [Releases](https://github.com/elastic/logstash/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/elastic-logstash