Kanject CLI

View .md

The Kanject CLI coordinates three release jobs around normal .NET and cloud tools: deploy services, publish packages, and distribute desktop applications. Each path starts with a local proof and ends with an evidence-bearing production action.

The CLI does not replace dotnet, AWS tools, CloudFormation, or your CI provider. It coordinates them around a manifest, stage files, generated MSBuild wiring, lockfiles, and deployment ledgers so the loop becomes repeatable. Run bare kanject for a project-aware landing screen; kanject --help renders the complete tree.

bash 
kanject <root-command>kanject <provider> <provider-command>
Deploy services
new / init → test → aws deploy → deployment ledger, rollback, previews, and pipeline automation.
Publish packages
packages plan / verify → bump plan or a declared intent → packages release → candidate feed smoke → approved, journaled publication.
Distribute desktop apps
Archive/native artifact proof → edition × RID routes → candidate downloads → byte-identical promotion.

Choose the project root and release boundary

Run bare kanject where you intend to work. It reads that root’s manifest, default stage and package policy locally, shows every configured workflow, and reports invalid configuration with a non-zero exit. It does not discover nested services or contact AWS to choose a workflow.

  • Independent services: one manifest and release history per service root.
  • Shared Lambda stack: several entries in one manifest deploy and roll back together.
  • Coupled application: one SPA and one Lambda/ECS backend share a coordinated lifecycle.
  • Library or desktop repository: use its package-policy/product root; neither workflow requires a Lambda deployment.

Interactive init reviews files, wiring, migrations and cleanup before writing, with Back and Cancel choices. new reviews each enrollment separately and preserves generated sources when enrollment is skipped. Scripts retain explicit inputs and approval flags. Enable shell completion for command and option names.

Prerequisites

The .NET SDK is the one common requirement; the rest depend on which job you are doing. Installation checks each one and fixes the usual setup failures.

  • .NET 10 SDK — the CLI itself runs on .NET 8 or later, but its project templates need .NET 10
  • AWS CLI 2.x when using AWS-backed paths — used by Lambda operations and S3 desktop distribution, but not required merely to work on a package repository
  • git 2.x — required for cross-repo dependency resolution (add lib, sync, migrate)
  • Amazon.Lambda.Tools — required only for the Lambda deployment path; Docker too if a function is built as Native AOT
  • An AWS account you control for Lambda or S3 distribution — Kanject CLI deploys into your environment, not a managed host
  • For the paid Kanject libraries — licensed Core libraries and the BaaS modules that the instant-messaging and file-server templates build on: access to the private Kanject NuGet feed, from your administrator. The CLI and its templates install from public NuGet with no credentials
  • For desktop native installers: matching-OS build runners and the platform tools/signing identities your chosen formats require

Command shape

Root commands are provider-agnostic and work against the project tree. Provider-bound commands live under a provider key; today the production path is kanject aws ....

  • kanject new, init, doctor, update, install provider — create, check, and extend the CLI
  • kanject add, configure distribution, env, sync, test, migrate — daily project work
  • kanject aws … and kanject github … — provider operations for deploy, previews, pipelines, and distribution
Was this page helpful?