tiny

CLI Overview

There is no standalone tinysystems CLI. Two real command-line surfaces exist, with different jobs:

  1. The module binary — every module compiles into a single binary that embeds the SDK's CLI (github.com/tiny-systems/module/cli). This is what you use while developing and testing a module: it runs the module against a cluster and ships introspection tools.
  2. tiny — the local front door to the Tiny Systems runtime. This is what you use to install and operate the runtime and modules on your own cluster.

The Module Binary

Your cmd/main.go builds a cobra root command and calls cli.RegisterCommands(rootCmd). The resulting binary is also the container entrypoint (CMD ["/manager", "run"] in the Dockerfile).

<module-binary> [command] [flags]

Commands:
  run                     Run the module (connects to the cluster, serves components)
  tools components-info   List registered components; --json emits the discovery shape
  tools rbac-values       Print the operator-chart rbac values overlay from SetRequirements
  tools rbac-check        Report Kubernetes calls not covered by declared RBAC; --strict exits non-zero
  pre-install             Helm hook: validate the install namespace
  pre-delete              Helm hook: clean up before uninstall

run flags

FlagDefaultDescription
--name, -nmainModule name (required; usually the container image repo)
--version, -v—Module version (required; no leading v)
--namespacetinysystemsNamespace the module is installed in
--kubeconfig, -k~/.kube/configKubeconfig path (falls back to in-cluster config)
--grpc-server-bind-address, -g:0gRPC bind address (the operator chart sets :8483)
--metrics-bind-address, -m:0Metrics endpoint bind address
--health-probe-bind-address, -t:0Probe endpoint bind address

Environment variables the run command reads:

VariableEffect
OTLP_DSNEnables OpenTelemetry export (traces); unset = telemetry disabled
TINY_NATS_URLRoutes cross-module messages over NATS instead of gRPC
TINY_NATS_TRANSPORTcore (default) or jetstream (durable work-queue wire)

The tiny CLI

Install from the tiny releases; tiny upgrade self-updates after that.

tiny [command] [flags]

Commands:
  (none)     Start the dev server (MCP endpoint + editor)
  up         Provision the runtime (CRDs + NATS broker + OTEL collector + core modules)
  install    Install a module from the configured repos: tiny install <module>[@version]
  repo       Manage module repos: list, add, remove, update, index
  status     Show the runtime + installed modules on the target cluster
  edit       Open the web canvas (served by the dev server)
  upgrade    Update tiny itself to the latest release

Persistent flags: --context (kubeconfig context), --namespace/-n (default tinysystems), --yes/-y (skip the target confirmation), --project/-p, plus cluster install settings (--ingress-class, --domain, --storage-class, --cluster-issuer). Every mutating command shows the target context and namespace and asks for confirmation before touching the cluster.

Quick Start

Develop a module

# Scaffold from the template (see Module Scaffold), then:
cd my-module

# Run against your cluster from source
go run ./cmd run --name my-module --version 0.0.1 \
  --kubeconfig ~/.kube/config --namespace tinysystems

# Inspect what your binary registers
go run ./cmd tools components-info

Operate a cluster

tiny up                          # provision the runtime
tiny install http-module         # install a module from the configured repos
tiny status                      # what's running
tiny repo add myrepo https://example.com/index.yaml

There is no init, generate, build, deploy, or watch command, and no .tinysystems.yaml config file. Scaffolding is a GitHub template repo, builds are plain docker build, and deployment is the shared operator Helm chart driven by tiny install (or helm directly).

Next Steps