Ponphil/LitePan: aggregating cloud drives behind WebDAV, STRM and FUSE

The problem LitePan addresses: many cloud drives, one namespace

Anyone who keeps media across several cloud-drive accounts knows the shape of the problem. Each provider has its own web interface, its own authentication, and its own idea of how folders should be laid out. A media server such as Emby or Jellyfin expects one library path it can scan. LitePan sits in that gap: the README describes multi-account management behind a single interface, cross-drive transfer that tries a server-side copy first and falls back to an upload, and generation of .strm files that media servers can read directly. The audience is narrow and specific: self-hosters with more than one drive account and a media library to keep organised. It is not a general file-sync tool, and it is not aimed at teams.

How LitePan works: Go binary, SQLite state, WebDAV and FUSE surfaces

The repository layout tells you most of the architecture. cmd/ holds the entry point, drivers/ holds the per-provider implementations, internal/ and pkg/ hold the rest, and web/ is a separate frontend built with npm. The go.mod file lists the pieces that matter: go-chi for HTTP routing, gowebdav for the WebDAV side, go-fuse for local mounting, modernc.org/sqlite as a pure-Go SQLite driver (so the binary can be built with CGO_ENABLED=0), and the anacrolix torrent stack for the built-in magnet handling. The Dockerfile confirms the data flow: environment variables LITEPAN_DATA_DIR, LITEPAN_STRM_DIR and LITEPAN_LISTEN are baked into the image, with the service listening on :5211 and the torrent listener on 42069 for both TCP and UDP. Persistent state lives under /app/data, generated .strm files under /app/strm, and FUSE mount points under /app/mounts. The container runs with pid: host and privileged: true, which is a direct consequence of mounting FUSE inside it.

Installing LitePan with Docker Compose and opening the panel

The README gives a Docker Compose deployment as the primary path, and the repository ships the same file as docker-compose.yml. Note the image tag: the README carries an explicit warning not to deploy ponphil/litepan:latest for this Go version, because latest still points at the Python image. Use the beta tag instead. The compose file maps the web port, the torrent ports, and three volumes, and passes through /dev/fuse.

services:
  litepan:
    image: ponphil/litepan:beta
    container_name: litepan
    restart: unless-stopped
    ports:
      - "5211:5211"
      - "42069:42069/tcp"
      - "42069:42069/udp"
    environment:
      - TZ=Asia/Shanghai
    volumes:
      - ./data:/app/data
      - ./strm:/app/strm
      - ./mounts:/app/mounts:shared
    devices:
      - /dev/fuse:/dev/fuse
    pid: "host"
    privileged: true

Start it with docker compose up -d, then open http://your-ip:5211 in a browser. According to the README, the default administrator password is admin. FUSE mounting requires /dev/fuse on the host, which is why the device entry is present in the compose file at all. If you would rather build from source, the Makefile offers make build with the fuse tag and make docker-build; the Dockerfile itself pins Go 1.26.6 and builds the web frontend with npm before compiling the binary.

Where LitePan is the wrong tool

The README opens with a caution block stating that this repository is the Go version of LitePan under development and that the first release may have many problems, so it should be tested carefully. That is the project's own assessment, not an outside one, and it should shape how you deploy it. The licence compounds the constraint: PolyForm Noncommercial 1.0.0 permits personal study and noncommercial use and forbids commercial use, so this is not something to build a paid service on. Support is also unusual. The README says public pull requests are not accepted and directs feedback to a Bilibili page, with an invitation to send a private message if you want to help maintain it. That means no public issue tracker where you can search for a failure someone else already hit. If you need a supported product with a commercial licence, LitePan is not it.

LitePan compared with OpenList

OpenList appears in the related searches around this project, and the comparison is fair because both aggregate cloud storage behind a common interface. The difference is in the extras. The LitePan README lists capabilities that go past mounting: STRM generation for Emby and Jellyfin, nfo and poster scraping with a poster wall, TMDB-based directory organisation with a preview step before archiving, and a chained automation that runs organisation, STRM generation, scraping and library refresh in sequence. It also lists 302 direct links, cache retention, naming alignment, offline download and a built-in magnet handler backed by the anacrolix torrent libraries in go.mod. OpenList is the more established name in this space, and if you only need WebDAV aggregation, that maturity matters. LitePan's pitch is the media workflow wrapped around the mount, and that is also where its beta risk concentrates.

Maintenance cost, licence and upgrade path

The last push to this repository was on 2026-09-12, so the code is being touched. The README does not document a rollback procedure, and no releases were retrieved, so there is nothing to pin beyond the image tag the README names, v0.5.5-Beta. Upgrading means changing that tag and restarting the container; the SQLite database under /app/data is the state you would have to preserve across the change, and the README is silent on schema migrations between beta tags. On licensing, PolyForm Noncommercial 1.0.0 restricts use to personal study and noncommercial purposes, and the README also points to THIRD_PARTY_NOTICES.md for dependency licences and reminds users to follow each cloud-drive provider's terms and local law. That last point is not boilerplate: the 302 direct-link and cross-drive transfer features act on accounts governed by someone else's terms of service. Read the licence text yourself rather than treating this paragraph as legal advice.

Editorial conclusion

LitePan fits a homelab user who already runs Emby or Jellyfin, wants several cloud-drive accounts behind one WebDAV or FUSE endpoint, and accepts beta software under the PolyForm Noncommercial licence. It is the wrong choice if you need commercial use rights, a stable release, or public issue and pull-request support, since the README says public PRs are not accepted. Verify first: that your host has /dev/fuse and that the container is started with the beta tag rather than latest, which still points at the archived Python version.

Frequently asked questions

Official sources

1. Issues
2. Ponphil/LitePan on GitHub
3. Project website
4. README