Agent skill · operations · nvidia
doca-container-deployment
Running an in-bundle DOCA service as a container on a BlueField (Argus, DMS, Firefly, or UROM service): kubelet standalone watching a static-pod manifests directory, YAML pod-spec drop, kubelet status / ENTRYPOINT logs / per-service liveness. Trigger on "how do I run my built service on the BlueField?", "where do I drop the pod-spec YAML?", "pod stuck in Pending / ImagePullBackOff / CrashLoopBackOff", "container Running but service isn't ready", "pod restart-loops after edit", or "DMS and Firefly together", even without naming container deployment. A DOCA-linked binary launched directly on the host or Arm belongs to doca-bare-metal-deployment. Covers smoke-before-bulk and the layered error taxonomy (pod-spec, scheduling, image pull, runtime, mount, network, version, host). Refuse and route elsewhere for per-service config schemas, DOCA install, library-API questions, external NVIDIA services (BlueMan, HBN, SNAP, Virtio-net), or full Kubernetes-cluster ops.
Why this skill is useful
Provides specific deployment patterns and error handling for DOCA service containers on BlueField that the AI wouldn't reliably generate on its own.
What it needs
Requires doca installed locally. About 6k tokens when loaded. Last updated 2026-08-07. 2,816 stars on the source repository.
What this skill does
DOCA container deployment Examples "How do I run a DOCA service container on BlueField?" — this is in scope after the setup recognize front door. Drop a documented pod spec; do not invent YAML or image tags. "The pod spec is in the directory but the pod never starts." — walk the eight-layer taxonomy before letting kubelet restart-loop the pod. Instructions Follow Loading order below. Open the tasks companion for configure / run / debug. Open the capabilities companion for the kubelet-standalone contract. Do not open every companion file. Where to start: This skill is for operating the cross-cutting DOCA container-deployment runtime — the shared pattern every DOCA service on the BlueField uses to come up (kubelet standalone agent on the BlueField Arm watching a static-pod manifests directory; the operator drops a YAML pod spec into that directory; kubelet schedules the pod and runs the container). If the developer has NOT yet decided container vs. bare-metal ("I just got a BlueField, what now?", "my code is built, how do I run it?", "how do I deploy this?"), route them BACK to doca-setup/SKILL.md first. That is the front-door routing decision. The wrong failure mode is to silently push every developer onto the container path because the agent loaded this skill first. ## recognize detects the system shape, asks the minimum residual question, and lands the developer on either this skill (when the workload is a packaged DOCA service to drop on a BlueField) or the bare-metal-path sibling doca-bare-metal-deployment/SKILL.md (when the workload is a DOCA-linked application binary the developer launches directly). If the developer is already on the container path, open the tasks companion and start at configure. If the question is what shape of runtime is this and what does the deployment contract look like, start at the capabilities companion. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills nvidia/doca-container-deployment