Open DroneLog: A Local DuckDB Dashboard for DJI and Litchi Flight Logs
Drone Log analyzer: A high-performance universal dashboard application for organizing and analyzing DJI/Litchi flight logs privately in one place. Supports plugin for custom flight log formats. Built with Tauri v2, DuckDB, and React.
At a glance
- What is it?
- Open DroneLog turns DJI .txt and Litchi CSV flight logs into a queryable local DuckDB database with a Tauri or Docker front end. The trade-off is format coverage: it reads what its parsers understand, and AGPL-3.0 shapes what you can do with it.
- Who is it for?
- Adopt Open DroneLog if you fly DJI or Litchi hardware, want flight history to stay on your own machine or server, and are willing to run a Docker container or a Tauri build to get it. Skip it if your logs come from a vendor whose format has no parser or Airdata export path, or if AGPL-3.0 is incompatible with how you ship software.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Flight Logs Are Readable but Not Queryable
DJI aircraft write plain-text flight logs. Litchi writes CSV. Both are human-readable and both are awkward to work with at scale. A single flight log contains thousands of rows of timestamped telemetry, and answering a simple question such as how a battery's full-charge capacity has drifted across forty flights means opening forty files and comparing columns by hand. Spreadsheet imports tend to collapse under the row counts. Cloud services solve the aggregation problem but require uploading the logs, which for commercial operators can conflict with client contracts or data handling policies.
Open DroneLog takes the position that the aggregation should happen locally. The README describes it as "a high-performance application for analyzing drone flight logs (DJI and Litchi CSV formats)" that runs as a Tauri v2 desktop app or a Docker-deployable web app. The intended user is a pilot or a small flight operation that already has the log files and wants statistics, battery health tracking and maintenance records without a subscription. The project also publishes a hosted web app and an Android build on Google Play, so the same codebase reaches users who do not want to install anything.
That positioning matters because the alternative tools in this space are mostly cloud-first. Open DroneLog's differentiating claim is not that it draws nicer charts. It is that the database lives on your disk.
How It Works: Logs In, DuckDB Out, React on Top
The architecture visible in the repository is a three-layer stack. The front end is React. The desktop shell is Tauri v2, which wraps a web view in a native binary and is why the project ships Windows, macOS and Android builds from one TypeScript codebase. The storage and query layer is DuckDB, an embedded columnar database. The README lists the tech stack as Tauri v2, DuckDB and React, and the repository's primary language is TypeScript.
DuckDB is the load-bearing choice here. Flight telemetry is a long, narrow table: one row per sample, with columns for height, speed, battery, cell voltages, attitude, RC signal, GPS, distance-to-home and velocity. That shape is exactly what a columnar engine handles well, and the README states the app uses "DuckDB-powered queries with automatic downsampling for large datasets." Downsampling is the mechanism that keeps charts responsive when a flight has tens of thousands of samples: the query returns a reduced series rather than every point.
Import is where the format work happens. DJI logs arrive as .txt, Litchi as CSV, and Airdata CSV exports are also accepted, with what the README calls "automatic unit detection." Deduplication is keyed on drone serial, battery serial and start time, which means re-importing the same folder should not double-count flights. Third-party formats from Dronelink and DroneDeploy are listed as supported, and the plugin route is a file named parsers.json that points at external parsers. That is the extension point for anyone whose logs do not match a built-in parser.
One detail worth flagging: the README notes that data stays local "except DJI key fetch during first import." So the first import is not fully offline. It contacts DJI to retrieve an API key, and there is a separate section in the README on obtaining your own DJI Developer API key.
Getting It Running: Desktop Download, Docker, or Build From Source
The lowest-friction path is the prebuilt release. The README links a Download Latest Release badge pointing at the GitHub releases page, with 3.3.0 as the most recent stable release listed. macOS users get a dedicated troubleshooting section titled "Damaged File" Error Fix, which is a common Gatekeeper symptom for unsigned or unnotarized builds. That section exists for a reason, so budget a few minutes for it if you are on macOS.
For a self-hosted web deployment, the README documents a Docker path. The image is published on GitHub and mirrored on Codeberg at codeberg.org/arpanghosh8453/open-dronelog, described as "an alternative docker image." The repository also lists a docker topic and a self-hosted topic, and there is a dedicated README section on hosting Open DroneLog for teams.
Linux users are expected to build from source rather than download a binary; the README has a section titled "Building from source (Linux users)." Because the stack is Tauri v2 plus React, that build will pull in the Rust toolchain alongside Node, and the exact commands are in the README rather than reproduced here.
Two configuration surfaces appear in the README. The first is parsers.json, which registers external parser plugins for custom log formats. The second is the configuration section, which covers application settings. The README also documents profiles and password protection, plus a separate security warning for web and Docker deployments. That warning is the one to read before exposing the container beyond localhost. A password on a self-hosted analytics app is not the same as a hardened deployment, and the project says as much by carving out a dedicated warning section.
What It Actually Tracks: Batteries, Maintenance, and Reports
The feature list is long, but three items are the ones that change how a pilot works.
Battery health is tracked per battery, with health bars, cycle count, serial renaming, and a capacity history chart that plots full-charge capacity over time with a multi-select battery dropdown. This is the feature that answers the drift question from the opening section. Because the database is local and persistent, the history accumulates across every import rather than resetting per session.
Maintenance tracking uses configurable thresholds rendered as color-coded progress bars, with date-based maintenance recording. The thresholds are yours to set, which is a double-edged design: the app will not know your airframe's service interval, so an unconfigured install shows progress bars against whatever defaults ship.
Exports cover CSV, JSON, GPX, KML and a Summary CSV, plus a FlyCard generator that produces 1080x1080 images for social media. There is also an HTML report generator that the README describes as a "configurable, print-ready flight regulation report (A4 layout)" with selectable field groups, weather data and day-by-day grouping, printable to PDF via Ctrl+P. Pilot name and field preferences persist across sessions, which suggests they are stored in the local database alongside the flight data.
Around those, the app offers interactive flight maps with 3D terrain, map-type selection across Satellite, Topographic and OpenStreetMap, replay with 0.5x to 16x speed control, live telemetry overlay and RC joystick visualization. The overview dashboard includes an activity heatmap, pie charts by drone, battery and duration, a time-of-day radial chart and a cluster map with an optional heatmap layer. Filters include date range with typed YYYY-MM-DD entry, drone, battery, controller and color filters, duration, altitude and distance sliders, tag filter, map area filter and filter inversion. Auto-tagging covers Night Flight, High Speed and Low Battery, with offline reverse geocoding for location tags. There is also a manual flight entry path for flights with no log file, and the interface is localized into 11 languages.
Where It Stops: Format Coverage and the First-Import Network Call
The honest limitation is format coverage. The README names DJI .txt, Litchi CSV and Airdata CSV exports as the primary inputs, with Dronelink and DroneDeploy listed as supported third-party apps. If your fleet logs in a format outside that set, the documented escape hatch is parsers.json and an external parser plugin. Writing that parser is your work, not the project's. There is no evidence in the supplied material of how many community parsers exist or how stable the plugin interface is across releases, so treat the plugin path as a real option that requires real effort.
The second constraint is the first-import network call for the DJI key. The README is explicit that local-first storage has this one exception. If your environment is air-gapped or your policy forbids outbound calls from an analytics tool, that is a friction point to plan around, and the README's DJI Developer API key section is the relevant reading.
The third is the web deployment posture. The project ships a Docker image and documents team hosting, and it also ships a security warning specifically for the web and Docker modes. A tool that stores your complete flight history, including GPS traces of every location you have flown, deserves more scrutiny when it listens on a network interface than when it runs as a desktop binary. The README's own warning section is the signal to take that seriously.
Finally, the release cadence is worth noting without reading anything into it. Three stable releases are listed between mid-April and early May 2026, with the last repository push in September 2026. Frequent point releases suggest active maintenance. They also mean you should read release notes before upgrading a self-hosted instance, because schema or parser changes between 3.2.x and 3.3.0 are not described in the material available here.
The Alternative: Cloud Logbooks and What They Trade Away
The obvious alternative is a cloud logbook such as DroneLogbook or Airdata, both of which the README names in its trademark disclaimer. The difference in approach is not cosmetic. A cloud service ingests your logs to its servers, correlates them across a fleet, and gives you a browser interface with no local install. Open DroneLog inverts that: the DuckDB file sits on your disk or your server, and the only outbound call in the documented flow is the DJI key fetch on first import.
That inversion has consequences in both directions. You get portability and no subscription, and the README states the project is "free, open source, no subscription required." You also get a tool that is only as good as its parsers, with no vendor support line. A cloud logbook with a commercial team behind it will typically absorb new aircraft formats faster than a single-maintainer project, because format support is a business requirement for them and a contribution request here.
If your requirement is fleet-wide compliance reporting with a support contract, the cloud route is the one that fits. If your requirement is that the GPS traces of your survey flights never leave hardware you control, Open DroneLog is the tool built for that constraint, and the Docker image plus the team hosting section is the deployment shape for a small operation that wants one shared instance on its own network.
Licence and Maintenance Cost Under AGPL-3.0
Open DroneLog is licensed AGPL-3.0. For an individual pilot running the desktop app or a self-hosted container, the practical effect is close to nil: you are using the software, not distributing it. The licence matters if you modify the code and make it available over a network. AGPL-3.0's network clause is the part that differs from GPL-3.0, and it is the reason some companies keep AGPL software off their internal infrastructure entirely. That is a policy question for your organization, not a legal conclusion, and the repository's LICENSE file is the authoritative text.
Maintenance cost is mostly your own time. The desktop path is a download and the README's macOS fix if you hit Gatekeeper. The Docker path is a container you need to keep updated, and because the storage layer is DuckDB, an upgrade that changes the schema is the scenario where you want a copy of the database file before pulling a new image. The parsers.json plugin route adds a second thing to maintain: if the plugin interface changes, your custom parser is the code that breaks, and the project has no obligation to preserve it across major versions.
There is no pricing tier to evaluate and no seat count to manage. The cost is the operational discipline of backing up a database file and reading release notes before you upgrade a shared instance.
Editorial conclusion
Adopt Open DroneLog if you fly DJI or Litchi hardware, want flight history to stay on your own machine or server, and are willing to run a Docker container or a Tauri build to get it. Skip it if your logs come from a vendor whose format has no parser or Airdata export path, or if AGPL-3.0 is incompatible with how you ship software. Before committing, verify three things: that your specific log format imports without errors, that the Docker deployment is bound to a network you control given the README's own security warning, and that the maintenance thresholds you configure match your airframe's actual service intervals.
Community notes