Deployment

Local runtime

The local runtime starts the control plane with a single command and has the control plane create a process-level execution environment for each task. It is the fastest way to verify the domain model.

make run-local

Once it is up, open http://127.0.0.1:8080 and complete the configuration on the model gateway page under settings. Those steps are in the next section. The model a task uses is chosen when the task is created.

The local runtime is the right way to verify the domain model, the control plane, the task runtime and artefact handoff. It does not provide the resource isolation or the network policy boundary of Kubernetes.

Local Kubernetes deployment

The Kubernetes path deploys the full isolated execution boundary. Before you start, the Agent Sandbox prerequisites must be in place — the Agent Sandbox Controller, the RuntimeClass and the network policy enforcer are not covered by the unified Helm install.

The prerequisite steps are documented under deploy/prerequisites/agent-sandbox in the repository.

Generate the private configuration

The Helm install needs a private values file carrying the database credentials, the object storage credentials and the initial administrator configuration. Generate it first and store it safely; do not commit it to version control.

Run the install

FUSION_HELM_VALUES=/absolute/path/helm-private.yaml make deploy-local

This performs the unified local Helm install. It does not build images, and it does not take over cluster resources already managed by an existing manifest. You can also pass the private values path as the first argument to deploy/helm/deploy-local.sh.

What a successful install does not prove

A successful install proves only that the Helm release completed and the basic health checks pass. It does not prove any of the following:

• that the control plane can reach the model gateway and complete a real inference call;
• that the runner can clone the target repository;
• that the sandbox imposes the execution boundary as intended;
• that a task can go from creation all the way to delivery.

Each of those has to be verified separately. The four verification levels are set out in the platform operations section.

Configure the model gateway

Whichever path you took, no task can run without a usable model gateway.

1. Open the model gateway page in platform settings.
2. Enter the gateway address.
3. Save the API key. The key is encrypted with the platform master key and is never echoed back, by either the page or the API.
4. Add the models you want to offer, with their provider and model identifier.
5. Select a model when you create a task.

The platform manages gateways by capability class. A gateway carrying chat and reasoning and a gateway carrying embeddings keep separate addresses, capability catalogues, health states and credential revisions; they do not merge into one domain identity even when a deployment points both of them at the same underlying gateway.

Credentials come in two tiers. Platform credentials are configured by an administrator and used by the platform itself; user credentials are stored by each member and used for the work scopes that member is entitled to. Ordinary members can neither read nor write platform credentials, and an agent inside a workspace never falls back to user credentials.

Configure enterprise identity and document ingestion

Enterprise single sign-on, or pulling requirement text from an enterprise document system, requires the PostgreSQL identity mode.

After signing in as a system administrator, open the enterprise identity and documents page in settings, fill in the region, application ID, application secret and public base URL, and enable single sign-on and document authorisation separately. Changes take effect immediately on save; no restart is required. The application secret can only be written or rotated, and is never echoed back by the page or the API.

The environment variables below are for first start-up or disaster recovery only. When the database has no administrator configuration yet, they create the initial record; when a configuration already exists, they do not overwrite the administrator's revision.

FUSION_LARK_APP_ID=cli_xxx
FUSION_LARK_APP_SECRET=***
FUSION_PUBLIC_BASE_URL=https://example.internal
FUSION_LARK_AUTO_PROVISION=true

Two callback URLs must be registered in the application: one for sign-in, and a separate one for document authorisation. Content authorisation needs document read and offline access permissions. At present only an explicit document URL entered by an administrator is supported, and only Markdown is pulled — the platform does not scan an entire knowledge space, and it makes no claim to inherit the source system's access control.

Verify the installation

make verify

The aggregate check covers the protocol authority and retirement gates, static analysis, tests and builds for each independent module, and front-end type checking and the production build.

Features that involve sandboxes, browsers or external storage should also be put through their corresponding live-run acceptance. A passing compile or a basic health check is no substitute for running it for real.