Open DroneLog: a local DuckDB dashboard for DJI and Litchi flight logs

What Open DroneLog solves for DJI and Litchi pilots

DJI stores flight logs on the controller or phone, and the vendor tooling is oriented toward support cases rather than personal record keeping. Third-party logbooks exist, and the README names several of them as trademarks it is not affiliated with, but the usual model is a hosted account. Open DroneLog takes the opposite position: the README describes it as local-first, with all data in a local DuckDB database and no cloud upload required, except a DJI key fetch during the first import.

The audience is narrow and identifiable. It is someone who flies DJI hardware, already has .txt logs on a controller or Android phone, and wants battery cycle counts, altitude and speed traces, and a map replay without paying a subscription. The README also lists Litchi CSV and Airdata CSV exports as import formats, which matters because Airdata is one of the services people use to get their logs off DJI hardware in the first place. Open DroneLog can consume that export instead of asking you to start over.

It is not a logbook for regulatory filing. The README mentions an HTML report with an A4 layout, selectable field groups and day-by-day grouping, printable to PDF through Ctrl+P, but nothing in the README claims the output satisfies any aviation authority's record-keeping requirement. Treat it as a personal analytics tool that happens to produce a printable report.

How the DuckDB and Tauri architecture fits together

The stack is stated plainly: Tauri v2 for the shell, DuckDB for storage and queries, React for the interface. The repository confirms it. The Dockerfile builds in three stages, a Rust backend compiled with the web feature, a Vite frontend, and a runtime image that serves both Nginx and an Axum web server from a single container. The src-tauri directory contains separate parser modules, including dronelogbook_parser.rs and litchi_parser.rs, which is where format-specific handling lives.

The performance claim rests on DuckDB rather than on custom aggregation code. The README says queries are DuckDB-powered with automatic downsampling for large datasets. That is the sensible design for this problem: a full telemetry trace at high sample rates is far too many points to draw directly, so the database does the reduction and the frontend receives a plottable series. It also explains why the app can offer synchronized drag-to-zoom across many charts at once.

Deduplication is handled at import time. The README states imports are rejected as duplicates based on drone serial, battery serial and start time. That triple is a reasonable key, and it is also the source of the most likely false positive: two flights from the same drone and battery that begin at the same recorded second would collide. The README does not document an override for that case.

The optional parser path is worth understanding before you commit. Custom formats are handled through external parser scripts configured in parsers.json, and in Docker mode the Python dependencies for those scripts come from requirements.txt, which ships empty apart from commented examples like pyulog and scipy. If your format is not DJI, Litchi or Airdata, you are writing that parser yourself.

Installing Open DroneLog and importing your first DJI log

The README points to the releases page for the latest build, and the project also offers a hosted web app so you can look at the interface before installing anything. For a self-hosted instance, the repository's docker-compose.yml is the shortest path. It pulls the published image, maps container port 80 to host port 8080, and mounts a named volume at /data/drone-logbook.

services:
  open-dronelog:
    image: ghcr.io/arpanghosh8453/open-dronelog:latest
    container_name: open-dronelog
    ports:
      - "8080:80"
    volumes:
      - drone-data:/data/drone-logbook
    environment:
      - DATA_DIR=/data/drone-logbook
      - KEEP_UPLOADED_FILES=true

After `docker compose up -d`, the web interface is reachable on port 8080 of the host. The DATA_DIR variable points the application at the mounted volume, so the database survives container replacement. KEEP_UPLOADED_FILES=true retains files you upload through the interface, which the compose comments note can be unified with a host sync folder when both mounts point at the same location.

Automatic import from a folder is a two-step change: mount the log directory read-only and set the sync path and schedule.

    volumes:
      - /path/to/your/drone/logs/on/host/device:/sync-logs:ro
    environment:
      - SYNC_LOGS_PATH=/sync-logs
      - SYNC_INTERVAL=0 0 */8 * * *

The SYNC_INTERVAL value is a cron expression, and the commented default in the compose file is every eight hours. Once the mount and variable are in place, logs dropped into that host folder are picked up on the schedule without going through the upload form.

For a desktop install on Windows or macOS, the README directs users to the releases page rather than a package manager. macOS users who hit a damaged-file error have a dedicated section in the README covering the fix. Linux users are pointed at building from source, and the package.json scripts show the toolchain: `npm run tauri` for the desktop shell and `npm run dev:web` for the browser build with VITE_BACKEND=web.

Where Open DroneLog stops being the right tool

