adsb-receiver installs the whole ADS-B ground station stack natively

A native install instead of a container image

The project exists for a stated reason, and the reason is a reaction to how the community packages software. It continues to realize that for some, Docker and premade images are not the most optimal solution. The README argues that the move towards premade and Docker and other PaaS images has become popular, that Docker images require additional software and in some cases result in additional overhead, and that they make trivial configuration changes more complicated than they should be. Most of those solutions also come with preinstalled software one may never use as part of the image.

The alternative this project offers is the ability to choose and install only what you want or need natively across a wide range of devices with minimal command line experience.

So the deliverable is an installer script, not a library or a service. The repository layout matches: `install.sh` at the root, a `bash/` directory for the scripts, a `build/` directory, and `CHANGELOG.md` and `CREDITS.md` alongside the README. The language the project is recorded in is PHP, which is a curiosity given the shell implementation, and the repository is MIT licensed.

The audience is a hobbyist or tinkerer with a Raspberry Pi and an RTL-SDR dongle who wants a working aircraft tracker without hand-assembling six upstream projects. The README does not discuss the radio hardware at all, which means that part is assumed knowledge.

Two commands to install, one to update

The installation instructions are short enough to paste.

    sudo apt-get update
    sudo apt-get install git
    git clone https://github.com/jprochazka/adsb-receiver
    cd ~/adsb-receiver
    chmod +x install.sh
    ./install.sh

Two things stand out. The install runs with sudo, because it installs system packages and services, and the script is made executable first, which is a small reminder that you are about to run code you have not read.

Updating an existing installation is the same idea, and the README explains the branch behaviour precisely. Your local repository master branch will be updated each time install.sh is executed, unless either the `--development` or `--branch <branch>` switch is used, and unless you are testing an upcoming release or wishing to contribute you will generally not need either of those switches.

    cd ~/adsb-receiver
    ./install.sh

So the update path is re-running the installer, and the switches exist for people who want to sit on a specific tag or track the development branch. For an operator this is the interesting part: the installer is the deployment tool, and the repository is the release mechanism, which means the difference between a stable installation and an experimental one is a single flag.

The decoders the installer can put on the machine

The decoders section lists the software the scripts can install, and each entry names an upstream project so you can see what you are getting.

ACARSDEC is the ACARS decoder, from the TLeconte repository. Dump1090, from FlightAware, is the long-lived ADS-B decoder. Dump978, also from FlightAware, handles the 978 MHz UAT side of ADS-B. Dumpvdl2, from szpajder, decodes VDLM2. Readsb, from wiedehopf, is the modern decoder that grew out of the dump1090 line, and VDLM2DEC from TLeconte is the VDLM2 counterpart to ACARSDEC.

That list is a good summary of the reception problem. ADS-B at 1090 MHz, UAT at 978 MHz, ACARS over VHF and VDLM2 over the same aeronautical VHF band are four different signals, and you need a decoder for each one you care about. The installer exists so you can pick the subset, and the upstream links make the provenance of each piece clear.

Two of these are alternatives to each other rather than complements, since readsb and dump1090 do the same job. The README does not say which to choose, so that decision is left to the operator, and it is the kind of decision the installer's interactive prompts presumably handle.

Feeder clients for the public tracking networks

The feeders section is a list of the public networks you can contribute to, each with the upstream project and its site. The ADS-B Exchange Feeder Client, the AirNav Radar Client, the Airplanes.live Feeder Client, FlightAware's PiAware, the Flightradar24 Feeder Client, the Fly Italy ADS-B Feeder Client, the OpenSky Feeder Client and the Plane Finder ADS-B Client.

The reason to install these is a trade rather than a benefit. You receive the aircraft data that everyone receives, and in exchange your receiver's data is pooled and used to improve that network's coverage. A single receiver in a rural area contributes to other people's maps, and the networks are where the traffic data comes from.

The practical point for a reader is that this is optional per service, and the installer appears to treat them as choices. Nothing in the README obliges you to run every feeder, and running one is a decision about contributing your location's coverage to a commercial or community dataset.

The extras section adds a fourth kind of tool: Beast-Splitter, which splits the Beast binary output that dump1090 style decoders produce so several consumers can share one receiver, DuckDNS.org support for a stable hostname, Graphs1090 for the performance graphs, and tar1090 for the tarpit of unknown aircraft.

The portal: lite or advanced, and what it costs you

The ADS-B Portal is the part of the project that is not an upstream tool, and it is where the design decisions are.

The feature list is substantial. It saves all flights seen and displays a plot for the flight. It saves all ACARS and VDLM2 messages received and lets you view them. You control what is displayed online via a web based administration area. There is a more uniform website layout that can be easily navigated, web accessible dump1090 and system performance graphs, and easy access to live dump1090 and dump978 maps. There is a blog for sharing aircraft tracking experiences, visitors can be informed when specific flights are being tracked, administrators can be informed by email when specific flights are being tracked, and the look of the portal can be customised through a custom template system.

The choice you make at setup matters more than the feature list. You have to choose between a lite or advanced installation, and the README says the advanced features add flight logging and plotting and should only be chosen on devices running a sturdy data storage solution. It then warns that anyone using an SD card as their storage medium should not attempt the advanced features.

That warning is the whole story of the project in one line. Everything the portal does, it does by writing data, and the most common host for this hardware is a Raspberry Pi whose storage is an SD card, which is the worst possible place to write a growing log of flights.

Supported systems, and where the gaps are

The project currently supports a specific set of Linux distributions. Raspberry PI OS, legacy and current. Debian Bookworm and Trixie. Ubuntu Jammy Jellyfish, Noble Numbat and Questing Quokka. The README adds that these scripts should work most any Debian based distributions, which is a statement of intent rather than a tested configuration.

Support is available through the repository through the use of the issue tracker or discussions.

That is the documented support surface, and it is the first thing to check. Running the scripts on anything else is an experiment.

The bigger gap is what the README does not cover at all. There is no discussion of the radio hardware, the antenna, the RTL-SDR driver, the frequencies, or the wiring of an aerial to a receiver. For a project whose entire purpose is receiving aircraft transmissions, that omission is telling. The installer assumes you already have a working receiver, and the parts that decide whether you will actually receive anything are outside its scope.

The alternative approach, which the README names at the start, is a prebuilt image or a Docker container. The difference is exactly what the project argues about: an image is disposable and reproducible but carries software you will not use, while a native install gives you a machine you have to maintain. The releases here are v2.8.12 from 2026-08-17, v2.8.11 from 2026-08-15 and v2.8.10 from 2026-04-09, and the last push was on 2026-08-17, so the project is still being worked on, with the patch level moving quickly.

Editorial conclusion

Adopt adsb-receiver when you want an ADS-B receiver assembled natively on a Raspberry Pi or a Debian or Ubuntu host, with only the decoders and feeders you actually want, and when you are comfortable letting a script install and configure services for you. Do not adopt it on a distribution outside the listed ones, or if you want a container you can throw away and rebuild. Verify first that you have the radio hardware and an antenna, which the README does not cover, that the release you install matches the tag you read, v2.8.12 from 2026-08-17 with the last push on 2026-08-17, and that the storage on the device is up to the task if you intend to enable the portal's advanced features.

Frequently asked questions

Official sources

1. Issues
2. jprochazka/adsb-receiver on GitHub
3. License: MIT
4. README
5. Releases