I've been using CodeProject AI with Mike Lud's license plate model on Blue Iris for a couple years now, but in this setup, the ALPR doesn't really do a whole lot. Really, you have more of a license plate camera with some OCR as a bonus, and no nice way to take advantage the data other than parsing Blue Iris logs or paying $600+/year for PlateMinder or Rekor ALPR.
This project serves as a complement to a CodeProject Blue Iris setup, giving you a full-featured database to store and actually use your ALPR data, completely for free. Complete with the following it has a very solid initial feature set and is a huge upgrade over the standard setup.
- Searchable database & fuzzy search
- Export filtered plate records as CSV or JSON
- Live recognition feed
- Traffic Analytics
- Categorization and filtering
- Store information on known vehicles
- Unified MQTT, Pushover, email, and signed webhook notifications
- Storage thresholds, category breakdowns, maintenance status, and guarded cleanup previews
- Automation rules
- Customizable tagging
- Configurable retention
- Flexible API
- HomeAssistant integration
- Permissioned users
This community fork builds containers directly from a reviewed Git commit. It
does not download or run installer/update scripts from the former upstream
project, and its Compose files default to the local image
alpr-dashboard:local with pulling disabled.
In order to send data and use the application, you will need ALREADY WORKING ALPR within Blue Iris. If you are not getting plate numbers in your alert memos, please configure and ensure your ALPR is working before beginning the setup.
You will also need the following installed on your system.
- Docker
- Docker Compose
- Docker engine enabled and running
Tip
If unfamiliar with Docker, an easy way to check all three of these boxes at once is to install Docker Desktop, which has a GUI and bunch of nice tools.
Clone the fork, check out the approved commit, and build the local image:
git clone https://github.com/prsmith777/ALPR-Database-Community.git
cd ALPR-Database-Community
git checkout <approved-commit>
docker build --tag alpr-dashboard:local .Copy .env.example to .env, fill in both passwords, and keep that file
private. Then start the stack with docker compose up -d. Compose refuses to
start while either required password is blank, never pulls the former
upstream application image, and keeps PostgreSQL bound to 127.0.0.1 by
default.
For this owner's staging and production process, including PostgreSQL 17
upgrade and rollback requirements, follow
docs/personal-deployment.md.
To start sending data, log in to the application and navigate to settings -> security in the bottom left hand corner. At the bottom of the page you should see an API key. Click the eye to reveal the key and copy it down for use in Blue Iris.
ALPR recognitions are sent to the /api/plate-reads endpoint. Integration
routes under /api/plate-reads and /api/plates require the API key in either
of these headers:
x-api-key: YOUR_API_KEY
Authorization: Bearer YOUR_API_KEYDo not place an API key in the URL. Query-string credentials such as
?api_key=... are rejected. Other application API routes use the signed-in
browser session instead of the integration API key.
We can make use of the built-in macros to dynamically get the alert data and send it as our payload. It should look like this:
{ "ai_dump":&JSON, "Image":"&ALERT_JPEG", "camera":"&CAM", "ALERT_PATH":"&ALERT_PATH", "ALERT_CLIP":"&ALERT_CLIP", "timestamp":"&ALERT_TIME", "trigger_type":"&TYPE" }
Blue Iris may label this JSON alert body as text/plain. The integration
accepts that default for compatibility and validates the body itself as JSON;
no additional Content-Type header is required.
For primary direction without a cloned camera, configure the motion sensor
with both explicit ordered crossings (for example A>B,B>A) rather than the
bidirectional shorthand A-B. Blue Iris then sends MOTION_A>B or
MOTION_B>A in &TYPE. Map those two values to the camera's semantic
direction labels under Settings > Vehicle Setup > Cameras and enable the
mapping only after live validation in both directions. New mapped reads use
Blue Iris as the displayed and notification direction source; missing or
unmapped crossings fall back to Vehicle ReID. Monochrome nighttime captures
are not classified and display Unavailable nighttime. Existing historical
reads are not rewritten.
Each alert attempt is assigned an x-request-id and emits safe arrival status
metadata. Authenticated alerts also leave a bounded, metadata-only ingress
receipt; rejected authentication attempts leave a receipt without reading the
request body. This makes rejected requests and a missing or blank &TYPE
visible to operators without retaining the plate value, image, AI dump,
request body, or Blue Iris path in operational logs. File-log rotation,
request-size limits, receipt preview policy, hot-audit policy, and PostgreSQL
container-log bounds can be tuned with the ALPR_* logging settings documented
in .env.example. Administrators can review growth, preserve a bounded incident
package, and run an exact preview-confirmed retention batch from System Logs >
Retention & incidents. Retention execution is never scheduled automatically.
Set your API key with the x-api-key header as seen below.
Browser sessions use HttpOnly, SameSite=Lax cookies. Cookies are non-Secure
by default so direct-LAN HTTP Docker deployments continue to work. Set
SESSION_COOKIE_SECURE=true when the application is served over HTTPS. Cookie
security is never inferred from X-Forwarded-Proto or other request headers.
See docs/security-baseline.md for the complete authentication and failure-handling policy.
Maintainers of this fork should follow the streamlined staging-to-production process in docs/personal-deployment.md.
This is meant to be a helpful project and is still a work-in-progress. There's a good amount of spaghetti vibe coding in here and random things left over from the initial release. Not to be relied on for anything critical.