MOSN: a Go network proxy for Istio service mesh and standalone L4/L7 load balancing

The problem MOSN addresses, and who ends up using it

A service mesh needs a data plane process that sits next to every workload, terminates and forwards traffic, and takes its configuration from a control plane rather than from a file an operator edits by hand. MOSN is that process, written in Go. The README describes it as a cloud-native network proxy open sourced by Ant Group and used in production containers during the 11.11 shopping festival. Those are the project's own claims; the repository does not include the measurement methodology behind them.

The audience is narrower than the tagline suggests. If you run Istio and want a data plane implemented in Go rather than C++, MOSN is a candidate. If you need a standalone L4/L7 load balancer, an API gateway, or a cloud native Ingress and you are comfortable with a proxy whose extension points are Go interfaces, it is also a candidate. If you want a proxy you configure entirely from documented YAML without reading source, the repository as shipped will frustrate you: the README lists capabilities but does not walk through a configuration file.

How MOSN forwards traffic: listeners, clusters, and the XProtocol layer

The README's capability list maps onto a conventional proxy architecture. Listeners accept connections; the core forwarding layer handles TCP, UDP, and transparent traffic hijack; routing is virtual-host based with matching on headers, URL, prefix, variables, and DSL, and supports redirect, direct response, and traffic mirroring. Behind that sit clusters, which the README says can be of type original dst, dns, or simple, with connection pools, circuit breakers, active health checks, and load balancing policies of random, rr, wrr, and edf. Subset routing and subset load balancing key off host metadata.

The part that distinguishes MOSN from a plain Envoy deployment is the extension surface. Protocol support beyond HTTP/1.1, HTTP/2, and gRPC is built on the XProtocol framework, and the README states that protocols can be identified automatically. Extensions are available through go-plugin, through a separate process, and through WASM. The README also says custom extensions are possible at the TCP I/O layer and the protocol layer, which is a lower-level hook than most proxies expose. The go.mod file confirms the dependency footprint this implies: envoyproxy/go-control-plane for xDS, hashicorp/go-plugin, tetratelabs/wabin, and a long list of tracing and service-discovery clients including Jaeger, go2sky, Zipkin, Nacos, and TarsGo. That is a large dependency graph for a proxy binary, and it is the price of the built-in integrations.

Installing MOSN and running a first instance

The README gives exactly one installation instruction: use `go get -u mosn.io/mosn`, or clone the repository into `$GOPATH/src/mosn.io/mosn`. The module path in go.mod is `mosn.io/mosn`, and the module declares `go 1.18`, so that is the minimum toolchain the repository expects. The Makefile builds two targets, `mosnd` and a sidecar binary named `mosn`, and defaults `BUILD_IMAGE` to `golang:1.18`.

There is no documented one-line command that starts a proxy with a sample config, so the practical first step is to build from a clone and inspect the configuration files under `configs/` and the runnable material under `examples/`. The repository layout lists `examples/cn_readme/`, `examples/codes/`, and `examples/en_readme/`; the README does not describe what each contains, so treat them as the starting point to read rather than a documented tutorial.

go get -u mosn.io/mosn

That command fetches the module into your Go module cache. To build the binaries the Makefile defines, work from a clone instead:

git clone https://github.com/mosn/mosn.git
cd mosn
make build

The Makefile names `mosnd` as the main target and `mosn` as the sidecar target, so the build output is those binaries. The README does not document the flags either binary accepts, and it does not document a default config path, so read `Makefile` and `configs/` before assuming a startup command. For Istio integration, the repository carries an `ISTIO_VERSION` file at the top level and an `istio/` directory plus an `istio_ctrl.sh` script; the README states integration with Istio 1.10 in full dynamic resource configuration mode, so check that file against your control plane version rather than assuming compatibility.

Where MOSN is the wrong tool

The README is a capability inventory, not an operator's manual. It does not document how to write a configuration file, what the schema of that file is, how to run the binary, or how to roll back an upgrade. Hot upgrades and graceful shutdown are listed as process management features, but the README does not describe the upgrade procedure or the failure semantics if an upgrade is interrupted. If your team needs a proxy whose operational contract is written down before you deploy it, that gap is a real cost, not a documentation nit.

Protocol coverage is the second boundary. HTTP/1.1, HTTP/2, and gRPC are supported directly. Anything else, including protocols you already run, has to go through the XProtocol framework, which means writing Go code. A team that wants to proxy an unusual protocol without maintaining a fork of a proxy is better served by a project whose protocol support is configuration-driven.

Version cadence is the third consideration. The most recent release listed is v1.6.1 on 2024-08-01, following v1.6.0 on 2023-08-17 and v1.5.0 on 2023-04-25. The repository's last push was on 2026-07-14, so development activity is visible in the repository even though tagged releases are roughly annual. If your upgrade policy depends on frequent tagged releases, plan around that spacing.

MOSN against Envoy as an Istio data plane

The direct alternative for the Istio data plane role is Envoy, and the difference in approach is visible in the README itself. MOSN says it integrates an Envoy network library while remaining a Go program, and it exposes extension points at the TCP I/O layer and the protocol layer, plus go-plugin and process-based extension. Envoy's extension model is C++ filters and, increasingly, WASM. MOSN's is Go plus WASM.

That distinction matters most for teams whose codebase is already Go. Adding a custom protocol or a custom routing decision to MOSN means writing Go against interfaces in this repository; doing the same in Envoy means writing C++ filters or accepting the constraints of the WASM ABI. The trade is that Envoy has a larger operator community and a configuration surface that is documented in far more depth than what this repository contains. MOSN also ships a set of integrations that Envoy does not bundle by default, including Nacos service discovery, Jaeger, go2sky, and Zipkin, which the go.mod dependencies confirm.

Licence and the cost of staying current

MOSN is Apache-2.0, the same licence as Envoy. The repository carries a `LICENSE` file and a `.licenserc.yaml`, which suggests the project runs a licence-header check over source files. Apache-2.0 permits commercial use, modification, and redistribution with the usual requirements around notices and patent grant. That is a general description of the licence, not legal advice for your situation; if you embed MOSN in a product, have your own counsel read the terms.

The upgrade cost is dominated by two things. First, the dependency graph in go.mod is broad: xDS control-plane libraries, WASM tooling, and several tracing and service-discovery SDKs all move independently, so a Go toolchain bump or an upstream SDK change can require code changes in this repository before you can build. The module declares `go 1.18`, which is old enough that newer Go releases may surface build or vet issues. Second, the release tags are spaced roughly a year apart based on v1.5.0, v1.6.0, and v1.6.1. If you track master rather than tags, you are tracking a branch whose last push was 2026-07-14, and you own the compatibility work yourself.

Editorial conclusion

MOSN fits teams already running Istio who want a Go data plane they can extend at the TCP I/O and protocol layers, and teams that need a standalone L4/L7 proxy with XProtocol-based protocol extension. It is a poor fit if you want a proxy with a complete, self-contained configuration reference in the repository, or if you are not prepared to read the code and the website documentation to fill the gap the README leaves. Before adopting, verify three things: that your Istio version matches the value in the ISTIO_VERSION file, that your target protocol is either HTTP/1.1, HTTP/2, gRPC or something you are willing to implement through XProtocol, and that the last push date of 2026-07-14 against a v1.6.1 release from 2024-08-01 is an acceptable release cadence for your upgrade planning.

Frequently asked questions

Official sources

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