Who Owns an n8n Node After It Is Built?

An n8n node is not one file with one owner. A working integration usually has an API specification, source repository, npm package, build workflow, documentation, credentials, test data, and an n8n verification record. The person or company that generates the package may not control all of those pieces.

Set ownership and access before the first build. Put the answers in the project agreement or an ownership schedule, then check the live accounts before the package is published. A release can make a node available to users without giving your team the repository access or npm permission it needs to fix the next API change.

The path from spec to a verified node passes through four hand-offs: OpenAPI document → GitHub repository → npm package (published by a GitHub Actions workflow) → n8n Creator Portal submission. Each hand-off has its own owner and its own set of people with access, and those can differ.

The five control points to name

Start by naming the account, organization, or team that controls each artifact. Do not use a person's name as a shortcut for a business owner. People change roles; account permissions and package namespaces need a durable home.

Artifact	Control it gives the owner	Questions to answer
OpenAPI document and mapping decisions	Defines the operations, fields, authentication description, and generated inputs	Who may change the specification? Where is the approved version stored?
GitHub repository	Controls source, issues, pull requests, releases, Actions workflows, secrets, and settings	Is it in the SaaS team's organization? Who has administrator access?
npm package	Controls published versions, package metadata, maintainers, and deprecation	Which npm account or organization owns the package? Who can publish?
Build and publish workflow	Connects a commit and workflow run to the package that users install	Who controls the workflow file, trusted publisher settings, and secrets?
n8n Creator Portal submission	Tracks the request for n8n's verification review	Which account submitted it, and who receives review requests or follow-up questions?

The table separates ownership from access. A contractor can have write access without owning the repository. A service can prepare a publish-ready package without owning the npm namespace. Record both facts.

GitHub ownership and npm ownership are separate

The GitHub repository and the npm package can have different owners. That arrangement may be deliberate, but the agreement should say who can change each one.

GitHub says a repository transfer gives the new owner administrative control of its contents, issues, pull requests, releases, projects, and settings. The transfer also has effects on collaborators, secrets, webhooks, forks, and URLs. Read the current GitHub repository transfer documentation before you promise a handover. A collaborator invitation is not the same as a transfer.

npm uses its own owner and maintainer list. An npm owner can publish new versions, change package metadata, and add other owners. npm documents a transfer path that adds the new maintainer, waits for acceptance, and then removes the old maintainer. Scoped package names have a different constraint because the scope is tied to the user account or organization name. See npm's package transfer instructions and confirm the package name before choosing the exit path.

Ask for these details in writing:

• The exact GitHub organization and repository name.
• The GitHub role your team receives, including administrator access when you need to control settings and Actions.
• The exact npm package name and account or organization that owns it.
• The npm permission your team receives and who can publish a new version.
• The account that controls two-factor authentication, recovery email, and trusted publisher settings.
• The person or team that can transfer the repository or package if the service relationship ends.

Do not infer any of those answers from a repository URL or from the fact that a package appears on npm. Check the account settings or request a written statement from the owner.

Publishing and provenance do not settle business ownership

n8n community nodes are npm packages. The current n8n submission documentation requires nodes submitted for verification to be built with the n8n-node tool and published from a GitHub Actions workflow with a provenance statement, and from May 1, 2026 that provenance rule applies to all community nodes. The repository must also be public and MIT-licensed, and the npm package's repository URL and author must match the GitHub repository. The verification checklist lists every rule. The provenance record connects a package to a source repository, commit, and workflow. It helps users inspect how the package was built.

That technical connection answers one question: where did this package come from? It does not answer who owns the API integration, who pays for maintenance, who can transfer the repository, or who must respond when an API changes. n8n's verification review is also separate from the commercial agreement between an API owner and a build service. Read the current n8n community-node submission requirements before you describe a package as ready for review, and see the step-by-step submission guide for who does what in the Creator Portal.

Verification matters more from n8n 3.0. That release sets N8N_UNVERIFIED_PACKAGES_ENABLED to false by default, so self-hosted users can no longer install unverified community nodes from npm unless an admin turns the setting back on. Whoever owns the npm package and the Creator Portal submission therefore controls whether most users can install the node at all.

