Skip to main content

Overview

Two companion packages to the core SDK:
  • @struktoai/mirage-server, a Fastify daemon that owns workspaces in-process and exposes them over HTTP (/v1/workspaces, /v1/jobs, …).
  • @struktoai/mirage-cli, a commander CLI that speaks to the daemon. Mirrors Python’s mirage CLI 1:1.
The CLI is stateless. Long-running state lives in the daemon; the CLI auto-spawns one on the first mirage workspace create if none is running.

Install

This pulls in @struktoai/mirage-server transitively (the CLI spawns the daemon from the server package’s installed bin/daemon.js).

Create a workspace

Write a YAML config:
Then:
The CLI:
  1. Validates the YAML + interpolates ${VAR} env references (fails fast if any are missing).
  2. Auto-spawns a daemon on 127.0.0.1:8765 if none is reachable.
  3. Sends POST /v1/workspaces and prints the returned detail as JSON.

Run commands in a workspace

Workspace lifecycle

Versioning

Each workspace has a git-backed history kept by the daemon (under ~/.mirage/repos/<id>; set MIRAGE_VERSION_ROOT to relocate). Same verbs and semantics as the Python CLI.

Sessions

Daemon lifecycle

Configuration

Precedence (highest first):
  1. MIRAGE_DAEMON_URL env var, e.g. http://127.0.0.1:9000.
  2. MIRAGE_TOKEN env var, bearer token passed as Authorization: Bearer <token>.
  3. ~/.mirage/config.toml [daemon] table, managed with mirage config list|get|set|unset (per key: env var > config.toml > default; mirage config list --resolved shows the effective values and origins):
    The daemon validates the table at startup and refuses to start on unknown keys or malformed TOML. The full key list and semantics match the Python CLI docs.

Python parity

The daemon speaks the same /v1/... protocol as Python’s mirage CLI. A Python CLI client can talk to a Node daemon and vice versa. The CLI subcommand tree matches Python’s mirage/cli/*.py file-for-file.

Where things live