# ServiceComb Mesher: sidecar proxying without iptables, and without maintainers

> Apache servicecomb-mesher routes HTTP and gRPC traffic through a Go sidecar built on the go chassis framework, but its own README asks users not to deploy it until the project finds maintainers.

**apache/servicecomb-mesher** — A high performance service mesh implementation written in go

- Repository: https://github.com/apache/servicecomb-mesher
- Stars: 686 · Forks: 69
- Language: Go
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/apache-servicecomb-mesher

## Mesher is a sidecar proxy, not a control plane

Mesher is a Go implementation of a service mesh sidecar, built on the go chassis microservice framework, designed to sit next to applications rather than replace them. The repository description calls it 'A high performance service mesh implementation written in go', and the project positions it as a way to bring services written in other stacks, .NET or Java for example, into a ServiceComb controlled system. The control plane is ServiceComb service-center, which is listed as the first step before any build. Mesher is not a control plane, and it has no homepage of its own. Documentation sits at mesher.readthedocs.io, with per version copies generated locally from the docs directory. That distinction matters when you evaluate it: you are adopting a proxy component that expects an existing ServiceComb service registry, not a self contained mesh that brings its own control plane.

## Why Mesher refuses to touch iptables

The clearest technical decision in the project is what Mesher refuses to do. The feature list says 'No IP tables forwarding' and explains that Mesher uses the http_proxy environment variable and the gRPC proxy dialer instead, which it says makes for better performance than iptables based forwarding. Interception therefore happens at the application protocol layer. An HTTP client honours the proxy setting, and a gRPC client is wired with a custom dialer that routes calls through the sidecar. A kernel level mesh works differently: it rewrites packet destinations with iptables rules and redirects traffic on the way in, without the application taking part. The trade off is real. Application level interception only covers traffic whose client agrees to use the proxy, so a service that ignores the proxy settings is invisible to Mesher and its traffic bypasses the sidecar entirely. No privileged container mode for the sidecar is described anywhere in the get started instructions, which is consistent with a design that avoids kernel level redirection.

## One codebase, two roles: sidecar and ingress edge

The same Mesher binary plays two roles. In sidecar mode it runs beside a service and reports on that service. In edge mode it stands in front of the whole system and manages ingress traffic; the project says mesher is able to run as an independent edge service, and the 1.7.0 roadmap entry describes mesher ingress as mesher as an edge service to manage ingress traffic. That gives it the API gateway role the README describes, managing ingress traffic rather than only internal calls. Each deployment exposes an Admin API on an isolated port, exposing runtime information and metrics, and the Go module pulls in the Prometheus client libraries, so the metrics path is real rather than aspirational. Building the edge variant is a separate docker target, and runtime configuration is passed through PAAS_CSE_SC_ENDPOINT and PAAS_CSE_CC_ENDPOINT environment variables, which point the edge service at the ServiceComb control plane and config server.

## Local health checks that can pull a service out of the registry

Health handling is one of the more useful sidecar behaviours described. The project says that, as a sidecar, mesher is able to check local service health by policy and dynamically remove it from the service registry if the service is unavailable. This is agent style deregistration rather than a load balancer failure detection setting, and it depends on the sidecar having a working path back to the registry that ServiceComb service-center provides. The feature list also claims support for both Linux and Windows, which is what allows .NET and Java services to be governed by the same proxy, and it claims the flexibility of building your own service mesh and API gateway by extending lots of components of the go chassis framework underneath it. The go.mod file confirms that layering: go-chassis v2, go-archaius for configuration, openlog for logging, and a go-cache dependency for local caching.

## Building the sidecar from source with Go modules

The build instructions assume you already have service-center running, because the proxy has no useful behaviour without a registry. From a checkout, there is a module based build that ends in a native binary under cmd/mesher. The first command sets a module proxy, which is marked as needed only if you hit network trouble in some regions. Run these steps in a Go toolchain that supports the module version declared in go.mod.

```bash
export GOPROXY=https://goproxy.io #if you are facing network issue
cd mesher
GO111MODULE=on go mod download
#optional
GO111MODULE=on go mod vendor
cd cmd/mesher
go build mesher.go
```

The optional vendor step populates a vendor directory so the build can run without network access later. The go.mod file declares go 1.13 and pins grpc v1.27.0, so a current Go release will build it, but those pinned dependency versions are old and worth checking against your own policy before you rely on them. For a working end to end setup rather than a bare binary, the documentation points you to the mesher-examples repository, which is where the sample configuration and the examples directories in this project are meant to be exercised.

## The build script produces a tarball and a docker image

