DeFlock puts licence plate readers on a map, one sighting at a time

The problem is scale, not individual cameras

The stated origin is personal observation. The author created the project after noticing the mass deployment of ALPRs in cities, towns and even rural areas in recent years, and describes that deployment as a massive threat to privacy. The aim is to shed light on the issue as the devices continue to be installed in thousands of cities across the United States and possibly beyond. That framing sets the project's shape. It is not a scanner, not a detector and not a database of licence plate reads, and nothing in it tries to read a plate. It is a registry of physical devices and where they point, built by people who walk or drive past them. The audience is a privacy-minded public, journalists looking for a pattern, and local organisers who want evidence before a council vote, and the design choice that follows from that audience is that the data has to be open and verifiable rather than curated.

The map moved to its own repository

The map is the visible part of the project, and it now lives somewhere else. The README says the map has become a separate repository, deflockhopper_maps, and the live site is at deflock.org. That is a meaningful architectural decision rather than housekeeping. A map application and a data set have very different change rates and different audiences, and separating them means the mapping code can be rewritten or replaced without touching the community contributions, and the data can be served to other consumers. The map itself uses OpenStreetMap data to populate a view of crowdsourced ALPR locations, along with the type of each device and the direction it faces. The direction is the detail that makes the map usable rather than decorative. A reader facing a parking lot is a different privacy proposition from one facing a motorway, and a registry that records the orientation is a registry that tells you something.

Two ways to report, and one needs no installation

Reporting is where a crowdsourced project lives or dies, and DeFlock offers two routes. One is the DeFlock App, with instructions on the project site, and the other is OpenStreetMap's iD web editor, which needs nothing installed and works in a browser. Both write into the same standardised tagging system, so a camera reported through either route lands in the same dataset with the same attributes. The choice of a standardised tagging scheme over a bespoke form is the second important design decision, and it is the one that makes the data durable. A proprietary submission format would be a database of a project, whereas tags in OpenStreetMap are a format that other projects can read, that contributors can correct, and that survive this project. The documentation also includes a constantly growing repository of ALPR makes, models and tagging instructions for OpenStreetMap, along with images for identifying them, which is the part that turns a database of points into something a volunteer can actually fill in.

A stack with several things marked deprecated

The backend is TypeScript with a Fastify API server, and the data lives in Cloudflare R2 for ALPR points and vector tiles, with OpenTelemetry for instrumentation. The cloud side is AWS Lambda for region segmenting, which is marked deprecated, and for counts, AWS S3, which is being phased out for R2, AWS ECR for images, Cloudflare as DNS and proxy, a Directus CDN and a Zammad helpdesk. The frontend is Vue 3 with Vuetify and MapLibre GL, with Vue Leaflet marked deprecated and being phased out for MapLibre GL. The services are the OpenStreetMap Overpass API and Nominatim for geocoding, and the Basic Map Tiles are marked deprecated. Several things in this list are on their way out, and the README is upfront about it. That is worth weighing, because a project that documents its own deprecations is telling you which parts of its stack are load-bearing and which are historical, and the migration paths are named, R2 for S3 and MapLibre for Leaflet.

Running the front end and the API locally

Development needs bun and nothing else, and the two halves of the application are run separately. The front end lives in the webapp directory and the API in api, with the same three steps for each:

cd webapp
bun i
bun dev

and for the API, a cd api in place of cd webapp and the same bun i and bun dev. The repository also has a cms/ directory, a scripts/ directory, a serverless/ directory holding the Lambda functions, a terraform/ directory for infrastructure, and the .github/ directory for the workflows. The split between the API and the Lambda functions tells you the shape of the system. The API serves the application and the live data, while the serverless functions handle the periodic work, region segmenting and counts, which are the jobs that would otherwise be cron jobs inside the API. A terraform directory also means the infrastructure is described as code, which is the level of maturity you would expect from a project that has to survive its own maintainers changing.

What a crowdsourced registry can and cannot tell you

The limitation is inherent in the method. A crowdsourced map of plate readers is incomplete in a way that a structured dataset is not, because a camera that nobody reported is invisible and indistinguishable from a camera that does not exist, and the map's density correlates with where people are paying attention rather than with where cameras are. That is a genuine problem for any conclusion you might want to draw from it, and it is the reason the project anchors the data in OpenStreetMap rather than a private store, since a public dataset can be corrected and extended by anyone who finds an error. A second limit is the data's own timeliness. The release history shows 1.0.2 adding a wardriving section in January 2025, 1.0.3 adding Motorola breach info, and 1.0.5 adding every door in April 2025, so the dataset grew by feature area rather than by a model, and the last push was on 2026-10-09. The licence is MIT with a LICENSE file in the root, and the project welcomes contributions through the ordinary fork, change and pull request route.

Editorial conclusion

DeFlock is worth using if you care about surveillance infrastructure and want an open, checkable record of where plate readers are being installed, because anchoring the data in OpenStreetMap means a sighting is auditable, revisable and reusable by anyone, rather than locked in one organisation's database. It is the wrong tool for anything requiring completeness or legal weight, since the data is crowdsourced, incomplete by nature, and its own release history shows pieces of the stack being retired. Before you rely on it, check whether the camera you care about has actually been reported, look at how the map is rendered, and read the tagging documentation rather than assuming a pin means what you think it means. If you are adding data, the iD editor route needs no installation at all.

Frequently asked questions

Official sources

1. FoggedLens/deflock on GitHub
2. License: MIT
3. Project website
4. README
5. Releases