Flitzdocs
CLI

flitz sdk

List, install, pin, locate, and remove Flitz SDK releases; the flitz.yaml pin.

The Flitz SDK is a self-contained Flutter SDK whose engine binaries are DDM-enabled and whose Dart SDK carries the dart2bytecode compiler that turns your app into bytecode the loader can run. It is not downloaded by hand: the flitz CLI is the only thing that fetches and places it, into a CLI-managed cache at ~/.cache/flitz/sdk/<tag>/, one directory per release tag.

A release tag has the shape <flutter-version>-flz.<N> — the upstream Flutter version, then Flitz's iteration counter at that version. flitz sdk releases lists what is published; latest always resolves to the newest.

CommandNetworkWhat it does
flitz sdk releasesyesList every published release, flagging the cached and pinned ones.
flitz sdk install [<tag>|latest]yesDownload into the cache without pinning. Idempotent. --force replaces a cached entry.
flitz sdk use [<tag>|latest]yesPin the tag for the current project and install it if absent. No argument reads the project's flitz.yaml.
flitz sdk listnoList cached SDKs and flag which one the current project pins.
flitz sdk pathnoPrint only where the pinned SDK lives — whether or not it is there yet.
flitz sdk remove <tag>noDelete a cached SDK.

releases, install, and use need a credential and an active license. list, path, and remove are purely local and never make a network call.

releases

flitz sdk releases
Available Flitz releases:
  <tag>  (installed, pinned)
  <tag>  (installed)
  <tag>

With --json: { "releases": [ { "tag", "installed", "pinned" } ] }.

install

flitz sdk install latest       # or an explicit <tag>
flitz sdk install              # the tag this project pins
flitz sdk install --force <tag>

Downloads the SDK for your host into the cache without touching the project pin. With no argument it installs the tag the project pins; an unpinned project with no argument is a usage error rather than a silent guess at latest.

Already cached? It says SDK <tag> already cached. and stops. --force re-downloads and replaces the cached tree, which is how you repair an entry that flitz status reports as missing a build tool.

install was asked for the download outright, so it never prompts.

use and flitz.yaml

cd /path/to/your/flutter/app
flitz sdk use latest           # or: flitz sdk use <tag>

sdk use resolves latest (or validates the explicit tag), then:

  1. Pins the tag by writing flitz.yaml at the project root — the current directory:

    flitz.yaml
    sdk: <tag>
  2. Offers the download with a default-yes prompt naming the tag and its approximate size. Accept, and the archive streams into the cache, is verified against its SHA-256, and is placed atomically. Decline, and the pin is still written: Not downloaded. Run 'flitz sdk install' when you are ready.

The pin is written before the download on purpose, so a declined, interrupted, or failed transfer still leaves the project pinned to the tag you chose and only the bytes outstanding. Non-interactively (no terminal to ask on), sdk use downloads without asking — a cold CI cache is exactly what it is run to warm.

Commit flitz.yaml. A fresh checkout on another machine reproduces the exact same SDK with an argument-less flitz sdk use, or with a single flitz publish --yes. The file may carry other keys of your own; the CLI reads only sdk: and preserves everything else when it rewrites the pin.

The pin is read from where you run flitz

Every command, including publish --app <dir>, reads flitz.yaml from the current working directory, not from the app directory.

Once a tag is cached, re-running sdk use for it does no network I/O and works fully offline. The archive ships a pre-populated bin/cache/, so flutter and dart inside it never reach out to download artifacts either.

list

flitz sdk list
<tag>  (pinned)
<tag>

Purely local. With --json: { "sdks": [ { "tag", "installed", "pinned" } ] }.

path

flitz sdk path
# /home/you/.cache/flitz/sdk/<tag>

Prints only the absolute cache path of the project's pinned SDK, on stdout, with no network call. It is a pure tag-to-path resolver, not a checker: it answers whether or not the SDK has been downloaded yet. That is what lets it sit in a shell profile that is evaluated before the SDK exists:

export PATH="$(flitz sdk path)/bin:$PATH"

Whether the tree is actually there is what flitz sdk list and flitz status report, and what publish enforces. With no pin in the current directory, sdk path prints nothing on stdout and exits 1.

--json adds the fact the bare form leaves out:

{ "tag": "<tag>", "path": "/home/you/.cache/flitz/sdk/<tag>", "installed": false }

Using the SDK as your flutter/dart

Publishing does not need the SDK on PATHflitz publish resolves it from the cache by itself. But if you want to point an editor, a shell, or the host app's own build at the SDK, sdk path is how:

export PATH="$(flitz sdk path)/bin:$PATH"
flutter --version

flutter --version inside a Flitz SDK reports the full release tag as the framework version. The -flz.<N> suffix is how you tell a Flitz SDK from a stock Flutter checkout at a glance. Your host app must be built against the same tag the bundle is built against — see Loader plugins → Compatibility.

remove

flitz sdk remove <tag>

Deletes ~/.cache/flitz/sdk/<tag>/. Reports <tag> not cached. and still exits 0 when there was nothing to delete.

Download integrity

  • Verified. Every archive is checked against the SHA-256 in the release manifest before it is placed. A mismatch names both digests, discards the partial, and leaves the cache untouched.
  • Resumable. The archive streams to a partial file in the cache's staging area; an interrupted install/use continues from where it stopped rather than re-fetching hundreds of megabytes. Ctrl-C deliberately keeps the partial.
  • Serialized. Two concurrent installs of the same tag wait on a lock instead of corrupting each other's tree.
  • Never damaged by failure. A failed or mismatched download never replaces, truncates, or deletes an already-installed SDK. --force is the only thing that replaces one.

Progress is reported as three phases — Downloading (with percentage, transferred-of-total, and rate), Verifying, and Extracting — so the largest transfer in the product is never silent.

On this page