Lantern VPN: a censorship circumvention client built on Flutter and sing-box

The problem Lantern solves, and the audience it assumes

The README opens with a single sentence of positioning: censorship circumvention available for free download on any operating system. That is a narrower claim than a general-purpose VPN. Lantern is aimed at someone whose network blocks destinations and who needs a client that decides on its own how to reach them, on a phone or a laptop, without a server to rent or a configuration file to write.

The repository topics confirm the framing: accelerator, censorship, circumvention, gfw, lantern, router, vpn. The gfw topic is the tell. This is software built for networks where a fixed protocol or a fixed endpoint stops working, not for someone shopping for the cheapest exit node in a country with an open internet.

The distribution model follows from that audience. The README ships installers for Windows 10 and up, Windows 7 as a separate binary, Android 6 and up, macOS 10.15 and up, iOS 11 and up as an ipa, and Linux for both amd64 and arm64 in deb and rpm form. It also states that stable links exist in multiple places for hosting redundancy, and that if the App Store is unavailable in a region there are FAQ steps for downloading anyway. Those two sentences describe a project that expects its own download page to be blocked.

What the Flutter app and the Go core each do

The primary language is Dart, and the top-level layout is a Flutter application: lib/, android/, ios/, macos/, linux/, windows/, web/, pubspec.yaml, analysis_options.yaml, and a test_driver/ directory. Alongside it sits a Go module, go.mod and go.sum, plus a lantern-core/ directory containing an ffi/ subdirectory. The Makefile names the pieces directly: LANTERN_LIB_NAME is liblantern, LANTERN_CORE is lantern-core, and FFI_DIR is lantern-core/ffi. So the architecture is a Flutter front end calling into a Go library through FFI, not a Flutter app that reimplements networking in Dart.

The transport layer comes from sing-box. The go.mod requires github.com/sagernet/sing-box v1.13.19, and a replace directive swaps it for github.com/getlantern/sing-box-minimal v1.13.19-lantern. There is also a commented-out replace for github.com/sagernet/sing pointing at a Lantern fork, and an active replace for github.com/refraction-networking/water pointing at github.com/getlantern/water. The module also requires github.com/getlantern/radiance. In other words, Lantern does not write its own proxy protocols; it maintains forks of an established proxy suite and pins them.

The comment block above those replace directives is worth reading for what it says about maintaining a fork. It explains that a gvisor pseudo-version must be forced because the tag's first pre-release identifier is purely numeric, which semver ranks below the timestamp-and-hash identifier of an ordinary pseudo-version, so minimal version selection can never pick it on its own. That is a real cost of forking: you inherit the dependency resolution problems of the upstream tree and have to pin your way out of them.

Installing Lantern on Linux and completing a first run

There is no package repository and no documented one-line installer. The README points at release assets and mirrors. For a Debian or Ubuntu machine on amd64, the stable asset is lantern-installer.deb, published both on the GitHub releases page and on an S3 mirror. Download it, then install it with dpkg:

curl -L -o lantern-installer.deb \
  https://github.com/getlantern/lantern/releases/latest/download/lantern-installer.deb
sudo dpkg -i lantern-installer.deb

dpkg will report the package installation and may print dependency warnings; the README does not document a fallback for unmet dependencies, so if dpkg stops partway, apt-get -f install is the conventional repair but is not described in the repository. RPM users on amd64 take lantern-installer.rpm from the same release, and arm64 users take lantern-installer-arm64.deb or lantern-installer-arm64.rpm. The README lists a beta channel at a separate S3 path for each platform and warns that beta builds may be unstable.

After installation, the README does not describe a CLI, a daemon flag or a config file. The documented path is to launch the application and let it connect. The Makefile is the build-side entry point, not a user-facing one: it defines targets including linux and macos, and the Dockerfile ends with make linux. That target is for producing a build, not for running the client.

If you want to build from source instead of using an installer, the Dockerfile is the only build recipe in the repository. It is Ubuntu-based, installs Go at GO_VERSION 1.23.1, clones Flutter to /opt/flutter, then runs flutter pub get and make linux:

FROM ubuntu:latest
ENV GO_VERSION=1.23.1
ENV GOPATH=/go
ENV PATH=$GOPATH/bin:/usr/local/go/bin:$PATH

Note the mismatch: the Dockerfile pins Go 1.23.1 while go.mod declares go 1.26.2, and the Dockerfile runs flutter channel master followed by flutter upgrade. A container build therefore tracks two moving upstreams. The Makefile comments also warn that pubspec.yaml's version field is a hardcoded literal that lags the real release line and is only rewritten in CI, so a local build stamps a stale version into telemetry and support tickets.

The version stamping trap in local builds

