tiny

Publishing Solutions

A finished project — flows, nodes, dashboard pages, scenarios — can be published to the public solutions catalog with one command. Anyone can then install it into their own cluster, widgets and dashboards included.

tiny login                 # once
tiny publish -p my-agent   # ships the project named "my-agent"

The command packages everything under the project label in your cluster, uploads it to tinysystems.io, and prints the catalog URL. Published solutions go live immediately; you can unlist or delete them from your dashboard at any time.

Signing in

tiny login opens a browser page where you approve the device once. Tokens are stored in your user config dir (~/Library/Application Support/tiny/auth.json on macOS, ~/.config/tiny/auth.json on Linux, file mode 0600) and refresh automatically.

tiny login      # approve in browser
tiny whoami     # check who's signed in
tiny logout     # forget the session

If your account belongs to several workspaces, pick one at login:

tiny login --workspace my-team

Publishing

tiny publish -p <project> [--title "..."] [--description "..."] [--tags agent,k8s]
  • -p, --project — the project name in your cluster (see tiny MCP list_projects, or the editor sidebar).
  • --title — catalog title; defaults to the project name.
  • --description — short description shown on the solution card; defaults to the project description.
  • --tags — comma separated; tags drive catalog filtering.
  • --update <slug> — update an existing solution instead of creating a new entry: same URL, new content revision, previous revisions kept. Title, description and tags change only when their flags are passed, so copy edited in the dashboard survives.
  • --workspace — workspace slug, only needed when your account belongs to several.
  • --context / --namespace — kubeconfig context and namespace, same as the rest of the CLI.

Publishing is snapshot-based: the catalog entry reflects the project at the moment you ran the command. A plain republish creates a new solution entry; use --update <slug> to refresh an existing one in place.

CI and robots

Non-interactive environments use a developer key instead of a browser login:

TINY_API_KEY=<key> tiny publish -p my-agent
# or
tiny publish -p my-agent --key <key>

Mint keys in the dashboard under Setup → Developer keys. Resolution order: --key, then TINY_API_KEY, then the stored tiny login session.

What gets published

  • Flows — nodes, edges, port configurations, positions; rendered as interactive previews on the solution page.
  • Dashboard pages and widgets — installed alongside the flows.
  • Scenarios — verification scenarios ship with the solution, so installers can prove it works in their cluster.
  • Module references — the modules your nodes use are listed on the solution page; installers need them available in their own cluster.

Values supplied through secret widgets stay in your cluster — node configurations carry the reference, not the value. Anything typed directly into a node's configuration ships as-is, so keep credentials in secrets, not in config fields.