If you need the publishing mechanics, use NativeShip's npm provenance guide. Keep the provenance workflow and the ownership schedule next to each other in your project records. One proves a build path; the other records who controls the assets and responsibilities.

Ask what support includes after the first release

The first package is often the easy part. An API owner still has to handle changed endpoints, expired credentials, new required fields, n8n version changes, user questions, and release notes. A project can fail later because nobody agreed who does that work.

Define the following before the package reaches customers:

1. Support intake. Give users one place to report a failed operation and say who triages it.
2. API ownership. Name the team that decides whether a node change follows an API change or waits for a larger release.
3. Test access. State who supplies the test account, sample data, sandbox, and permission to run a request.
4. Release authority. Name who approves a version, tags the repository, runs the publish workflow, and writes the release note.
5. Security response. Record who handles a leaked credential, vulnerable dependency, or compromised publishing account.
6. Compatibility work. Decide who checks saved workflows, credentials, output fields, and breaking changes before a release.
7. End of service. Write the handover steps, deadline, files to export, account changes, and final support date.

The n8n node versioning guide explains why package versions and node versions answer different support questions. Use that technical distinction in the schedule. A package owner may publish a patch while the integration owner still needs to protect an older node version inside saved workflows.

What to confirm on the NativeShip offer

The NativeShip pricing page lists one-time plans: Developer at $149, where you generate and publish the package yourself, and Startup at $349, which adds more build credits and help with each platform's review. A pricing page lists features, though, not account ownership. Confirm in writing where the GitHub repository, npm package, source files, credentials, and test data will live, and who makes future maintenance decisions.

Before you pay or hand over an API specification, ask the current owner to confirm the terms that affect your project:

Question	Written answer you need
Where will the repository live?	Your organization, the provider's organization, or a new account created for the project
Who owns the npm name?	Your npm account, your organization scope, or another owner, with the exact package name
What do you receive?	Source, generated package, build files, workflow, README, screenshots, test records, and release history
Who can publish?	Named accounts or teams, their permission level, two-factor control, and recovery path
Who handles updates?	Included work, request process, limits, response expectations, and what costs extra
Can you take the project elsewhere?	Repository and package transfer steps, timing, data export, and support after handover
What happens to submitted data?	Storage location, retention period, deletion request, and access to API specifications or credentials

These are questions for the current agreement, not assumptions to fill with marketing copy. If an answer is missing, mark it as open and keep the node in planning until the owner resolves it. The existing SaaS integration decision guide can help you decide whether the customer and maintenance case justify the integration in the first place.

A small ownership schedule you can attach to the project

Use a short record that a product lead, developer, and provider can all read. Keep account IDs and recovery details in a password manager rather than inside a public repository.

API owner:
GitHub repository owner:
GitHub administrator(s):
npm package name and owner:
npm publisher(s):
Build workflow owner:
n8n Creator Portal submitter:
Support intake:
API-change decision owner:
Security incident owner:
Included maintenance:
Handover trigger and deadline:
Files and account access delivered at handover:
Data deletion or retention terms:

Have each responsible person confirm the entries before the first public release. Then review the schedule when a team member leaves, the repository moves, the npm scope changes, or the API adds a breaking version.

Red flags before you approve the release

Pause the release and get a written answer if any of these statements describe the project:

• The repository is in a personal account and no organization owner is named.
• You can download a package but cannot inspect or update the source.
• The npm package name is chosen for you, but the owner and transfer path are unclear.
• One person controls GitHub, npm, two-factor recovery, and the n8n submission with no backup.
• “Maintenance included” has no definition of what changes, how requests arrive, or when work ends.
• The node is called verified because it was published, even though n8n's review is still pending. (See how n8n community node verification works.)
• Credentials or API specifications are sent to a service without a retention and deletion answer.

Resolve the account and responsibility questions before you announce the node. A clear handover plan is part of shipping an integration that customers can depend on.