Deploy DeepSeek Harness on Kubernetes: Self-Hosted AI Agent Infrastructure Guide (2026)

Running DeepSeek Harness on Kubernetes means treating it as two separate infrastructure problems: a lightweight, CPU-only orchestration workload (the harness process itself), and a much harder sandboxing problem (whatever the harness’s tools are allowed to touch on your behalf). Get the second part wrong and an open-source agent harness becomes the easiest way to hand shell access to an untrusted model output.

DeepSeek released Harness (dsh) as a developer preview on August 13, 2026 - MIT-licensed, built on an internal plugin kernel called Cordis, with the stated design goal of making every layer of the agent stack swappable. It landed the same day as DeepSeek-V4-Pro’s general availability, and picked up tens of thousands of GitHub stars within days. For platform teams evaluating whether to stand up internal agent infrastructure on their own clusters, here’s what actually changes versus running a standard LLM-serving stack.

What is DeepSeek Harness’s architecture, and why does it matter for Kubernetes?

DeepSeek Harness organizes around one idea: “Agent = Model + Harness,” where the harness is the infrastructure layer - the agent loop, tool registry, session store, sandbox, and UI. Most agent frameworks hard-code that layer. Harness instead runs everything through Cordis, a plugin kernel that manages mounting, unmounting, and dependencies between components, so you can select or replace the model provider, tool set, or storage backend through configuration rather than forking the source.

Four runtime modes ship out of the box:

For a platform team, the practical takeaway is that Standard mode is a remote-code-execution surface by design. The model decides what shell commands to run; your job is making sure “the model was wrong” has a small, contained blast radius.

How do you sandbox agent execution safely on Kubernetes?

Treat each agent session the way you’d treat a customer’s untrusted container, not the way you’d treat your own application code.

┌─────────────────────────────────────────────────────────┐
│  Ingress (per-tenant auth, rate limit)                  │
└──────────────────────┬────────────────────────────────────┘
                        ▼
        ┌───────────────────────────────┐
        │  Harness API/UI Deployment    │   stateless, CPU-only,
        │  (dsh web, Standard mode)     │   normal PodSecurityContext
        └───────────────┬────────────────┘
                        │  spawns per-session sandbox
                        ▼
        ┌───────────────────────────────┐
        │  Sandbox Pod (per session)    │   gVisor/Kata RuntimeClass,
        │  namespace: agent-sandbox-*    │   default-deny NetworkPolicy,
        │  runAsNonRoot, no NET_RAW      │   ephemeral, torn down on exit
        └───────────────┬────────────────┘
                        │  tool calls (shell, file, web)
                        ▼
        ┌───────────────────────────────┐
        │  Session log store (append-   │   S3/object storage, WORM
        │  only, per-tenant prefix)     │   bucket policy for audit
        └───────────────────────────────┘

Concretely:

1. Separate the control plane from the execution sandbox. The dsh API/UI process that handles auth and session routing doesn’t need shell access itself - only the sandbox does. Run them as different Deployments with different service accounts.
2. Use a RuntimeClass with real kernel isolation. Standard runc containers share the host kernel; a misbehaving or compromised agent session can attempt container-escape techniques against it. gVisor (runsc) or Kata Containers add a syscall boundary or a lightweight VM boundary respectively - the isolation guarantee an agent harness actually needs.
3. Default-deny NetworkPolicy per sandbox namespace, egress allowed only to the model API endpoint and any explicitly permitted tool destinations (a search API, an internal doc store). An agent that can reach your internal network is a lateral-movement risk, not a feature.
4. restricted Pod Security Standard: runAsNonRoot: true, drop all capabilities, readOnlyRootFilesystem where the tool loop allows it, automountServiceAccountToken: false unless a tool genuinely needs the Kubernetes API.
5. One namespace per tenant, not per session, with per-session pods torn down on exit. Namespace-per-session is usually too much control-plane churn at any real volume; use ownerReferences and a TTL controller instead to garbage-collect finished sandbox pods.

This is the same isolation posture we’d recommend for any framework that gives a model shell access - it isn’t specific to DeepSeek Harness, but Harness’s plugin model makes it easy to forget the sandbox is a separate concern from the plugin that implements it.

Does self-hosting DeepSeek Harness actually save money?

This is where the math changed under everyone’s feet in the same week Harness shipped. DeepSeek raised V4-Pro API pricing on August 16, 2026:

That’s roughly a 2-4.5x increase depending on tier and time of day. The harness itself costs nothing to run - it’s MIT-licensed and the compute footprint of the orchestration layer is small - but the model behind it is what actually drives your bill, and DeepSeek is no longer the cheap default it was a few months ago.

What this means for a self-hosting decision:

• If you’re routing Harness at DeepSeek’s hosted API, run your own token-volume numbers against the new pricing before assuming self-hosting the harness saves money versus a hosted agent product with bundled model access.
• If you’re self-hosting an open-weight model behind Harness (it’s model-agnostic, so this is a real option), the cost equation shifts to GPU capacity and utilization instead of API pricing - see our vLLM vs TGI vs Triton benchmark for what that infrastructure actually costs on Kubernetes.
• Session volume matters more than sticker price. A platform running a handful of internal agent sessions a day has different economics than one running thousands of CI/eval sessions through Minimal mode.

How do you scale agent sessions differently from LLM API traffic?

Agent sessions aren’t stateless request/response traffic. A single session can run for minutes, hold open a sandbox pod, accumulate tool-call history, and spike CPU unpredictably mid-session when the model decides to run a build or a test suite. Plain CPU-percentage HPA reacts too slowly to that pattern.

What works better in practice:

• KEDA on custom metrics - queue depth of pending sessions, or active-session count from the harness’s own session store, rather than CPU utilization on the orchestration pods.
• A pod-per-session TTL controller for the sandbox layer, so idle or completed sessions get garbage-collected instead of accumulating as zombie pods.
• PodDisruptionBudget tuned for long sessions. A cluster autoscaler node drain shouldn’t kill a 20-minute agent session mid-task; either checkpoint session state to the log store frequently enough to resume, or exclude long-running sandbox pods from routine node churn.
• Separate node pools for the CPU-only harness control plane versus the sandbox execution layer, so a burst of agent activity doesn’t starve unrelated workloads on shared nodes.

DeepSeek Harness vs. other open harnesses for self-hosted deployment

If you’re comparing self-hosted options rather than defaulting to whatever got the most GitHub stars this week:

None of this is a reason to avoid DeepSeek Harness - the plugin-everything architecture is a genuinely interesting bet, and it’s the newest entrant with the most momentum right now. It’s a reason to run it in a staging cluster with the sandbox controls above before anything touches production traffic, given it’s explicitly a developer preview with expected breaking changes.

Getting this right on your own infrastructure

Standing up agent infrastructure on Kubernetes is a platform engineering problem before it’s an AI problem: sandboxing, per-tenant isolation, autoscaling for stateful sessions, and audit logging all need to exist before the harness choice matters much. If you’re evaluating DeepSeek Harness, OpenCode, or a self-hosted agent stack against hosted alternatives for a GCC deployment, AI/ML Infrastructure on Kubernetes is where we scope that - typically a 2-3 week engagement covering the sandbox architecture, cost modeling against your actual session volume, and a security review before go-live.