Introducing Akuapkg

Akuapkg is the open-source Rust tool for authoring cloud-native packages. Its standalone binary is akuapkg. The Akua platform CLI is a separate binary named akua, and it exposes the same package command surface under akua pkg.

That distinction matters because both tools meet in the same workflow. Package authors can use Akuapkg without signing in to the Akua platform. Platform users can stay inside the broader akua CLI while its embedded package dispatcher runs the same parser and command implementation.

akuapkg render --inputs inputs.yaml --out ./deploy
akua pkg render --inputs inputs.yaml --out ./deploy

Both commands render a Package. The first calls Akuapkg directly. The second enters the package namespace of the Akua platform CLI.

Why the package tool has its own name

The original project used akua for its package binary. The platform later needed that top-level command for workspaces, clusters, products, and other hosted resources. Keeping both tools under one executable name made documentation ambiguous: akua render could look like a platform operation even though rendering is local package work.

The renamed boundary is explicit:

• Akuapkg is the Rust package-authoring project.
• akuapkg is its standalone binary.
• akua is the Akua platform CLI.
• akua pkg is the platform CLI’s embedded Akuapkg namespace.

The package format still uses established filenames and import paths such as akua.toml, akua.lock, and import akua.ctx. Those are package-format contracts, not alternate CLI names.

One parser, two entry points

The distinction is a naming boundary, not a fork. Akuapkg’s Rust crate owns the command parser and dispatcher. The standalone executable enters that parser with akuapkg as its displayed binary name. An embedder can supply akua pkg instead, so nested help, errors, and usage examples match the command a platform user typed.

That shared implementation prevents the two forms from drifting into similar-looking commands with different flags. A package integration does not need to translate akua pkg render into a separate API or reproduce Akuapkg’s validation. It passes the package arguments to the same dispatcher and returns the same exit code.

The TypeScript SDK exposes the same idea for in-process consumers. Its package dispatcher accepts a binary name for help text, while the command behavior stays in Rust. The platform CLI can therefore own authentication and its wider resource hierarchy without taking ownership of package semantics.

What Akuapkg does

Akuapkg turns a typed KCL Package into manifests that Kubernetes reconcilers can consume. The current source includes commands for scaffolding, dependency management, rendering, checks, tests, formatting, inspection, OCI packaging, and verification. Run akuapkg --help against the version you are using for the authoritative list.

A typical local loop starts with these commands:

akuapkg init checkout
cd checkout
akuapkg check
akuapkg test
akuapkg render --inputs inputs.example.yaml --out ./deploy

Package dependencies live in akua.toml and resolve into akua.lock. KCL provides the typed authoring layer. The render path hosts supported engines inside Wasmtime rather than finding separate executables on $PATH.

Package authoring remains usable without a hosted Akua account. Commands such as check, test, render, and export operate on local package source. Hosted API support is an optional extension, not a dependency of the render path. That separation lets a repository use Akuapkg in local development or CI while choosing its own GitOps and cluster workflow.

The same workflow is available to a platform user without switching binaries:

akua pkg check
akua pkg test
akua pkg render --inputs inputs.example.yaml --out ./deploy

Embedded help also keeps the outer command name. akua pkg render --help displays usage for akua pkg render, while the standalone tool displays akuapkg render.

The outer CLI becomes useful when a workflow already includes platform operations. An agent or developer can keep one akua process for the platform and enter pkg for local package work. Someone building only packages can use akuapkg and avoid the hosted surface entirely. Documentation should show the entry point that matches its audience instead of treating the names as interchangeable.

Agent-facing behavior

Akuapkg detects supported agent environments and can select structured output without requiring every prompt to add the same flags. Explicit flags still win, so an integration can request JSON directly:

akuapkg render --json --inputs inputs.yaml --out ./deploy

The repository also ships task-oriented skills for package creation, inspection, testing, diff review, and publishing. These skills call akuapkg commands; a platform-specific skill can use the equivalent akua pkg form.

Release availability

Use the published Akuapkg releases to check which versions have downloadable artifacts. The Akuapkg source link retains the project’s published source coordinate and redirects to the current repository.

This article describes the command boundary present in the source tree. It does not promise that a tagged version is available through every distribution channel.

Current limits

Akuapkg remains alpha software. Command flags and package contracts can change before v1.0, and source can move ahead of published artifacts. Pin the version you test, read that version’s akuapkg --help, and confirm release assets exist before writing an installation procedure around them.

The akua pkg form also depends on a platform CLI build that embeds the package dispatcher. Use the standalone akuapkg binary when you only need package authoring or when the platform CLI version in your environment does not expose pkg yet.

The important boundary is stable enough to state plainly: use Akuapkg for package work, use akua for platform work, and use akua pkg when you want package work inside the platform CLI.