Outline Server: a REST wrapper around a Shadowsocks backend

shadowbox supervises the proxy binary and nothing else

The component at src/shadowbox is the part that matters. It runs and manages outline-ss-server, the Go binary that actually carries traffic, and it puts a REST API in front of that process for access key management. Nothing in this repository re-implements the protocol; the proxy backend lives in a separate project, outline-ss-server, and this repo is the supervision and control layer around it. The second component, at src/metrics_server, is separate again: a REST service for optional, anonymous metrics sharing. So the repository holds two REST surfaces, one that owns the running process and its keys, and one that only reports numbers and can be left out.

The censoring resistance comes from the dependency, not from this tree

The protection properties belong to the Shadowsocks backend this project depends on. Because Outline uses Shadowsocks, it picks up ongoing work that strengthens resistance to detection and blocking rather than freezing a design at one release. The specific protections named are AEAD ciphers, which are mandatory, probing resistance that mitigates detection techniques, protection against replayed data, and variable packet sizes to hinder identification. Four separate mechanisms, none of which live in this repository. The reasoning behind them sits in docs/shadowsocks.md, and the go.mod file pins the backend to a specific version, so the security surface you inherit is decided by that pin rather than by anything you configure here.

npm install does not start anything, and Go is a hard prerequisite

The install step looks short because most of the work is hidden in the build. The README requires Node on the LTS line, named as lts/hydrogen at version 18.16.0, NPM at 9.5.1, and Go 1.21 or newer, and the go.mod file asks for a later Go toolchain than that floor. Running npm install pulls the JavaScript dependencies and then, through a postinstall script, builds the task runner binary with go build, which is why Go has to be installed before the first npm command rather than after it. The engines field in package.json pins node to 18.x.x, so a newer major runtime is outside the range the project declares for itself. The install buys you a working task command, not a listening port.

npm install
./task shadowbox:start

Every task runs through a single taskfile entry point

Commands are not npm scripts for the daily workflow. After npm install, the build produces a task binary and the daily commands go through it: ./task shadowbox:start starts the server, and ./task clean removes build output. Taskfile.yml at the repository root holds those definitions, and the same file is what a pre-commit hook invokes, running lint and format through the task runner so style checks happen before a commit lands. There is no separate start script in the package.json scripts block beyond that postinstall build step. The practical consequence is that the task binary is on the critical path for running, cleaning, and committing, and it is built locally from source rather than installed as a dependency.

Workspaces spread the TypeScript across src, while Go sits beside it

The layout explains why the primary language is TypeScript but the tree also carries go.mod, go.sum, and a tools.go. package.json declares src/* as workspaces, so each component directory is its own npm package rather than one lumped source folder, and src/shadowbox and src/metrics_server are the two you can see. The Go side is a separate module that pulls the proxy backend and a task runner plus an addlicense helper as direct requirements, with a long indirect list behind them covering Prometheus client libraries, GeoIP database readers, and hashing packages. A repository with both an npm workspace tree and a Go module in the same root is unusual, and it is the clearest sign that this is a TypeScript control plane wrapped around Go components.

Access key management is the only REST job the project claims

The stated scope of the REST API is access key management, and that boundary is worth reading literally. A key is what a client needs in order to use the proxy, so the API is about issuing and managing those, not about routing traffic itself. Routing is the backend's job, and the dashboard, the interactive view of the same keys, belongs to a separate project, Outline Manager. If you go looking in this repository for a way to see or toggle connections at runtime, that interface is not here. The same boundary explains the metrics service being optional: it exists to share anonymous numbers and is not required for the server to function as a proxy.

Three tagged releases sit well behind the last commit

The repository is not archived, and the last push is dated 2026-10-28, so work is still landing. The released versions, however, tell a slower story: the three most recent tags are server-v1.12.3 from 2025-02-24, server-v1.12.2 from 2025-02-21, and server-v1.12.1 from 2025-02-19, all clustered within about a week of each other and more than a year behind that commit. Anyone pinning a version gets code from early 2025, while anyone tracking the default branch, master, gets whatever has landed since. There is no statement in the README about a support window or a patch policy for the tagged releases, so the gap between the newest tag and the newest commit is something you have to account for yourself.

Editorial conclusion

Outline Server fits operators who already run their own Shadowsocks infrastructure and want key management behind a REST API; it does not fit someone who wants a turnkey client, because the GUI lives in Outline Manager and the config lives in a nested README. Before adopting, check the Node 18 pin and confirm the tagged release versus master gap suits your update process.

Frequently asked questions

Official sources

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