devops

DevOps: Cloud Environments, Nodes, Sessions & Deployments

Ariadne can see and act on the infrastructure your code actually runs on — Azure, AWS, Portainer, or a Docker host of your own — through a single fenced, audited gateway. Every mutating action is scoped and policy-gated before it runs; nothing bypasses that gate, including the UI.

Accessing DevOps Settings

Go to Settings → Cloud Environments (/cloud).

The page is a stack of collapsible sections: Environments, Infrastructure nodes, Remote coding sessions, Deployments, and Build artifacts.

1. Environments

An environment is one configured target the agent can query and, within limits, control.

Adding an environment

1. Click Add environment
2. Enter a name and choose a provider:
   • Docker node — a Docker host reachable through one of your own infrastructure nodes (below). No credentials are stored — the socket never leaves that machine.
   • Portainer — base URL, endpoint ID, and an API token.
   • Azure / AWS — supported by the underlying design, but the hosted adapters aren't wired up yet; you can save the configuration now, but Test Connection will fail until they land.
3. Click Save

Testing and capabilities

Click the plug icon next to an environment to run Test connection. This probes the provider and records exactly which capabilities are available (inventory, metrics, logs, container control, exec, deployment, …) — and, if something is missing, why (e.g. "the service principal lacks Microsoft.App/*/read"). The agent is told what an environment can do before it plans an action, so it doesn't build a plan around something it will be refused.

Scope fence (deny-by-default)

Click an environment's name to open Scope & policy. The scope fence is the hard boundary on what the agent may ever touch in that environment: rows of (kind, value) — resource group, region, subscription, account, cluster, endpoint, label, or container-name pattern.

An empty fence means nothing is in scope. Every mutating action is refused until you add at least one row. This is deliberate — you opt infrastructure in, rather than opting it out.

Action-class policy

Every action the agent can take falls into one of four classes:

Set the decision per action class from the Action-class policy table. notify means the agent acts and then tells you; approve parks the action until you approve it; never refuses it outright.

2. Infrastructure nodes

A node is a Console instance running in --node mode on a machine you control, giving the agent visibility into (and, if you allow it, control of) that machine's Docker host — cheaper and richer than any hosted control plane, because nothing is proxied through a cloud API.

Deploying a node

1. Open Deploy a node, name it, and (optionally) tick Allow remote coding sessions on this node
2. Click Generate to get a single-use enrolment token, valid for 15 minutes, embedded in three ready-to-run install commands: a Linux systemd one-liner, a Windows service command, and a docker run with the Docker socket mounted
3. Run the appropriate command on the target machine

Approving a node

A newly enrolled node appears as pending — it can only send heartbeats and telemetry; it cannot yet run any command. Approve it from the Infrastructure nodes table before it becomes usable. You can also suspend or forget a node at any time.

Once approved, the node reports live CPU, memory, disk, network and GPU metrics, and can be selected as the target for a Docker node environment (§1) or a remote coding session.

The node's own veto

A node never trusts a command just because it came from the server — it independently checks the request against its own local policy file before acting. If the node's owner has capped it (e.g. "restart only, no mutate"), the server cannot raise that ceiling. Treat nodes as a trusted-network feature: the person with root on the box always keeps the last word.

3. Remote coding sessions

The agent can provision a short-lived coding environment on infrastructure you've granted, check out a repo into it, and work in it like any other headless conversation — useful for hands-off work on a repo that shouldn't live on your own machine, or for giving the agent a disposable sandbox.

Ask the agent to start one (start_remote_coding_session), or watch existing sessions in the Remote coding sessions table: conversation link, environment, state, resource shape, start time, and expiry. Click Stop to end one early.

Sessions have an idle timeout (default 30 minutes) and a hard wall-clock ceiling (default 4 hours) — they don't run forever by accident, and an orphaned workload left behind by a crash is swept automatically.

4. Deployments

For workloads Ariadne manages directly (an image-tag roll, a Portainer stack, an ECS/Container Apps revision), the agent plans a deployment, you (or policy) approve it, and it applies with automatic verification.

• Plan — the agent calls plan_deployment; this is always read-only and produces a diff (image, env, previous revision) without touching anything.
• Apply — click Apply on a planned deployment. After applying, Ariadne polls a health/error-rate check for a few minutes; a failed check triggers an automatic rollback.
• Rollback — available any time on an applied or failed deployment; restores the previous image/revision recorded in the plan.

A deployment whose target is :latest is rejected outright — the agent must resolve it to a digest first, which is what makes rollback reliable.

5. Build artifacts

When a build has no shared registry to push to (a single-file publish, a docker save tarball with nowhere else to land), the agent parks the output in Ariadne's own blob storage as a courier between two machines that only both trust Ariadne. The Build artifacts table shows what's stored: name, kind, size, SHA-256 digest, producing session, source commit, and expiry countdown.

Artifacts expire after 14 days by default (90 days if a live deployment depends on them for rollback). Bytes never pass through the model's context — the agent only ever sees { artifactId, sha256, sizeBytes }.

Security notes

• Credentials are resolved only inside the gateway and adapter — never returned to the agent, never logged, never shown in a conversation.
• Every gateway call (read or write) is written to an audit trail: actor, environment, capability, action class, target, and outcome.
• Log lines, error messages and other content read back from infrastructure are treated as untrusted data, never as instructions — even if they contain text that looks like a command.

See Goals & Schedules for infrastructure alert rules (CPU/memory/disk/GPU thresholds), which live on the Autonomy page alongside other watchers, and Support for how a struggling workload turns into an investigation.