Process topology is how a deployment groups services into operating-system processes. It is a choice made by the deployment, over components. It is never a merge of biomes. A laptop or an appliance can run the backend as one composed process. A large cloud can run every service in its own process. Some deployments mix the two.

As a biome author you do not choose this and you do not declare it. The service SDK handles it. What you owe is code that works in any shape.

What a deployment decides

For each service component, a deployment decides:

  • Own process. The component runs by itself, as an isolated service.
  • Composed. The component is mounted, with others, in one process. Each one keeps its own identity, route prefix and registry entry.

Your manifest declares only facts about the component itself, such as its scaling mode. There is no "composed" opt-in and no trust class to declare.

The platform enforces the rules that make composition safe:

  • A process holds components of one trust class only. Anything that holds key material is never composed with other code, and third-party code is never composed with first-party code.
  • A deployment may always isolate more than the minimum. It can never isolate less than the rules allow, and a topology that breaks a rule is refused before anything starts.
  • A component that must run as a single instance is only placed in a process that is not replicated.

What this means for your code

Business code must behave the same in every shape:

  • No process.env. Read configuration through a typed config contract that your package owns, resolved from an injected reader and checked at boot. A missing required value fails at boot with a message that names the field.
  • No process handlers. Do not call process.on or process.exit. In a composed process they would affect your neighbours. The host refuses a module that installs them.
  • No port ownership. Do not assume you own the port or a root-relative route namespace. The host assigns where you listen.
  • No fixed paths. Do not rely on an image path or the working directory. Find your own files relative to your own package.
  • No telemetry setup. Do not start telemetry yourself. The SDK does.
  • Peers only through generated clients. Reach another service through its generated client. Do not add a peer URL setting of any kind. Services register at boot, and clients find peers through the Service Registry.
  • Name the member you call. A composed process answers at one front door and dispatches each request by the x-xema-service header. The SDK's database-credential client sends that header, naming the database pool service, so a request to a composed pool reaches the right member.
  • Peers may be late. If a peer is not ready at boot, you get a bounded retry and then a failure that names the peer. Nothing hangs and nothing continues in a degraded state.
  • Safe to scale out. Retries are idempotent and no truth lives in the process.

Your service entry file comes from the SDK (@xemahq/xema-service-nest), and your module is a stable export with no side effects at import.