Deployment topologies in practice

Yig supports three deployment topologies. The choice determines where the agent runtime executes, what infrastructure the operator is responsible for, and how the agent reaches the customer’s data systems.

All three share one structural property: customer data does not transit Yig infrastructure. The agent reads from and writes to the customer’s own systems. Topology determines where the runtime doing that reading and writing lives.

Local

Local is for one person. The agent runtime runs on the operator’s own machine. Data is read from and written to local files, locally accessible databases, or systems reachable from the operator’s network.

When to choose it. Evaluation and proof-of-concept. Single-user deployments where the operator is also the reviewer. Regulated environments where the organisation’s data handling policy requires that no data leave the local machine.

What the operator is responsible for. Everything: installing and updating the runtime, managing the API key, configuring the audit log destination, and keeping the machine available when workflows need to run.

What it cannot do. Multi-user deployments. Team reviewer flows (a local deployment has a single operator; the reviewer gate cannot be satisfied by a second person unless they have access to the same machine). Scheduled or event-triggered runs that need to operate while the operator is offline.

Migration path. A local deployment can be migrated to customer cloud by packaging the same configuration into a container and deploying it in the customer’s cloud account. Audit log records from the local deployment are retained at their original destination.

Customer cloud

Customer cloud is for a team that owns its infrastructure. The agent runtime runs inside the customer’s own cloud account (AWS, Azure, GCP, or equivalent). Data is read from and written to systems within the same cloud account, or accessible via the customer’s network controls.

When to choose it. Team deployments where multiple reviewers need access from different locations. Organisations with existing cloud infrastructure and the capacity to operate a containerised runtime. Finance teams that need scheduled close workflows that run without a human triggering each run.

What the operator is responsible for. Deploying and maintaining the containerised runtime, managing credentials and secrets, configuring network access to data sources, and ensuring the runtime has access to the audit log destination. Yig provides a Docker image and a Kubernetes profile; the operator applies it to their infrastructure.

What it enables over local. Multiple authorised reviewers. Scheduled execution. Integration with the customer’s existing identity provider (SSO). Persistent availability.

What Yig handles. Runtime updates are distributed as new Docker image versions. The operator applies them on the schedule they choose.

Single-tenant managed

Shared infrastructure with access controls is the SaaS default. Dedicated infrastructure per customer is what “single-tenant managed” means here.

Single-tenant managed is dedicated, not multi-tenant. The agent runtime is deployed and operated by Yig in a dedicated, isolated environment. No other customer’s workflows, data, or audit logs share that environment. The customer’s data is still read from and written to the customer’s own systems — the managed runtime connects via customer-configured egress only.

The surfaces the team works in — Slack, Excel, Word, CLI — are held to the surface contract regardless of which side runs the runtime. Topology determines where the runtime lives; it does not change what the agent owes the surfaces.

When to choose it. Organisations that want team-scale deployment with the security properties of customer cloud, but prefer not to operate the runtime themselves. Finance teams without dedicated platform or DevOps capacity.

What the operator is responsible for. Configuring data source access credentials and egress rules, reviewer authorisation, and audit log destination. The operator does not manage the runtime, updates, or infrastructure.

What Yig handles. Runtime operation, updates, availability, and isolation guarantees. Single-tenant means each customer’s environment is not shared with any other; the isolation is structural, not access-controlled.

What this topology is not. Multi-tenant. In a multi-tenant managed deployment, multiple customers share infrastructure with logical access controls. Single-tenant managed means dedicated infrastructure per customer. Multi-tenant managed is intentionally not on this list — it would require different data handling commitments that do not yet exist in the product.

Choosing between topologies

The decision tree is straightforward:

Question	If yes →
Single user, evaluation or regulated local-only requirement	Local
Team deployment, own cloud account and ops capacity	Customer cloud
Team deployment, prefer not to operate runtime	Single-tenant managed
Need air-gapped execution with self-hosted model	Local or Customer cloud with Ollama

There is no topology that is generically “best.” Local has the smallest footprint; customer cloud gives the most operator control; single-tenant managed minimises operational overhead.

Migrating between topologies

Topology migrations are configuration changes, not data migrations. Audit log records from the previous topology remain at their original destination; the new deployment starts producing records at a new destination.

The agent’s workflow configuration, reviewer authorisations, and installed templates migrate with the deployment configuration. No re-installation of templates is required. A common path is local for evaluation → customer cloud for team rollout, executed by exporting one configuration and importing it to the next.

Topology is a configuration choice. It is never a data-plane choice. Laptop, cloud account, or dedicated managed environment — the customer’s general ledger, workbook, and document store stay in the customer’s stack. If a future Yig product ever needs customer financial data to live on a Yig-managed server to function, the architecture changed shape, and the change is upstream of this article.