Outline Manager and Outline Client: one repository, two install paths, and release tags that stopped in 2023

Two applications, two install links, and five client platforms against three manager ones

The repository holds two products rather than one, and they are installed from different steps of the same getting started page. Outline Manager lives in the server_manager directory, is a graphical interface for managing Outline servers, runs on Windows, macOS and Linux, and the project sends you to https://getoutline.org/get-started/#step-1 for the installer with details in server_manager/README.md. Outline Client lives in the client directory, is a cross-platform proxy for Windows, macOS, iOS, Android and Linux, and its installer sits at step-3 of that page with details in client/README.md.

Two asymmetries follow from those platform lists. Provisioning is a desktop act, so creating a server from a phone is not something this repository covers. And the Client is described as built for the server the Manager deploys, yet also as fully compatible with any Shadowsocks server, which means the Client is usable with no Manager in the loop at all. That compatibility claim is the reason the repository is not only a VPN suite but also a client for a wider class of servers, and it is the single most useful line in the README for anyone deciding whether the Client fits an existing setup.

Every tag names the client, and the most recent one is dated 2023-03-20

The release record and the branch history tell different stories. The three most recent tags are v1.10.1, labelled Outline Client 1.10.1 for Windows and Linux and dated 2023-03-20, v1.10.0-2, labelled Outline Client v1.10.0 and dated 2023-03-03, and windows-v1.9.1, labelled Outline Client (Windows) v1.9.1 and dated 2023-01-09. The default branch meanwhile received a push on 2026-11-02, so work is landing on master while the newest tag remains the 2023 one.

Consequences for anyone tracking this project. None of the three most recent tags names Outline Manager, so the manager is versioned by whatever the installer page serves rather than by anything in the tag list. The naming is also inconsistent across those three tags, with one plain version, one carrying a trailing revision number and one prefixed with the platform it covers, so a script that assumes semver shaped names will misread at least two of them. And because the client tag names are the only release signal, you cannot derive a Manager version from a client tag. Check the installer page for the Manager and treat master as the only current source of truth for both apps.

The Go module is named localhost and pins two pre-release SDK versions

The Go side of the repository is small but load bearing, and two details in it deserve a look before you build. First, the module declaration is not a real import path:

module localhost

go 1.25.0

Second, the direct dependency block includes two Outline SDK modules at pre-release versions, alongside the packages that do the client work:

require (
	github.com/Wifx/gonetworkmanager/v2 v2.1.0
	github.com/eycorsican/go-tun2socks v1.16.11
	github.com/goccy/go-yaml v1.18.0
	github.com/songgao/water v0.0.0-20200317203138-2b4b6d7c09d8
	github.com/stretchr/testify v1.10.0
	go.nhat.io/cookiejar v0.3.0
	golang.getoutline.org/sdk v0.1.0-rc1
	golang.getoutline.org/sdk/x v0.0.9-alpha.1
	golang.org/x/mobile v0.0.0-20250813145510-f12310a0cfd9
	golang.org/x/sys v0.36.0
)

golang.getoutline.org/sdk sits at v0.1.0-rc1 and the x subpackage at v0.0.9-alpha.1, so the client builds against a release candidate and an alpha of a library that is still pre-1.0. That is fine for an application, and it is a reason to read the client changelog before upgrading, since a dependency bump can arrive inside a client build without the SDK ever reaching a stable tag. The module name localhost means there is nothing here for another project to import by path, which is consistent with a repository of applications rather than a library.

The client turns a TUN device into SOCKS in userspace and drives NetworkManager on Linux

Two direct dependencies explain what the client actually does at the network layer. go-tun2socks bridges a TUN interface into a SOCKS proxy, which is how a single client binary can carry all traffic through the server without a separate kernel module per platform. gonetworkmanager/v2 is a Linux specific dependency, and it is there because system level network changes on Linux go through the NetworkManager D-Bus interface rather than through direct device manipulation.

What that means for you as a reader. The full tunnel behaviour is implemented in userspace, so the client is responsible for the entire path from the TUN device to the proxy. On Linux the client expects NetworkManager to be present and reachable, which is a real dependency in environments where networking is configured by other means. The README does not say which operations need elevated privileges on any platform, and the per platform answers live in client/README.md rather than in the top level page, so check there before scripting a rollout.

