---
id: architecture
title: "Processes"
summary: "The processes that make up Viaducta (Manager, Controller, Host, LLM, Roslyn, log shipper, cloud bridge), what each does, and the buses they communicate over."
audience: user
keywords: "architecture, manager, controller, host, llm, roslyn, log shipper, cloud bridge, nats, kafka, uds, opensearch, keycloak"
---
# Processes

Viaducta is a set of cooperating processes. The **Manager** serves the designer, a **Controller** runs each execution
environment, and **Hosts** run the flows. Each process can be placed on its own machine, or all of them can run in a
single container.

```mermaid
flowchart TB
  browser["Designer (browser)"] -- "HTTPS, websocket" --> manager["Manager"]
  agents["External AI agents"] -- "MCP" --> manager
  manager --- roslyn["Roslyn process<br/>(C# editing)"]
  manager --- llm["LLM process<br/>(AI assistant)"]
  manager -- "management bus<br/>NATS, Kafka or UDS" --> controller["Controller<br/>(one per environment)"]
  controller -- "execution bus<br/>usually UDS" --> hosts["Hosts<br/>(run the flows)"]
  controller --> shipper["Log shipper"] --> opensearch[("OpenSearch")]
  bridge["Cloud bridge<br/>(remote site)"] -- "websocket" --> controller
```

## Manager

The backend of the designer. It serves the REST API and the designer's websocket, validates the user's Keycloak
token, hosts the MCP endpoint for external AI agents, keeps the AI assistant's data and generates code for other
applications.

The Manager keeps no repository of its own. It reads and writes flows, types and settings on the Controllers over
the management bus, so one Manager serves every environment of one or more tenants.

## Controller

One Controller runs each execution environment, as a Windows service, a systemd service or a container. It:

- owns the environment's **repository**: flows, types, expression settings, database links, certificates, network
  routes, alarm definitions and hosting tags, as plain files with their history;
- starts, supervises and stops the **Hosts**, and starts the auto-start flows;
- commits to and pulls from **Git**;
- runs the **network hub** that cloud bridges connect to;
- starts the **log shipper**.

## Host

A Host compiles and runs flows. The Controller starts Hosts as the flows' hosting strategies require (see
[Running flows](./runtime#hosting-strategies)). Besides running flows, a Host serves the designer's runtime tools for
its flows: the data monitor, the debugger, the profiler, the file watcher and the test agent.

## LLM process

The AI assistant runs in its own process, one per tenant, started by the Manager and stopped after five minutes
without use. It talks to the model provider you configure: Microsoft Foundry (Azure OpenAI), or any
OpenAI-compatible endpoint such as vLLM or Ollama, including models on your own hardware.

## Roslyn process

C# code completion, IntelliSense and diagnostics in the designer come from a Roslyn process, started when you open
the first C# script of a flow, one process per flow. When you reopen the flow the running process is reused; after
five minutes without use it ends and returns all its memory. It serves the editor only; flows are compiled by the
Hosts.

## Log shipper

Started by the Controller. It reads log messages from the bus, writes them to OpenSearch in bulk and answers the
designer's log searches. Keeping the OpenSearch client out of the Hosts keeps every Host small.

## Cloud bridge

A small program for Windows, Linux and macOS, installed at a site where systems must be reached. It connects out to
the Controller's network hub over a websocket and carries **network routes** in both directions: flows reach
databases and devices at the site, and systems at the site reach services published by flows. No VPN and no inbound
firewall rule are needed. You download the bridge from the designer, already configured for its site.

## Communication planes

The processes talk over a message bus. Each connection between process groups is a **plane**, and each plane uses
the bus that suits where its processes run:

| Plane | Between | Typical bus |
|---|---|---|
| Management | Manager and Controllers | NATS, or UDS when they share a machine |
| Execution | Controller and its Hosts | UDS |
| Development | Manager and Roslyn processes | shares the execution bus, or NATS |
| Cognitive | Manager and LLM processes | shares the execution bus, or NATS |

- **UDS** (Unix domain sockets) is the fastest and connects processes on one machine. Hosts and their Controller use
  it, and a single-container installation uses it everywhere.
- **NATS** connects processes on different machines or sites: one Manager driving Controllers in several data
  centres, or Roslyn and LLM processes moved to their own machines.
- **Kafka** does the same as NATS, for organisations that want every message between the processes on a bus they
  can inspect.

A plane without a bus of its own shares the execution bus. Channels are separated per tenant.

## Identity

Sign-in goes through **Keycloak**. The Manager validates the token on every request and websocket connection, and
the user's roles (designer, viewer, administrator) decide what they can do. A **tenant** has its execution
environments and its users; one installation serves one tenant or many.