FlightData Feeder

The client of the FlightData platform: the agent that runs on your own machine, reads ADS-B (and Mode S, MLAT, ACARS, VDL2, HFDL and drone Remote ID) from local receivers, filters what you choose to share, and forwards it to a FlightData server over an authenticated, encrypted binary connection. It serves its own web dashboard on localhost so you can see exactly what it is doing.

This repository holds the complete source of that client, published so that anyone running it can read what it sends, when, and to whom. The server it talks to is not part of this repository.

flightdata_feeder/   the client: agent, dashboard, plugins, tests
proto/               the wire protocol both sides speak (public half)

Build

Requirements: Go 1.25 or newer, git, and either bash or PowerShell (one script assembles the dashboard's HTML and JavaScript from its partials). Nothing else — no npm, no build step for the frontend, no C toolchain. Binaries are fully static (CGO_ENABLED=0).

cd flightdata_feeder

make dev                  # build for this machine, into bin/
make build-linux-amd64    # or a specific target: -linux-arm64, -linux-arm7, -windows
make build                # all of them

make is a convenience. The plain Go build works too, as long as the dashboard has been assembled at least once:

cd flightdata_feeder
bash web/dashboard/_assemble.sh        # PowerShell: web/dashboard/_assemble.ps1
CGO_ENABLED=0 go build ./cmd/feeder

Run the tests the same way the project does:

cd flightdata_feeder && go test ./...
cd proto && go test ./...

Run

./bin/flightdata_feeder-linux-amd64 --config-dir configs --data-dir data

The dashboard is then at http://localhost:2280. Two flags answer a question without starting the feeder: --version, and --hardware-id (the SHA-256 of the CPU serial and MAC address that identifies this installation to a server).

Configure

Everything lives in one file, configs/feeder.json, and the feeder reloads it while running — editing it does not require a restart. The dashboard writes the same file, so you can use either.

The three things to set before the first run:

Setting	What it is
network.server_host / server_port	the FlightData server to feed. The default is localhost: a feeder that is not configured feeds nobody.
network.sharing_key	your station's key on that server. Leave it empty and the server may issue one, if its operator allows that.
the input sources	where frames come from — a dump1090/readsb SBS-1 or Beast stream, an SDR the feeder manages itself, a serial receiver, or a recorded .fdr file.

Transport security is on by default and stays on: the feeder will not silently fall back to plaintext, and it refuses a server certificate that changes after the first successful connection until you clear the pin yourself. Both refusals are visible on the dashboard rather than buried in a log.

One consequence of building it yourself is worth knowing in advance: a feeder only accepts an over-the-air update whose package carries an ed25519 signature from a release key it was compiled to trust, and a build from this source is compiled to trust none. It will refuse every OTA package offered to it — which is the correct answer for a binary nobody signed. Update it by building again.

flightdata_feeder/README.md is the long version — every configuration block, every dashboard page, the plugin interface, and how the external decoders are managed.

Licence

Apache-2.0 — see LICENSE and NOTICE. Everything redistributed with this source (the dashboard's JavaScript and CSS, the offline basemap, the flag images, the fonts) is inventoried in THIRD_PARTY_NOTICES.md, with its licence and where it came from.

This repository is published as a snapshot: each commit is a release of the client, not the development history of the platform it belongs to.