This deserves its own treatment because it affects anyone building from source rather than downloading an installer. The Makefile states that APP_VERSION is the full version from pubspec.yaml, with precedence environment over pubspec.yaml, and that CI must export APP_VERSION. It documents why: on Windows CI the shell expression runs under cmd.exe, which mangles the quoting in the grep and sed pipeline and returns empty, producing an empty common.Version ldflag and a 400 missing app version at /v1/config-new.

That is a hard failure, not a cosmetic one. An empty version means the client cannot fetch its configuration. The Makefile then describes the local fallback: read pubspec.yaml directly, with a PowerShell branch so Windows developers without Git Bash or WSL still get a working build. It also gives the caveat plainly, that pubspec.yaml is only rewritten to the authoritative version in CI by release.yml from scripts/ci/version.sh, so a local build resolves current Go dependencies from go.mod but stamps the stale literal.

The practical consequence is that a sideloaded or development build is mislabeled in telemetry and support tickets, as the comment says. If you build Lantern yourself and then file a bug, the version you report may not be the code you ran. The repository is honest about this in a comment rather than in user documentation, which is where most readers would look.

What the README does not tell you

The README is a download table and a links list. It does not document a kill switch, a split-tunnelling rule, a protocol selector, a logging verbosity setting, or a way to point the client at your own server. Every one of those is a normal expectation for a VPN client, and their absence from the front page is not proof they are absent from the application, but it does mean you cannot evaluate them before installing.

There is also no rollback or downgrade procedure. The README offers stable and beta channels and notes that stable links exist in multiple places for hosting redundancy, but it says nothing about reverting to a previous version if a release regresses. For software whose whole purpose is staying reachable, that is a gap: if a new build fails to connect on your network, the documented recovery path is to find an older asset yourself.

The third-party dependency situation is another thing to weigh. Lantern depends on forks of sing-box, sing, water, wazero, gvisor and wireguard-go, pinned through replace directives in go.mod. That is normal for a project that needs behaviour upstream will not merge, but it means security fixes arrive when the fork is updated, not when upstream ships them. The repository does not state a policy for tracking upstream advisories. Anyone evaluating Lantern for an organisation should treat that as an open question rather than assume it is handled.

How Lantern differs from a self-hosted circumvention stack

The obvious alternative for a technical user is running sing-box directly, since Lantern already depends on it. The difference is who makes the decisions. With sing-box you write a JSON or YAML configuration that names your own server, your own protocol and your own routing rules, and you run it as a daemon. You control the endpoint, so you know who sees your traffic, and you can read the entire configuration before starting it.

Lantern inverts that. The client ships a curated set of transports and picks among them, which is exactly what makes it usable by someone who will not rent a VPS. The trade is transparency and control: the README does not expose the selection logic or a way to override it, and the client is not aimed at users who want to audit a config file. If your threat model includes not trusting the operator of the exit nodes, sing-box with your own server is the more defensible choice, and it costs you a server and an afternoon of configuration.

A second alternative is a mainstream commercial VPN. Those generally document features Lantern's README does not, such as kill switches and per-app routing, and they publish independent audits. They also fail in exactly the situation Lantern exists for: when the provider's fixed endpoints are blocked, a commercial VPN has fewer ways to adapt than a client built around transport rotation. The two tools are not substitutes so much as answers to different questions.

Licence, upgrade cadence and what they cost you

Lantern is GPL-3.0. If you redistribute the client or ship a modified version, the licence's source-availability terms apply to what you distribute. Running the official installer on your own machine is not redistribution, and this is not legal advice: read the LICENSE file in the repository and get counsel if you plan to bundle Lantern into a product.

The upgrade picture is visible from the release list. v10.0.0 landed on 2026-09-18, preceded by v10.0.0-beta5 and v10.0.0-beta4 on 2026-09-15. The last push to the repository was on 2026-09-21. That is a fast cadence with a real beta channel, which is good for a circumvention tool, because a transport that works this month may not work next month.

The cost falls on the operator, not the user. Someone has to keep the forks current, keep the pinned pseudo-versions resolving, and keep the CI version stamping correct across Windows and Unix shells. The Makefile comments show that this maintenance is already fiddly enough to require a documented workaround. If you are considering contributing rather than just using Lantern, the Flutter-plus-Go-FFI split means most networking changes land in lantern-core or in the fork, not in the Dart layer.

Editorial conclusion

Lantern fits people who need a free client on a phone or desktop and are willing to accept a closed decision-making layer: the transport picks are made for you, and the README documents no way to inspect or override them. It is the wrong tool if you need a self-hosted endpoint, a documented kill switch, or a config file you can audit before traffic leaves the machine. Before adopting it, verify the checksum of the installer you pull, since the README lists three independent hosting mirrors for the same stable build, and check the release notes for v10.0.0 rather than trusting the version string a local build stamps into telemetry.

Frequently asked questions

Official sources

1. getlantern/lantern on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases