Why starskiff
A lightweight skiff to Starship's heavy vessel
starskiff is the lightweight counterpart to Starship: where Starship stands up multi-chain environments on Kubernetes, starskiff boots a single real chain node in seconds — for integration tests and CI. Not a mock; the actual node — run from a binary or a container image.
| Starship | starskiff | |
|---|---|---|
| Infra | Kubernetes + Helm + Docker | None — child process (binary or docker run) |
| Startup | 2–5 min | 3–5 sec |
| Dependencies | K8s cluster | A binary or Docker |
| State reset | Helm redeploy (minutes) | kill + restart (~3s) |
| Best for | Production simulation | Dev/test |
Design decisions
- No Pool/Server layer (unlike prool) — Cosmos nodes expose their own RPC/gRPC/API, so a proxy is unnecessary.
- No orchestration — a node runs as a plain child process, whether from a binary on
PATHor a container (docker run, still a child process). No Kubernetes, no scheduler. - Fresh state per run — each
start()creates a temporary home directory, initializes a new chain from genesis, andstop()deletes it. - SDK-version tolerant —
cosmosBasehandles genesis structure differences across Cosmos SDK versions (v0.47 vs v0.50+), and warns when a config key it expected to patch has drifted. - Extensible — any Cosmos SDK binary works via
cosmosBase/cosmosEvmBase.
Testing strategies
| Strategy | Isolation | Speed | Use case |
|---|---|---|---|
| Account isolation | Practical | Fast | Most tests — each test uses unique accounts |
| Suite-level instance | Full | ~5s setup | Tests that modify chain-wide state |
| Shared instance | None | Fastest | Read-only queries, smoke tests |
Recommended: fund multiple accounts in genesis, assign each test its own account(s). See Test Accounts.