Architecture

A universe is one VM, a Postgres database, a Redis instance, and four platform images. That is the whole system, at every size. This section is the detail behind that sentence: what runs, what it talks to, how it is provisioned, and what a security review will ask you.

​

What runs

unoverse is the engine. Your Agents run here, your workflows execute here, and the platform’s MCP surface is served from here. It is the only service the internet reaches. The workflow engine is not a separate service. It runs in the same process, behind the MCP surface, and has no listener of its own. That consolidation is why a universe is four containers rather than seven. Canvas is where you build and observe Agents. It is an operator tool, in the same trust ring as SSH, reachable only from an address you nominate. Memory keeps user profiles and open tasks, so an Agent can reason about the same person across weeks. Spatial ML maintains the semantic map behind Spatial. Studio does not appear here. It runs on a developer’s own machine, reads their files off disk, and publishes to a universe over the API. It is never deployed.

​

Ports and trust zones

Four zones, and which one a service is in is the whole of its network exposure. Canvas is an operator tool, not a public page. It is not on the load balancer. You reach it directly, from the address you nominated, in the same trust ring as SSH and the log viewer. It then talks to the platform over the public surface like any other client. Two of those are worth reading carefully. 4104 and 5001 are published on the VM rather than bound to loopback, so what keeps them private is the cloud firewall’s default-deny, not the way the container is configured. That is a real control and it is enforced in your cloud account, but it is one layer rather than two. Binding them to the Docker network is tracked work. The gate is in the application, not in the proxy. That matters when a review asks what happens if the load balancer is misconfigured: the answer is that requests still fail authentication, because nothing about the proxy is load bearing.

​

Your code and the platform stay separate

The platform runs on the VM as Docker images, pulled from the registry by tag. You never fork it, and it never writes to your folders. Nothing you author rides inside an image. An image carries code and only code, which is why a platform upgrade cannot disturb your content and a content change cannot require a deployment.

​

State

All state is in Postgres and Redis. The services hold none of their own, apart from the engine’s in-process session registry, which is the reason a universe runs one engine today. Redis is the shared-state backbone, and two services use it: the engine, and Memory, which reads its ambient stream of observations from there. It is always provisioned by the stack rather than brought by you, because the platform owns its version and its TLS posture. Postgres can be yours if you have one. Data and State covers the rules that come with that, including a connection budget that is not optional.

​

Where to go next