Skip to content

tar1090

The ADS-B aircraft map for readsb, served on this machine only, with no outside requests

What it does

Installs tar1090, the web page most people use to watch ADS-B aircraft on a map from their own receiver: a table of what is in the air, a track for each aircraft, altitude and speed, range rings, filters. It reads the JSON file readsb keeps up to date (Debian's readsb service writes it to /run/readsb). Its own installer is not used. hammunition reference serve serves the page at http://127.0.0.1:8480/aircraft/, on this machine only, and hands it readsb's file through its own data/ address, read-only. The page is changed in three ways so that it cannot call anything off this machine: tar1090's settings that fetch aircraft photographs, flight routes and weather or airspace overlays are switched off; its online map layers are replaced by your offline map (the one osm-pmtiles builds) or, without one, a blank background with the reason written on the page; and the page's responses carry a Content-Security-Policy that names no host, so the browser itself refuses a request to anywhere else.

Why you would want it

readsb decodes aircraft and its own built-in map is basic; tar1090 is the maintained, much fuller page for it, and the aircraft view the rest of the ADS-B community uses. Served here it needs no web server to set up, does not listen on port 80 on every address as tar1090's installer arranges, and works with the network off, which is when a field station most wants to know what is overhead. It replaces Virtual Radar Server (superseded by readsb with tar1090, PARITY-POLICY).

Before it will work

readsb (installs with it) decoding something: an RTL-SDR at 1090 MHz, or dump978-fa's UAT output fed to readsb (--net-connector 127.0.0.1,30978,uat_in, measured). readsb has to be writing its JSON: the Debian service does, to /run/readsb; if yours writes elsewhere, hammunition reference serve --readsb-json DIR names the directory. For a map behind the aircraft: vector-map-kit and osm-pmtiles with map regions set (the navigation profile); without them the page still works on a plain background.

How it installs

  • data (GPL-2.0-or-later (tar1090's LICENSE: "licensed under the GPL, v2 or later"); its flag icons are MIT (html/flags/LICENSE), https://github.com/wiedehopf/tar1090/blob/e784ee5ae82948f41efe3ef5c235ade0943ab8ff/LICENSE): https://github.com/wiedehopf/tar1090/archive/e784ee5ae82948f41efe3ef5c235ade0943ab8ff.tar.gz (2,812,358 bytes)
  • The page's files only, under /usr/local/share/hammunition/data/tar1090/. Nothing is run and no web server is configured. It installs on every target that offers readsb; where readsb is absent (Ubuntu 24.04 and Linux Mint 22.3: no candidate in the 2026-10-01 sweep, recorded in docs/reference/catalog-gaps-2026-09.md) this unit is deferred by name.

Known problems

No aircraft database: type, operator and registration are blank unless readsb supplies them, and the pictures, routes and overlays (TFRs, weather, airspace) are off, because each is a request to someone else's server. Tracks use only what the page has seen since you opened it: tar1090's history service, which keeps what happened before, is not run. The page's detail panel still has links to FlightAware and planespotters; clicking one is your navigation, not the page calling out. The basemap is drawn by the page from your regions' vector tiles with a small style of its own, plainer than the map at /map/, and covers only the regions you built: an aircraft outside them is drawn on the plain background. The page always reads readsb's plain aircraft.json: readsb 3.14.1630 also writes aircraft.binCraft.zst (measured, run with no SDR, 2026-10-02), and its receiver.json can say to read that, or globe files or history chunks, so the receiver.json the page is given has only the version, refresh interval and position. Measured in headless Chromium with a synthetic aircraft.json and a synthetic tile (tests/test_aircraft_render.py); not yet seen with a live receiver (the installed readsb writes no receiver.json without an SDR, so the real file's contents were not read), and not in Firefox. The data unit is an archive of GitHub's making: see the note above on its hash.

Keeping it current

  • probe: none
  • strategy: reinstall
  • Upstream has no tags and commits several times a month. The pin is the commit measured on 2026-09-29; to move it, download the new commit's archive twice, compare the sha256, check that html/index.html still loads layers.js in the one place hammunition reference serve rewrites (a test asserts it), and bump url, sha256, size, members and version together. hammunition update reports the pin; it does not ask GitHub.

Where to get help with the software itself

tar1090's GitHub issues (https://github.com/wiedehopf/tar1090/issues) for the page itself, though they will not support what this server changed (the layers, the settings, no database). Problems with decoding are readsb's (https://github.com/wiedehopf/readsb/issues).

Source: catalog/packages/tar1090.yaml