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 loads every declared component before upload. It reports broken imports as error and components the loader skipped as degraded, with the cause and suggested fix. Use --strict to fail on component errors; degraded entries remain warnings.

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

The same verb pulls: dn capability sync https://platform.dreadnode.io ./stack writes every capability in your org to a folder, the inverse of the push above. That folder copies to another instance — see Loading Hub content for the SaaS-to-on-prem and air-gap flows.

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 quick view surfaces the description, version, visibility, author/license metadata, component inventory, and ready-to-copy install commands.

The orange capability name, component links, and View full details open the capability’s full page. Select the version beside its name there to inspect another published version without losing your current component or file view when that content still exists.

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.

Delete a version

Section titled “Delete a version”

Open the exact version in the web catalog and choose Delete. Enter its full ref, such as acme/[email protected], to permanently delete that version and its stored files. Other versions remain available; deleting the last version also removes the capability from the catalog.

Deletion has no archive or undo. The platform blocks it while a runtime has that exact version installed.

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.