Skip to main content

Package Ninja overview

Package Ninja is a hosted SaaS workspace plus a local CLI enforcement layer. It authenticates developers in the browser, resolves package policy from the control plane, and blocks or allows package-manager commands before package-manager side effects happen. Use this guide when you need to install the CLI, understand the control model, or troubleshoot governed package-manager workflows.

The goal is simple: keep developer workflows fast while making package policy enforcement deterministic, auditable, and workspace-managed.

What does Package Ninja do?​

Package Ninja gives security, platform, and engineering teams one shared package-governance workflow:

  • developers keep using familiar package-manager commands
  • command routing can be previewed before execution with package-ninja plan --json
  • policy is checked before install, run, and publish side effects
  • audit visibility is captured in the hosted workspace

What does ecosystem coverage mean right now?​

Package Ninja has more than one support tier today:

  • First-class governed workflow: package-ninja restore, package-ninja add, package-ninja remove, package-ninja test, package-ninja run -- <native command>, and project shims share one governed path across the current production adapter set.
  • Preview coverage: package-ninja plan --json uses the same workflow planner as governed execution and reports selected root, ecosystems, native commands, risk class, freshness requirement, artifact inspection, and audit behavior without running package managers.
  • Runtime adapter coverage: the policy/runtime layer includes ecosystem adapters for npm-family, PyPI, Cargo, Go modules, NuGet, Maven/Gradle, and Composer.
  • Workflow convenience coverage: JavaScript still has the richest top-level convenience verbs overall, especially for publish. Governed fix now also supports direct safe-version remediation for PyPI uv/Poetry/Pipenv projects, Cargo, Go modules, NuGet, Composer, and narrow Maven/Gradle manifest patterns when a verified upgrade target exists; other ecosystems still use the universal native command runner when there is not yet a safe default top-level verb.
  • Registry intelligence coverage: the hosted search and package-risk surfaces already reach beyond npm into multiple additional registries.

Use the dedicated coverage page for the exact breakdown:

How is Package Ninja structured?​

  • Control plane (web + backend): authentication, workspace state, policy config, billing, and audit records.
  • Data plane (CLI runtime): executes package commands locally after policy preflight.
  • Policy timing: verdicts are resolved before package manager side effects.

Who should use Package Ninja?​

  • Security teams that need enforceable package policy without rewriting developer workflows.
  • Platform teams that need centralized governance and incident visibility.
  • Engineering orgs that need seat-based controls and predictable onboarding.

What does this guide cover?​

  • install and authenticate the CLI
  • workspace onboarding and first-run behavior
  • policy precedence and enforcement outcomes
  • team membership, roles, and session revocation
  • billing seats and checkout lifecycle
  • operational troubleshooting and recovery commands

What is the correct CLI package and command name?​

Package Ninja uses package-ninja as the canonical command name.

The canonical npm package is @packageninja/cli.

This guide documents only the canonical package and command names. If your machine is still on a legacy compatibility channel, upgrade to @packageninja/cli before following the examples here.

Where are the main product pages?​