# Lynavo Drive: photo sync over the LAN, with the boundary drawn on purpose > Lynavo Drive is a self-hosted alternative to the big cloud photo services that syncs a phone's photo library to a desktop over the local network, with no account and no upload to a third party. The open repository deliberately excludes remote access, accounts, signing and updates, and the readme says so in two separate callouts. **Lynavo/lynavo-drive** — LynavoDrive (Lynavo Drive) by Lynavo - an open-source alternative to iCloud and Google Photos for private photo backup and computer file access. - Repository: https://github.com/Lynavo/lynavo-drive - Website: https://drive.lynavo.io/ - Stars: 530 · Forks: 81 - Language: TypeScript - License: AGPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/lynavo-lynavo-drive ## The repository ships a core, and the boundary is stated up front Lynavo Drive is described as an open-source alternative to iCloud and Google Photos for private photo backup and computer file access, and the headline in the readme narrows it further: a high-performance, local-LAN incremental media sync tool from mobile, iOS and Android, to desktop, macOS and Windows. The local LAN restriction is the defining constraint, and the readme puts it in a section of its own with an important callout. Foreground automatic sync works without sign-in or an account service. The upload set comes only from the mobile photo-library scan and the local pending queue, with no manual file-selection fallback. The queue is read-only and each phone uploads one file at a time. And missing non-OSS modules or account-service state do not block foreground LAN pairing and sync. That last point is the design in one sentence. The core has to work without the parts of the product that are not open, so a fork or a build without the account service still does the thing people actually want, which is getting photos off a phone onto a computer without sending them to somebody else's server. The project status paragraph says the same thing in a different register. Lynavo Drive is implemented and open for community source builds and contributions, and this repository provides one public local source-build and package-verification path. It does not publish official signed installers, mobile store builds, auto-updates, or hosted services. There is a table that breaks the surfaces down. The desktop runtime covers macOS and Windows. The mobile runtime covers iOS and Android. Linux is local source-build and package verification only. The network surface is foreground sync over the same LAN. And distribution is community source builds and locally produced packages and binaries. The project is AGPL-3.0, written primarily in TypeScript, and the last push was on 2026-10-01 with releases v1.0.1 in July 2026 and v1.0.2 later the same month. ## Two editions, and the rule about what a GitHub release actually is The editions table draws a line that is unusual for a project to draw about itself. The Open Source Edition is the local-LAN core in this repository, source builds, and unsigned verification files, downloaded from the GitHub Releases. The Official or Commercial Edition is signed desktop installers, official mobile builds, and services available for the selected plan, from the official downloads page. Then the paragraph that clarifies what the GitHub releases are for. Commercial binaries, signing, account services, remote access, billing and updates are built and operated outside this repository, and their version numbers, licence terms, capabilities and support policy may differ from an OSS tag. GitHub Release assets remain open-source build-verification outputs only. So a release asset on GitHub is a build you can verify, not a product you are supported on. That is a specific and careful distinction, and it is the kind of thing that usually only gets written down after someone gets asked whether the GitHub binary is the real one. The features list is short and each item is a decision about behaviour rather than a capability claim. Automatic incremental media sync scans the mobile photo library and queues unsynced photos and videos without manual file selection. Local discovery and pairing finds desktops through mDNS on the same LAN, then pairs with a QR code or a six-digit pairing code. Resumable serial transfers upload one file per phone at a time and continue unfinished queue items after a foreground LAN reconnection. The read-only queue and history item is worth pausing on. It shows transfer progress, completed files and completion-day statistics, without delete, skip or reorder controls. That is not an oversight, it is the OSS boundary showing through in the interface: the queue is a report of what the core does, not a control surface over what the commercial build does. Shared-file access lets mobile users browse and download files exposed by the desktop's local shared directories, and the documentation is careful to say this is separate from automatic media upload. And local diagnostics exports desktop and mobile diagnostics without relying on a hosted diagnostics service, which is the same principle applied to support tooling. ## What the non-OSS boundary excludes, in the project's own words There is a second callout listing what is not in the repository, and it is more specific than a general disclaimer. Remote access, cloud relay, tunnel credentials, official accounts and silent background continuation are unavailable and remain disabled. Desktop signing, notarization, mobile store distribution, package upload and auto-update infrastructure are not provided, with the exception that only stable-tag Android APK and AAB assets use repository signing secrets. That last clause is a small thing with a large meaning. The Android release assets are signed with the repository's own secrets, so a stable-tag Android build can be verified, while everything else about distribution is out of scope. It is a narrow carve-out from a broad exclusion. The third bullet is a packaging detail that most people would not think about. The source package does not redistribute Apple Bonjour for Windows. It uses a locally installed or configured Bonjour runtime when available, and otherwise the zeroconf-compatible fallback. That is a deliberate legal position with a technical consequence. Bonjour is Apple's implementation of the service discovery protocols, and redistributing it inside an AGPL source package would be a licensing problem. So the Windows build asks the user to have Bonjour installed, or falls back to a compatible implementation that is not Apple code. And the fourth bullet restates the Linux position. Linux remains a local build and package-verification target, not a supported desktop user surface. Read together, the two callouts are a coherent statement of how the product is split. The core is the LAN sync and it is genuinely complete in that narrow sense. Everything that turns it into a consumer service, remote access, accounts, relay, background continuation, signing and updates, lives outside the open repository and stays disabled in the open build. That is an unusual and arguably careful approach for a commercial product with an open core, and it has an obvious cost, which is that the open build does less than the paid one and the readme does not hide that. ## A pnpm and turbo monorepo with a Go sidecar The developer quick start shows what kind of codebase this is, and it is a workspace with several runtimes rather than a single application. ```bash corepack enable pnpm install --frozen-lockfile pnpm --filter @lynavo-drive/contracts build pnpm --filter @lynavo-drive/design-tokens build pnpm dev:desktop ``` Four commands, and the first pair is a pin and an install. The repository's pinned pnpm version is enabled with corepack, and the dependencies are installed with a frozen lockfile so that a local build matches the committed one exactly. Then the shared packages are built. There is a contracts package and a design-tokens package, each built separately, which is the monorepo convention of building the shared pieces before the apps that consume them. The design tokens package in particular is the thing that keeps a desktop app and two mobile apps visually consistent, and building it first is what guarantees the mobile app picks up the same values. Then the desktop dev mode starts, and the readme notes that the Electron window opens automatically and the desktop app starts the sidecar. That sidecar is the interesting architectural detail. The package manifest has separate scripts for it, one that changes into the Go service directory and runs make, and one that builds it. The root manifest also shows the two platform toolchains in its badges, Node at 22.12.0 or newer and Go at 1.25.6 or newer, so the repository genuinely spans two languages: a TypeScript and Electron shell with a Go process behind it. The manifest itself is a private package named lynavo-drive under AGPL-3.0-only, with engines requiring Node 22.12.0 or newer and pnpm 10 or newer, and the package manager pinned to a specific pnpm version. The script list shows how many targets there are. There are desktop dev and build scripts, mobile dev and build scripts, and then a set of scripts that all go through a single Node script with a profile and a target argument. The prod profile variants cover the desktop, the mobile through metro, iOS, iOS device and Android, and there are also mobile profile set and reset scripts. That pattern, one script with a profile and a target argument, is how you keep a dozen build variants from turning into a dozen near-duplicate commands. The release profile is a build that mirrors what the commercial build does, which is why the same script can drive both a local dev run and a production-shaped one. The top level directory listing confirms the shape: an apps/ directory for the desktop and mobile applications, a packages/ directory for the shared contracts and design tokens, a services/ directory for the Go sidecar, plus docs/, scripts/, pics/, a turbo.json, a pnpm-workspace.yaml, a tsconfig.base.json and a version-manifest.json. The version manifest and the build script's version sync check are worth noting. The build runs a version sync check before the turbo build, which means the version has to be consistent across the workspace before anything compiles, and the manifest file at the root is what that check reads. ## A contributor workflow rather than an installer, and the governance files The quick start is explicitly framed as a contributor workflow and not an end-user installer, and the readme points to a release playbook in the docs directory for local package builds and platform-specific verification. That framing does real work in a repository that also publishes signed installers elsewhere. The commands here are for building and verifying, not for installing on a user's machine. The top level also carries a set of governance and policy files that are worth noting individually. There is an AGENTS.md, which is the file that gives automated coding assistants their instructions for the repository. There is a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a SECURITY.md and a PRIVACY.md, and the privacy policy is notable for a project that is explicitly an alternative to two large cloud photo services. There is a THIRD_PARTY_NOTICES.md, which is the file that records the licences of the third party code that is vendored or depended on. Given that the project uses Electron, a Go toolchain, mDNS and NATS, and that it explicitly declines to redistribute one proprietary component, keeping the third party position accurate is a real obligation rather than a formality. The README exists in two languages, with a link to the traditional Chinese version at the top. There is a .node-version and a .nvmrc, which pins the Node version twice for the two tools that read it, and an .npmrc, a .prettierrc and a .prettierignore, an eslint.config.mjs, and an .editorconfig. The CI and release badges are worth reading as a statement of process. There is an OSS Release Gate workflow and a separate CI workflow, so the gate is a distinct step from the ordinary build. For a project whose open build deliberately has features compiled out, a gate that checks the release artefacts are the open ones is exactly the mechanism you would want, and the naming suggests it is a deliberate boundary rather than a generic publish job. The topic tags also tell you where the project sits relative to the alternatives it names. It lists google-photos, icloud and immich alongside localsend, nats, private-cloud and self-hosted, which places it in the same family as a self-hosted photo server while being much narrower in scope. ## Conclusion Lynavo Drive suits someone who wants their phone's photos on their own computer without handing them to a cloud provider, since the LAN-only design does that without an account and without the data leaving the network. It does not suit you if you need the cloud features, because remote access, relay, official accounts, background continuation and auto-updates are explicitly not in the open build, and the read-only queue means you cannot skip or reorder uploads there either. Before you rely on it, read the OSS boundaries section rather than the feature list, and note that the GitHub release assets are verification outputs rather than supported installers, so the desktop build on Windows also needs a Bonjour runtime installed or it falls back to a compatible implementation. ## FAQ ### What does Lynavo Drive actually do? It is a local-LAN incremental media sync tool from mobile, iOS and Android, to desktop, macOS and Windows. It scans the mobile photo library, queues unsynced photos and videos without manual selection, finds desktops over mDNS and pairs with a QR code or a six-digit code. ### What is not included in the open source Lynavo Drive build? Remote access, cloud relay, tunnel credentials, official accounts and silent background continuation are unavailable and stay disabled. Desktop signing, notarization, mobile store distribution, package upload and auto-update infrastructure are also not provided, with the exception that stable-tag Android APK and AAB assets use repository signing secrets. ### Can I use Lynavo Drive without an account? Yes. Foreground automatic sync works without sign-in or an account service, and missing non-OSS modules or account-service state do not block foreground LAN pairing and sync. The upload set comes only from the mobile photo library scan and the local pending queue. ### How do I build Lynavo Drive from source? Enable the repository's pinned pnpm version with corepack, install with a frozen lockfile, build the shared contracts and design-tokens packages, then start the desktop dev mode. The Electron window opens automatically and the desktop app starts the Go sidecar, which has its own dev and build scripts in the services directory. ### What are the GitHub release assets in Lynavo Drive for? They are open-source build-verification outputs only. Commercial binaries, signing, account services, remote access, billing and updates are built and operated outside the repository, and their version numbers, licence terms and capabilities may differ from an OSS tag. ## Sources - [License: AGPL-3.0](https://github.com/Lynavo/lynavo-drive/blob/main/LICENSE) - [Lynavo/lynavo-drive on GitHub](https://github.com/Lynavo/lynavo-drive) - [Project website](https://drive.lynavo.io/) - [README](https://github.com/Lynavo/lynavo-drive/blob/main/README.md) - [Releases](https://github.com/Lynavo/lynavo-drive/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lynavo-lynavo-drive