Skip to main content

Marketplace vs direct helm

When to publish a package to the marketplace vs install a chart directly. Two paths exist; they're not interchangeable.

The short version​

  • Use the marketplace for charts your team will install more than once, or that need typed install forms, or that have org-specific defaults.
  • Use direct helm for one-off installs, ad-hoc CLI work, troubleshooting. No publishing required.

What's a marketplace package, really​

A marketplace package is a row in DT Edge Platform's DB that says:

  • "This is a chart you might want to install."
  • It points at a chart_ref (oci://... or HTTP repo)
  • It has one or more versions with default values
  • Optionally each version ships an x-form-schemas block — a JSON Schema that lets the UI render a typed form for the values

Publishing a package doesn't move chart bytes anywhere. The chart still lives in the registry; the package row points at it. What you're publishing is discoverability + form schemas + default values.

Direct helm — what you give up​

DT Edge Platform has a backend endpoint that takes a chart_ref + version + values without a marketplace row. It's not in the UI; it's API only. You give up:

  • Discoverability — your teammates can't find this chart in the marketplace grid
  • Typed install forms — only the YAML editor; no form schema means no validation hints
  • Org-curated defaults — every install starts from the chart's own defaults; org-specific overrides aren't pre-filled
  • Standard categorisation — the chart isn't tagged with global categories, so it doesn't show up in "all networking packages" type filters

What you keep:

  • The same install pipeline (operation row + worker run + helm SDK)
  • Image-pull credentials (you specify image_registry_ids in the request)
  • Audit log entries
  • All ownership + lifecycle features (upgrade, rollback, uninstall)

When marketplace makes sense​

Almost always for production work:

  • A chart you'll install more than once — even if just on staging + prod, the marketplace path saves time (form schemas
    • defaults bound)
  • A chart with config you want users to fill in correctly — form schemas catch bad values at type level, before the install attempt
  • A chart specific to your org — even if you're the only one who'll install it, having an org-curated defaults baseline helps you remember what's been configured how
  • Charts that share image registries — bind the registries once at publish time; every install picks them up automatically

When direct helm makes sense​

Niche cases:

  • One-off installs that won't recur — debugging an upstream chart, trying out a community chart you don't plan to keep
  • CLI / CI scripts that don't need the UI surface — though for these, an API key + the marketplace install endpoint usually beats the direct-helm endpoint
  • Bypassing the marketplace catalog during incident response — when you need to install a fix-version of a chart that's not yet published

What about CLI helm direct on the cluster?​

You can absolutely helm install directly on the cluster's kubeconfig with no involvement from DT Edge Platform. It just won't show up in the Applications list.

Why: DT Edge Platform filters its release list to releases stamped with the dtedge.io/managed=true label. The label is added by DT Edge Platform's helm install handler (via action.Install.Labels). A plain helm install from your laptop doesn't add the label, so the release stays invisible to DT Edge Platform.

This is intentional — operators who use helm CLI directly don't want their releases mixed into the team's main view.

If you want to "import" a CLI-installed release into DT Edge Platform:

kubectl label secret -n <namespace> -l "owner=helm,name=<release-name>" \
  dtedge.io/managed=true

The next sync (≤1 minute) picks it up.

Why not just CLI everywhere​

The marketplace surface gives you:

  • A form schema → typed installs without YAML editing
  • Cross-team discoverability
  • Operator-side audit trail (who installed what, when, with which values)
  • Version pinning + visible changelog (when versions ship release notes)
  • Scoped image-pull credentials (no per-install creds smuggling)

For a team's day-to-day "install the standard logging stack", those wins compound. CLI is for "I'm fighting an outage and need to deploy this fix-chart five minutes ago."

See also​