Application Bundling

Microbus distinguishes a microservice (a single unit with its own hostname and .creds) from an application (a deployable bundle composed of one or more microservices). The same set of microservices can be packaged as one large bundle, several smaller bundles, or one bundle per microservice. The choice is a security lever the operator controls — bundling decides where trust boundaries fall in the deployment.

Bundle Membership and Trust

Microservices in the same bundle share an OS process and address space. The consequences:

Shared memory. A compromised microservice has direct memory access to its bundled siblings — heap, stack, file descriptors, secrets cached in process memory. The operating system is the trust boundary at this level, and within an OS process there is no boundary.
Each microservice still has its own NATS connection. Even when bundled, each microservice opens its own connection with its own signed .creds. The broker enforces ACL per microservice, not per process.
Cross-bundle traffic always traverses NATS. It picks up broker-verified source identity, ACL enforcement, and the per-call audit trail. There is no shared-memory shortcut for cross-bundle calls.
In-bundle calls also traverse NATS in the default code path. The framework does not have a “skip the bus when in the same process” optimization that bypasses ACL — every call is subject to the same broker-side enforcement, even if the messages happen to flow between two goroutines in the same OS process.

So bundling decides the memory boundary, not the broker enforcement boundary. Broker enforcement happens regardless of how you bundle. Memory isolation only exists at process boundaries.

Topology Examples

One Bundle (Single Binary)

All microservices in one application. One OS process, one binary, one deployment unit.

Best for local development, integration testing, small deployments where memory isolation is not a security concern.
Trade-offs maximum simplicity. Memory of every microservice is reachable by every other microservice in the bundle. A compromise of any microservice yields the secrets and state of all of them.

Per-trust-root Applications

The two foundational :666 services (access token, bearer token) and any custom :666 services are each deployed as their own application. Everything else is bundled freely.

Best for typical production. Recommended starting posture.
Trade-offs N+M+K processes where N is your normal bundle count, M is the number of trust roots, K is any other isolation case. Modest extra cost for substantial isolation gain on the highest-stakes microservices.

Per-workload-class Applications

Group microservices by trust class:

One bundle for trust roots (or per-trust-root, recommended).
One bundle for ingress + ingress-adjacent (the HTTP ingress, ID-bridge wrappers).
One bundle for compliance-audited services (PCI scope, GDPR-relevant data handlers).
One bundle for everything else.
Best for deployments with regulatory or audit requirements that demand specific microservices be deployable, restartable, and reviewable independently.
Trade-offs more processes, more deployment artifacts. Each bundle is independently rolled out, restarted, and rolled back.

Per-microservice Applications

Every microservice is its own application.

Best for maximum isolation. Useful when the deployment runs untrusted or third-party microservices alongside first-party ones.
Trade-offs highest process count and orchestration overhead. Each microservice carries its own framework runtime, NATS client, observability initialization. Memory and startup latency add up.

Recommendations by Microservice Class

Class	Recommended posture	Why
Trust roots (access token, bearer token, custom `:666`)	Own application	Compromise of any other bundle cannot reach memory of the trust root.
Shell service	Own application	Executes arbitrary commands; compromise extends fully into the host.
HTTP ingress	Own application	Broad ACL surface; sees user bearer tokens before exchange; logical entry point under attack.
Foreman	Own application	Holds workflow state; compromise affects every flow in the deployment.
Compliance-scoped services	Own application	Independent audit, restart, rollout boundary.
Everything else	Bundle freely	Per-broker ACL still applies; OS-process isolation cost not justified.

These are starting recommendations, not rigid rules. A deployment running in a single AZ on a small VM may justify a flatter bundle structure; a deployment running multi-region with adversarial multi-tenancy may justify near-total isolation.

Trade-offs to Weigh

Process count vs. isolation. Each application is one OS process and one set of OS-level overhead (memory, file descriptors, scheduler entries). The marginal cost is small per process but adds up at hundreds of microservices.
Latency. In-bundle calls still go through NATS, so latency is dominated by broker round-trip, not process boundaries. Splitting a bundle does not meaningfully change latency.
Deployment surface. More bundles means more deployment artifacts to roll out coherently. The framework’s topology tooling helps but does not eliminate the operational cost.
Memory footprint. Each application carries its own framework runtime. At scale, the per-process memory floor matters.
Resilience. A crash in a bundled microservice can take its siblings down. Splitting trust roots into their own applications means the trust root’s uptime is independent of the rest.

What Bundling Does Not Do

It does not change which microservice can call which endpoint. That is determined by interservice ACL, which is per-microservice and independent of bundling.
It does not change the actor-claim model. Actor JWTs propagate uniformly across hops regardless of whether the next hop is in-bundle or cross-bundle.
It does not protect against shared-state attacks at layers below the OS — hypervisor, hardware, supply chain. Those are outside the framework’s threat model.