Skip to content
Dreadnode Dreadnode Dreadnode

Publishing

Push a capability to the registry, control visibility, and confirm what was published.

Publish a capability and the rest of the platform can install it. The registry stores versioned OCI bundles scoped to your organization — push a new version, confirm it landed, and point your team at the exact ref.

Terminal window
dn capability validate ./capabilities/threat-hunting
dn capability push ./capabilities/threat-hunting --publish
dn capability info [email protected]

Before you push

Section titled “Before you push”

Two prerequisites:

  • version in capability.yaml is pinned semver (0.1.0, not latest)
  • dn login has authenticated the CLI against your server

dn capability validate ./path runs the manifest checks before upload. Use it when you want to catch schema errors without hitting the network.

Push from the CLI

Section titled “Push from the CLI”
Terminal window
dn capability push ./capabilities/threat-hunting --publish

Breakdown:

  • push uploads a new version
  • --publish makes the version visible to others in your org immediately
  • Omit --publish to upload privately; flip visibility later with dn capability publish <name>

For a monorepo of capabilities, dn capability sync discovers and pushes each directory under a root:

Terminal window
dn capability sync ./capabilities --publish

Push from Python

Section titled “Push from Python”

Same operation via the SDK, useful from build scripts or CI:

import dreadnode as dn


dn.configure(
    server="https://app.dreadnode.io",
    api_key="dn_...",
    organization="acme",
)


cap = dn.push_capability("./capabilities/threat-hunting", publish=True)
print(cap.name, cap.version, cap.status)

skip_upload=True builds and validates the bundle without sending it to the registry — handy for CI pre-checks.

Confirm what landed

Section titled “Confirm what landed”
Terminal window
dn capability info [email protected] --json

info is the safest way to verify the exact ref before asking others to depend on it. It shows the OCI digest, the publish state, and the manifest metadata the catalog surfaces.

Open the web catalog at /capabilities to see what your consumers see — the detail drawer surfaces the version, visibility, author/license metadata, and ready-to-copy install commands:

Web catalog detail drawer for a published capability

If the version, description, or keywords aren’t what you expected, stop here and push a corrected version before pointing teammates at the ref.

Terminal window
dn capability list --search threat --include-public

list shows every capability you can see, including the public catalog when you pass --include-public.

Versioning rules

Section titled “Versioning rules”
  • Versions are immutable — once 0.1.0 is pushed, the bundle never changes. Publish 0.1.1 for a fix.
  • Versions must be full semver (X.Y.Z). Prereleases and build metadata are not supported at the registry level.
  • The canonical name is <owner>/<name>. Bare names (threat-hunting) resolve against your active org.

Visibility

Section titled “Visibility”

Visibility is managed per capability name, not per version. Making threat-hunting public affects every version of it.

Terminal window
dn capability publish threat-hunting      # make public
dn capability unpublish threat-hunting    # make org-only

What gets pushed

Section titled “What gets pushed”

Every path declared in the manifest (agents, tools, skills, workers, dependencies.scripts) must exist on disk — missing files fail the push. The description field is the canonical listing text the catalog surfaces; keep it short and specific.

See the dn capability reference for every verb and flag.