One repository, three toolchains: Node 22, Go 1.25 and a JVM for signing

The manifest pins a single Node major version and the Go module pins its own minimum, and the signing path adds a third toolchain:

  "engines": {
    "node": "22"
  },

The workspace list has four entries, infrastructure, server_manager, client and client/capacitor, which is where the desktop and the mobile client code both live. The desktop packaging path comes from electron-builder, while the clean script removes third_party/jsign/*.jar along with output and node_modules, and a .java-version file sits at the repository root. So at least one packaging step runs through a jar based signing tool and therefore needs a JVM, even though the project is TypeScript first.

The practical consequence is that a clean contributor environment needs Node 22 because the engines field says so, Go 1.25.0 to satisfy the module, and a Java installation for the signing path. The reset script exists for exactly this reason: it runs the clean step and then npm ci, which is how you get back to a known state after pulling changes without a global install of anything.

Build steps run through infrastructure/build/run_action.mjs and a root list.action.mjs

The npm scripts here are a thin dispatch layer, and the real work is registered elsewhere. The action script points at a runner in the infrastructure directory:

    "action": "node ./infrastructure/build/run_action.mjs",
    "clean": "npm run clean --workspaces && rm -rf output node_modules third_party/jsign/*.jar && go tool task clean",
    "format:all": "gts fix",
    "lint:gts": "gts lint",
    "lint:lit": "npm run lint:lit --workspaces --if-present",
    "lint:all": "npm run lint:lit && npm run lint:gts",
    "reset": "npm run clean && npm ci",
    "storybook": "storybook dev -p 6006"

Three things follow. Listing the available actions is itself an npm script, action:list, and the registry appears to be the list.action.mjs file at the repository root, so you learn what a step does by asking the runner rather than by reading package.json. Some steps are Go rather than Node: addlicense calls go tool task addlicense, the clean script finishes with go tool task clean, and the task definitions live in Taskfile.yml. And checks are split, with gts handling general TypeScript style and a per workspace lit lint running only where that workspace opts in, since the flag is --if-present. Consequence for contributors: package.json alone will not tell you what a build step touches.

Browser support is a lint failure, not a runtime surprise

The client is a web stack shipped inside desktop and mobile shells, and the repository treats browser support as something enforced in review rather than discovered in production. Three pieces do it: a .browserslistrc file at the root, browserslist in devDependencies, and eslint-plugin-compat, which is a lint rule set that fails a build when the code uses an API outside the browserslist targets.

What that changes in practice. If you add a call to an API that is newer than the declared support matrix, your lint run stops it, which is much cheaper than a crash report from a user on an older engine. The flip side is that the declared matrix is the ceiling: nothing in the repository describes a way to ship an API that only exists on the newest engine, and the consequence is that a feature gated on a modern browser has to be feature detected or excluded. Format and style sit in the same enforcement layer, with format:all running gts fix and lint:all combining gts with the per workspace lit lint, so the house style is not optional in practice.

Customer support, community chat and agent guidance are three different destinations

The short README sorts its own audience into separate places, which is worth knowing before you file anything. Customer support and direct contact go to https://support.getoutline.org. Community conversation goes to the Reddit community for Outline VPN and to the IFF Mattermost instance run with the Internet Freedom Festival, and contribution guidance lives in CONTRIBUTING.md. Repository automation has its own guidance file in AGENTS.md.

For a reader deciding whether this project fits, that routing tells you where each kind of answer comes from. One gap to keep in mind: the top level page says nothing about which versions the Manager currently supports, so a compatibility question is better raised in the community channels than answered from the repository, since the tag history only records client releases and the newest of those is dated 2023-03-20.

Editorial conclusion

Use the Manager to provision a server and the Client to reach it, and treat the tag names as a client only record rather than a release train. Before you build either app, check the Go SDK pin, the Node 22 engine field and the extra JVM step, because this repository is not a single toolchain.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. OutlineFoundation/outline-apps on GitHub
3. Project website
4. README
5. Releases