The sharpest limitation is format coverage. Three input families are documented, DJI .txt, Litchi CSV and Airdata CSV, plus third-party apps named as supported through those paths. Anything else depends on the plugin system, and the plugin system is a developer task, not a configuration toggle. requirements.txt exists precisely so you can add parser libraries and rebuild the image, and the file's own comment tells you to rebuild with `docker compose -f docker-compose-build.yml build --no-cache open-dronelog`. If you cannot write that parser, the format is not supported.

The second constraint is the security posture of web mode. The README carries a section headed Security Warning (Web/Docker), and the compose file exposes a master password variable, PROFILE_CREATION_PASS, plus an optional DEFAULT_PROFILE_PASSWORD for the default profile on first startup. Those controls exist because the web build is a multi-user surface. Running it on a public interface without them is a choice the documentation warns against.

Third, the DJI API key. The README has a dedicated section on obtaining your own key at developer.dji.com, and the compose file shows DJI_API_KEY commented out. The README's local-first claim is qualified by the note that a DJI key fetch happens during the first import. If a fully air-gapped workflow is a requirement, that first-import call is the point where it breaks.

Finally, the maintenance picture. The last push to the default branch was on 2026-09-07, and the most recent release listed is 3.3.0 from 2026-05-01. The repository is not archived. That is a project with recent commit activity and a release cadence measured in weeks to months, not a dormant one, but the gap between the last release and the last push is worth noting if you depend on tagged versions.

Open DroneLog compared with hosted logbook services

The obvious alternative is a hosted logbook such as the services named in the README's trademark notice. The difference is not the feature list, it is where the data lives and who pays for it over time. A hosted service stores your telemetry on its infrastructure and typically charges a recurring fee; Open DroneLog stores everything in a DuckDB file on your machine or your server, and the README states there is no subscription required.

That trade cuts both ways. You gain control and lose convenience. A hosted service usually handles log retrieval from the aircraft or controller for you, offers mobile apps, and provides support when an import fails. Open DroneLog expects you to get the files yourself. The README's own table of contents reflects this: it has a section on accessing flight log files, with a sync bridge for Windows and macOS, manual collection, and Airdata exports as separate paths. You are responsible for the first mile.

A second alternative is doing the analysis yourself. DJI logs are parseable, and DuckDB is available as a standalone tool, so a determined engineer could build a personal pipeline. What Open DroneLog adds on top of that is the interface: map replay with speed control from 0.5x to 16x, RC joystick visualization, per-battery health bars with cycle tracking, and an export set covering CSV, JSON, GPX, KML and a Summary CSV. Reproducing those is weeks of work, which is the real argument for adopting the project rather than rolling your own.

One thing the project does not offer is a managed cloud. The README points to a hosted web app for evaluation and to a Docker image for self-hosting, and the Codeberg mirror provides an alternative image registry. There is no vendor-operated backend that stores your flights for you, and no indication one is planned.

Licence terms and the cost of keeping Open DroneLog current

The licence is AGPL-3.0-only, as declared in package.json and confirmed by the LICENSE file at the repository root. The practical consequence for a self-hosted instance is that running it on your own hardware for your own flights does not trigger the network copyleft clause, because you are not offering the modified software to other users. The moment you host it for a team, as the README's team hosting section describes, you are operating a network service, and the AGPL's source-availability obligation becomes relevant. This is a description of the licence text, not legal advice; if you plan to modify and host it for others, get a lawyer's read.

Upgrade cost is low if you use the published image. Changing the tag in docker-compose.yml and recreating the container is the whole procedure, and the named volume at /data/drone-logbook preserves the database across that operation. The risk sits in schema changes between versions. The README does not document a migration path or a rollback procedure for the database, so backing up the volume before a major version bump is the reasonable precaution.

Upgrade cost is higher if you build from source or maintain plugins. The Dockerfile compiles the Rust backend with the web feature, and the build copies parser sources explicitly. Adding a Python parser library means editing requirements.txt and rebuilding with `--no-cache`. On the desktop side, package.json exposes the full Tauri and Android build matrix, including separate scripts for arm64, armv7 and x86_64 APKs and AABs. Keeping a fork in sync with upstream means tracking all of that.

Editorial conclusion

Adopt Open DroneLog if you already own DJI or Litchi logs and want the analysis to stay on hardware you control. Skip it if your fleet logs a format nobody has written a parser for, or if you need vendor support with an SLA. Before committing, verify three things: that the parser handles your specific log format, that the AGPL-3.0-only licence is acceptable for how you intend to deploy the web build, and that the Docker deployment is not exposed to an untrusted network, since the README carries an explicit security warning for web mode.

Frequently asked questions

Official sources

1. arpanghosh8453/open-dronelog on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases