kmq installs or connects to KubeMQ through the existing container runtime, Helm and operator. It also manages messages through the server's management API. The broker remains a separate container or Kubernetes workload.

Install

curl -fsSL https://raw.githubusercontent.com/kubemq-io/kmq/main/install.sh -o install-kmq.sh
sh install-kmq.sh
kmq version

Invoke-WebRequest https://raw.githubusercontent.com/kubemq-io/kmq/main/install.ps1 -OutFile install-kmq.ps1
& ./install-kmq.ps1
kmq version

Use the published Windows x86-64 archive. The installer adds kmq to this PowerShell session and to your user PATH for new terminals. Select Linux-container mode in the local runtime; a Windows-native broker image is not supplied.

The installers select the latest published stable release and verify its archive checksum. To reproduce a specific installation, pass --version vX.Y.Z to the macOS/Linux installer or -Version vX.Y.Z to the Windows installer. For disconnected work, stage the matching executable, checksums and signature material on a connected machine. The client does not download a missing container runtime for you.

Evaluate locally

Start your Docker runtime, then run:

kmq onboard --goal evaluation --runtime docker --name kubemq --platform linux/amd64 --pull

Use --runtime podman to select Podman explicitly. The server image is Linux x86-64; on Apple Silicon, the selected runtime must support x86-64 emulation. The native kmq executable still matches your workstation architecture. The command records the runtime connection, resolved image and volume identity. Ports bind to loopback. It prints a nonsecret installation_id and a next action; runtime creation is not authentication or message verification.

To inspect before mutation, use kmq deploy plan --goal evaluation --runtime docker --name kubemq --platform linux/amd64 --pull --out PRIVATE_DIRECTORY/plan.json, inspect that file, then kmq deploy apply --plan PRIVATE_DIRECTORY/plan.json. Use a directory private to your operating-system user. Windows file access-control lists must exclude other users; do not substitute a shared temporary directory.

Authenticate and verify

Use the identifier printed by the deployment command:

kmq auth setup --installation INSTALLATION_ID --username admin

kmq deploy verify --installation INSTALLATION_ID

kmq status

kmq queue send onboarding-check '{"id":1}'

kmq queue receive onboarding-check

Setup prompts locally for the password and saves a dedicated service credential in protected storage. An already configured installation uses kmq auth login --installation INSTALLATION_ID --username admin. Do not put passwords, email codes or service keys in command arguments, shell history or agent chat. A remote management endpoint requires HTTPS and certificate verification; pass --ca-file for your private authority.

Native credential storage is the default. If it is locked or unavailable, the command reports that fact and does not silently write plaintext. An explicit --credential-backend file selects protected file storage with ownership/permission checks. Keep the same selected backend when resuming.

Continue with a trial

Follow trial verification and claim to save the license. A local license reference identifies the saved material; it is not the secret itself. Continue the same installation and retained store through license replacement, then verify the new accepted identity. Do not create a second installation to extend an expired evaluation.

Resume, inspect and remove

kmq deploy apply --plan PRIVATE_DIRECTORY/plan.json
kmq deploy status --installation INSTALLATION_ID
kmq deploy restart --installation INSTALLATION_ID
kmq deploy remove --installation INSTALLATION_ID

Repeating apply resumes that saved operation. A timeout, interrupted terminal or lost response does not authorize creating a replacement. Inspect the reported partial state and use the same plan. Changed runtime identity, image, cluster version or ownership produces a conflict that requires a new inspection.

Removal retains persistent data. Kubernetes removal deletes the recorded cluster with server-side identity preconditions and retains the independent operator release. Saved customer credentials remain necessary when reconnecting retained server account data.

Connect to an existing installation

kmq deploy connect inspects and records an existing runtime using the same input options, without taking lifecycle ownership. For Kubernetes, pass --input with the inspected recipe. Authenticate using kmq auth login, or use kmq auth import --token-stdin with protected standard input to save an existing service credential. Connecting does not grant permission to recreate or delete the installation.

Kubernetes

Use the pinned local chart and JSON recipe described in the Kubernetes guide. Supply the namespace, runtime context, storage class, license Secret, TLS Secret and each server's management endpoint. The automatic one-server trial is insufficient. The operator release and cluster release must be independent.

Copy an agent prompt

Help me set up KubeMQ with the installed kmq. Run `kmq version`, `kmq skills get core` and `kmq schema -o json` first, then inspect the runtime and existing installations. Ask whether I want a fresh evaluation, a trial continuation or Kubernetes production. Save and show the target-bound plan before applying it. Preserve volumes, installation identity and existing accounts. I will enter email codes and passwords locally; never ask me to paste secrets into chat. Resume the same saved operation after uncertain outcomes. Finish only after authenticated management, intended license adoption on every server and a real message round trip succeed. Report any unverified production requirements separately.

See the command reference for messaging, schemas, output and exit codes. kmq schema and each command's --help describe the installed version.

Set up KubeMQ with kmq