Layotto packs state, config and pub/sub into the sidecar

One sidecar for traffic and for distributed capabilities

Layotto is described as an application runtime developed in Go that provides distributed capabilities such as state management, configuration management and event pub/sub, so that application development gets simpler. The motivation section puts it more precisely. The aim is to combine the Multi-Runtime idea with Service Mesh into one sidecar, and the claim is that whichever product you use as your mesh data plane, be it MOSN, Envoy or something else, you can attach Layotto to it and add Multi-Runtime capabilities without adding new sidecars. The example given is a Layotto process attached to MOSN that both serves as the data plane for istio and exposes runtime APIs such as a Configuration API and a Pub/Sub API. The authors also mention being surprised by how much a sidecar can do, and the ambition to make it the runtime container for FaaS through WebAssembly.

MOSN underneath gives it the network layer

The architecture is inherited rather than invented. Layotto is built on the open source data plane MOSN, which supplies the network layer management and the traffic control, and the feature list spells that out as service communication and service governance, with traffic hijacking and observation and service rate limiting named as examples. Because the network capability is already there, the runtime layer is additive rather than competing. The project layout shows the split in code: `cmd/`, `pkg/`, `components/`, `kit/`, `spec/` and `sdk/` sit alongside `deploy/`, `docker/`, `diagnostics/` and `demo/`, and the module dependencies in `go.mod` include `mosn.io/mosn` and `mosn.io/api`, so the proxy layer is a real dependency of the runtime rather than a description of intent.

gRPC SDKs and a configuration file instead of code changes

The portability story is the part most teams care about. Layotto provides SDKs in various languages, and the SDK talks to Layotto over gRPC. The application developer specifies the infrastructure type through the configuration file that Layotto provides at `configs/runtime_config.json`, and the README states that no coding changes are required, which greatly improves the portability of the program. That is a different contract from embedding a client library per backing store. Here the business logic talks to one local endpoint and the choice of state store, message queue or config centre is a deployment decision. The cost of that contract is that you now have a runtime to configure and a protocol to learn, and the application no longer holds a direct typed handle on the underlying system.

The API surface and what is actually implemented

The API table is the honest inventory of the project. State is described as writing and querying data of the key value model. Pub/Sub publishes and subscribes messages through various message queues. Service Invoke calls a service through MOSN, which the README notes is another istio data plane. Config writes, queries and subscribes to configuration through various config centres, with an Apollo demo linked. Lock is a distributed lock API, and Sequencer generates distributed unique and incremental IDs. Two entries are weaker. File, described as a file API implementation, and Binding, described as transparent data transmission, are both marked with a TODO where the quick start column would otherwise link to a demo. So the pattern is that the common primitives are covered by demos and the remaining ones are declared but not yet walked through.

Extension points, WASM and the actuator

Layotto is designed to be extended by the team that runs it. The API plugin feature is listed with a demo under the title of adding your own API, and the `demo/` directory shows the shape of that work with folders for bindings, configuration, cryption, delay_queue, email, faas, file, flowcontrol, hello, lifecycle, lock, oss, pluggable, prometheus, pubsub, rpc, secret, sequencer, sms, state and uds. The FaaS model is built on WASM and the runtime, and there is a separate entry for acting as the data plane of istio. On the operational side the actuator exposes a health check that reports the state of the app and of components inside Layotto, and a metadata query that reports metadata in Layotto and in the application, both with a demo.

Building it: a thin Makefile over make/*.mk

The build entry point is a Makefile that says all make targets should be implemented in `make/*.mk` and that it exists as a wrapper so the `--warn-undefined-variables` flag can be forced on. The wrapper runs a single sub-make through a `_run` target instead of invoking `make` recursively for each goal, which the comment explains is to avoid running multiple sub-makes when several goals are given on the command line. The Makefile also notes that the flag cannot be set from inside a Makefile because it only takes effect in the second phase, during recipe execution, and not during parsing. The repository also carries CircleCI configuration, a golangci lint setup, a licence header checker in `.licenserc.yaml`, a `RELEASING.md` and a `LEGAL.md`, alongside the quickstart demos and the docs.

Apache-2.0, an old release line and a busy main branch

The licence is Apache-2.0, with the licence header already present in the Makefile, and there is a `LEGAL.md` and a `CODE_OF_CONDUCT.md` at the root. The Go module is `mosn.io/layotto` and declares `go 1.18`:

module mosn.io/layotto

go 1.18

The dependency set pulling in gRPC, Envoy's go-control-plane, dapr components-contrib, OpenTracing and Zipkin, fasthttp and logrus among others. The release history is the part that needs a note. The tagged releases listed are v0.5.0 from 2023-02-15, a `test` tag from 2024-02-26 and `revert-1054-main` from 2024-07-05, which are not release artefacts a team would pin to in the way you pin v0.5.0. The repository is not archived and the last push was on 2026-10-18, so work continues on main even though the published version line has not moved since 2023.

Editorial conclusion

Adopt Layotto when your mesh data plane already runs as a sidecar and you want state, configuration, pub/sub, lock and sequencer APIs exposed from that same process instead of adding another proxy per workload. Do not adopt it if you only need one of those capabilities, since the full runtime is a large surface with its own configuration model and plugin system. Verify first which API plugins are actually implemented, because the README marks the File and Binding APIs as having no quick start yet, and check the release tags, since the only proper release in the list is v0.5.0 from 2023-02-15 even though the last push was on 2026-10-18.

Frequently asked questions

Official sources

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