Registration

Getting a node package onto a tenant is operator-mediated, not self-service — what you hand over, what to expect of the turnaround, and the every-tenant-sees-every-package behaviour to plan around.
Registering a node package is operator-mediated, not self-service. There is no partner-facing publish endpoint and no Cockpit flow that lets you register a package on a tenant yourself. You hand the built package to revenexx, and a platform operator registers it for the tenant; your nodes then appear in that tenant's palette.

Plan for that in your release process. It is a human step, not a deploy — which means a fix to a node is not something you can ship at 17:00 on a Friday.

There is deliberately no publish subcommand in the SDK's CLI. If you are looking for one, this page is why.

What you hand over

  • The built package — compiled output plus the manifest.json the SDK CLI's manifest subcommand produces. Run the build first; a missing manifest is the most common reason a package cannot be registered. See Custom nodes.
  • The package version you intend to be registered, and what changed since the last one.
  • Which tenant it is for.
  • What it needs to work — the credential types it publishes or depends on, and any secret keys its nodes reference by convention. This is what saves the first support conversation after it lands.

Keep the source. Do not treat a registered tarball as your only copy: the manifest format is still settling (v0-draft), and a future version may require a rebuild.

After it is registered

Your nodes appear in the Integration Studio palette for that tenant, grouped under the bundle label from your package.json — see Package manifest. Credential types you shipped appear in the credential-type list, and templates you shipped appear under Templates.

A new package version is another registration. Existing workflows are unaffected until an author re-saves the node, because a node instance pins the node version it was placed with.

The limit to plan around

Node packages are not entitled per tenant today. Every registered package is visible to every tenant, so a package registered for one customer shows up in another customer's palette.

Two consequences, and both are about expectations rather than mechanics:

  • Do not treat registration as a way to keep something private to one customer. If a node's existence, its name, or its description reveals something confidential — a customer name in a slug, an unannounced integration — do not ship it in a package name or label. Name nodes after the system they talk to, not the customer who paid for them.
  • Nothing leaks between tenants at run time. Tenancy is enforced on execution: a workflow only ever sees its own tenant's data, and credentials and secrets are per tenant. What is shared is the visibility of the package, not any data.

Per-tenant entitlement is a known gap rather than a design decision. Check the changelog before you plan around it changing.

Where to go next

Was this page helpful?