Agent environment / deepseek-harness

Run DeepSeek Harness in an isolated cloud sandbox.

One API call gives the DeepSeek iterative bugfix harness a real Linux machine to loop in — run, observe, patch, rerun — until the task exits clean or the budget runs out.

Start building Quickstart

TEMPLATE

deepseek-harness

AUTH

DEEPSEEK_API_KEY

ISOLATION

gVisor

EGRESS

default-deny

OVRIN / SANDBOX C603 EXITED 0

import ovrin client = ovrin.Client() sandbox = client.sandboxes.create( template="deepseek-harness", env={"DEEPSEEK_API_KEY": key}, ) result = sandbox.run( 'dsh run --task bugfix --max-iters 12' ) print(result.stdout)

✓isolated with gVisor19 ms

✓sandbox ready · /workspace mounted151 ms

✓DeepSeek Harness started2.0 s

✓task completed27.4 s

Why a sandbox

DeepSeek Harness is happiest with a whole machine.

The harness is a loop, not a single call: run the reproduction, read the failure, patch, rerun. Long-running, iteration-heavy and shell-heavy — the profile that most needs a hard boundary around it.

01

Bounded, disposable iteration

Cap iterations and wall-clock time per sandbox. A runaway loop burns its own box, not your fleet.

02

Reproduce-then-fix stays isolated

Flaky test harnesses and half-built repro scripts never touch anything outside /workspace.

03

Network on a leash

Default-deny egress. Allowlist api.deepseek.com, your registry and your git host. Nothing else resolves.

What's in the template