Kurtosis began as a developer‑focused tool to spin up reproducible, ephemeral environments. Over the last two years the community has stretched those limits, running long‑lived devnets and complex integration testbeds on top of Kurtosis. We propose an evolution that promotes Kurtosis from purely ephemeral to persistent devnets, and eventually, a production‑grade orchestration platform capable of hosting stateful, durable, multi‑tenant networks in the cloud.
The Bloctopus team, in collaboration with Kurtosis maintainers, is already experimenting with StatefulSets, advanced log exporting, dynamic persistent storage, and REST‑API stability fixes. We look forward to collaborating with the community to upstream future improvements into the mainline project. We invite the current maintainers, power‑users, and new contributors to collaborate on this roadmap so Kurtosis can serve both ephemeral and always‑on workloads.
| Package | Owner | Stars | Highlights |
|---|---|---|---|
| ethereum‑package | ethPandaOps | 327 | Multi‑client PoS testnet with MEV‑Boost and observability stack (github.com) |
| optimism‑package | ethPandaOps | 184 | Rolls out full L2 stack incl. op‑node, op‑geth, L1 deployment & Grafana dashboards (github.com) |
| kurtosis‑cdk | Polygon Labs | 60 | Modular Polygon CDK devnet (L1 + L2) with customizable components (github.com) |
| polkadot‑kurtosis‑package | HugoByte | 22 | Multiple parachain topologies, explorer & Grafana (github.com) |
| cosmos‑package | Bloctopus | 10 | Coreum & Cosmos‑Hub devnets, staking & IBC ready (github.com) |
| hyperlane‑package | Abacus Works | 10 | Multi‑domain bridge devnet with validators & relayers (github.com) |
| layerzero-package | Bloctopus | 6 | Full implementation of DVN and executor for any EVM network for multi-chain messaging |
These packages demonstrate Kurtosis’ power but also expose its limitations for persistent devnets: operators often hack around storage, logging and multi‑enclave needs
All the capabilities described below are being tested in our public fork (github.com/brianle1301/kurtosis). Feedback is welcome while we harden these features for upstream PRs.
| Area | Change | Status |
|---|---|---|
| Stateful workloads | Added StatefulSet support so any user service can opt‑in to ordered, sticky identity Pods. | PoC in fork; internal soak‑testing - will expose user‑config options (github.com) |
| Durable storage | Automatic PVC provisioning & auto‑scaling | PoC in fork; internal testing with hard‑coded 60 % → 2× rule - aiming for dynamic & customizable scaling (github.com) |
| Stable REST API | Fixed enclave‑scoped connectivity bug that blocked programmatic clients | Fixed in fork (github.com) |
| K8s‑native deploy | Decoupled Engine & workloads from CLI - direct kubectl apply now works |
Fixed in fork |
| **Restarts and | ||
| snapshotting** | Allow restarting of enclaves and exporting state for quicker start-up | WIP |
Current limitation: Today, the kurtosis engine and packages are launched primarily via the developer‑focused CLI. While perfect for local iteration, invoking the CLI from a jump‑box or scripting kurtosis run … in CI makes it hard to follow GitOps best‑practices and to integrate with platform‑operator tooling.
Introducing first‑class Helm charts solves this by letting operators manage Kurtosis like any other Kubernetes application through declarative manifests that can be version‑controlled, templated and promoted through environments.