Mesh - Sonny

Mesh sessions and ownership

Sat, 24 Jan 2026 00:00:00 +0000

Use this page when work is owned by a configured remote runtime. For an ordinary local conversation, start with sessions and continuation . A local saved ID, a remote attachment, a portable copy and a split peer are different things. This guide uses Sonny 0.12.7 on Linux. Two actual managed processes used mTLS and the matching signed isolation worker on an owned rootless daemon. Session creation, a real TUI prompt/reply/detach and a separate read-only CLI observer were exercised with synthetic evidence and a controlled model endpoint. These checks do not certify physical-host connectivity, live provider login or all transfer/recovery cases. It requires the operator-managed mesh endpoint, identity/TLS, policy, admitted remote workspace, Recipe and provider access described in daemon operations . Review the intended node and session before an effectful command; a loopback address does not remove identity, authorization or isolation prerequisites.

Distributed Mesh

Sat, 24 Jan 2026 00:00:00 +0000

Use the mesh when work needs to run on an administered Sonny node while a client connects to observe or interact with it. Identify the session’s owner, the client identity and the intended action before changing its state. A disconnected terminal does not establish that the work stopped. The baseline here is Sonny 0.12.7 on Linux. Qualification started two actual managed processes with mTLS and a matching signed worker image on an owned rootless Docker daemon. A created session reported verified Docker isolation; actual TUI input and a read-only CLI observer received the controlled model’s reply. This is a single-host, development-workflow qualification. It does not establish physical-host networking, a live provider account, high availability or automatic recovery after a host disappears.

Mesh Architecture

Sat, 24 Jan 2026 00:00:00 +0000

graph TB C[Client / CLI / Desktop] -->|gRPC :50052| N1[Node A] C -->|gRPC :50052| N2[Node B] N1 <-->|Synapse QUIC :50053| N2 N1 --> DB1[(control.db)] N2 --> DB2[(control.db)] Clients connect to each mesh node’s control interface over gRPC. Nodes exchange mesh traffic using the configured Synapse transport. Each node maintains its own control database. Authentication and authorization apply at these boundaries. The two planes Share link Share this section Permalink Share via Twitter LinkedIn Facebook A node has separate client and peer listeners. Each needs its own reachable address, transport configuration and firewall policy. A successful handshake or readiness result on one plane does not qualify the other, or establish that an upgrade can preserve a running session.

Running the Mesh

Sun, 25 Oct 2026 00:00:00 +0000

Use this guide when you administer a managed Sonny node. Running an ordinary client or opening the desktop does not require starting this system service. The user-scoped supervisor and the packaged mesh daemon serve different roles. The package baseline here is Sonny 0.12.7 on Linux. The installed Debian unit was compared with that release’s source; the older Debian 0.11.31 package was extracted for comparison. Maintainer-script and reload tests used isolated fixtures. Runtime checks additionally used the actual installed binary, matching signed worker image, required Docker isolation and a disposable mTLS node. They exercised identity/policy refusals, live certificate reload and interrupted-session cleanup on one Linux host. Your deployed service still needs its own identity, policy, network and rollback qualification.

sonny mesh

Sat, 24 Oct 2026 00:00:00 +0000

The sonny mesh command group: mesh serve listener flags, push/attach/detach/transfer/terminate, node and session inspection, and the persistent mTLS client flags.