A second path wraps the same work in a shell script under the build directory. It expects GOPATH to point somewhere sensible, and the script is documented as producing both a binary archive and a docker image. The archive is named release/mesher-latest-linux-amd64.tar and the image is tagged servicecomb/mesher-sidecar:latest. The linux in that file name is worth noticing, since Windows support is claimed and no equivalent Windows packaging command is given here. The edge service has its own image, built from a dedicated Dockerfile, and it runs as a container with the two control plane endpoint variables and a published port. The run example leaves both endpoint values empty, so you are expected to supply real ones.

```bash
cd build
export GOPATH=/path/to/gopath
export GOPROXY=https://goproxy.io #if you are facing network issue
./build_proxy.sh
```

```dockerfile
sudo docker build -t servicecomb/mesher-edge -f docker/edge/Dockerfile .
```

```bash
sudo docker run -e PAAS_CSE_SC_ENDPOINT="" \
-e PAAS_CSE_CC_ENDPOINT="" \
-p 80:30101 \
--name mesher-edge servicecomb/mesher-edge
```

The published port 80 maps to container port 30101, which is the listener the edge service exposes for ingress traffic.

## A release history with long gaps and a maintainer warning

Maintenance is the headline fact for anyone weighing this project. The README carries a notice to contributors saying the project is not active due to lack of maintainers, and a second notice to users telling them not to use the project if possible until enough resources are found. The recorded activity matches that warning. The last push was on 2026-05-15. Releases are sparse: v1.7.0 on 2022-01-04, v1.8.0 on 2024-03-10, and v1.8.1 on 2026-02-04. A two year gap followed by another two year gap is not a cadence you can plan upgrades around. The repository is not archived, so code and history remain available, and the Apache-2.0 licence means the code can be used, modified, and redistributed under its terms, with the usual obligation to keep the licence and NOTICE files intact. Forking and carrying it internally is a more realistic path than waiting for a release, but that transfers the maintenance burden to you.

## Where Mesher is the wrong tool

Several boundaries are worth naming before you commit. Protocol coverage is narrow: the supported protocol list is HTTP and gRPC, so anything else passes through untouched. Traffic interception depends on application cooperation, which is a different operating model from a mesh that redirects at the kernel level and needs no cooperation from the client, so you would be running a different kind of system in a different way. Control plane coupling is total: service-center is a prerequisite, and the KIE integration described in the 1.7.0 roadmap lets one config server change both sidecar and ingress settings, which only helps if you already run that config server. The roadmap also lists skywalking support under in future, and the go.mod does carry a go2sky dependency, but no tracing configuration is documented. Finally, go.mod pins go 1.13 and grpc v1.27.0, which are ageing choices for a security sensitive edge component.

## Conclusion

Choose servicecomb-mesher only if you already run ServiceComb service-center and need a Go sidecar that speaks HTTP and gRPC without kernel level redirection, and only after checking that the missing maintainers leave you a maintainable dependency. Teams that need active releases, a wider protocol set, or a mesh that intercepts traffic without application cooperation should pick a different project. Before anything else, verify who will answer questions on the project, because the README itself tells users to wait.

## FAQ

### Is Apache servicecomb-mesher still actively maintained?

No. The project README states the project is not active due to lack of maintainers and asks users not to use it if possible until enough resources are found, and the last push was on 2026-05-15.

### How do I build the servicecomb-mesher sidecar from source?

With Go modules enabled, run go mod download in the mesher directory, optionally vendor the dependencies, then build from cmd/mesher with go build mesher.go. The build also expects ServiceComb service-center to be installed first, and the documentation points to the mesher-examples repository for a working setup.

### Does servicecomb-mesher use iptables to redirect traffic?

No. The feature list says there is no IP tables forwarding, and instead Mesher uses the http_proxy environment variable and the gRPC proxy dialer, which it says performs better than iptables based forwarding.

### Which protocols and operating systems does servicecomb-mesher support?

The supported protocol list is HTTP and gRPC, and Linux and Windows are both supported, which is what allows services written in .NET, Java, or Go to be governed by the same sidecar.

## Sources

- [apache/servicecomb-mesher on GitHub](https://github.com/apache/servicecomb-mesher)
- [Issues](https://github.com/apache/servicecomb-mesher/issues)
- [License: Apache-2.0](https://github.com/apache/servicecomb-mesher/blob/master/LICENSE)
- [README](https://github.com/apache/servicecomb-mesher/blob/master/README.md)
- [Releases](https://github.com/apache/servicecomb-mesher/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-servicecomb-mesher