NimbusRoadmap
Where Nimbus is headed — vision, current focus, and long-term goals.
Vision
Nimbus exists to make running a Minecraft network simple, fast, and self-sufficient. One JAR, one config folder, no external dependencies beyond Java — whether you're running a 20-player lobby or a 2,000-player network across multiple machines.
The long-term goal: any operator, from solo hobbyist to large network team, can deploy and scale a Minecraft network in minutes — with modded support, multi-node clusters, and production-grade reliability out of the box.
Nimbus is not trying to be Kubernetes for Minecraft. It's trying to be the tool you reach for instead of Kubernetes — because for most Minecraft networks, the complexity of container orchestration is the problem, not the solution.
Guiding Principles
These shape what gets built and what gets cut:
- Zero external dependencies — No database server, no web server, no Docker daemon required to get started. SQLite ships embedded, the API server is built in, everything works from a single JAR
- Convention over configuration — Sensible defaults that work for 90% of use cases. Advanced operators can customize everything, but new users shouldn't need to
- Console-first — The CLI is the primary interface. The dashboard and REST API are complementary, not required
- Vanilla to modded — Paper lobbies and NeoForge modpacks are equally first-class. No feature should assume vanilla-only
- Operator autonomy — Self-hosted, no phone-home, no telemetry, no vendor lock-in. Your infrastructure, your data
Nimbus 1.0 is released. The REST API is now stable — breaking changes only in major versions. See API Stability for the full policy and Changelog for release history.
Now — Post-1.0 Focus
Nimbus 1.0 is stable. The focus now shifts from core hardening to ecosystem depth, operator ergonomics, and community growth. Priorities shift as the project evolves — expect this section to evolve between releases.
Operator-Facing Modules
The core engine, module framework, and first-party modules (Punishments, Resource Packs, Backups, Auth, Docker) are stable. The next layer is what networks reach for daily but currently glue together from third-party plugins:
| Goal | Why it matters |
|---|---|
| Staff tooling module | Reports, appeals, staff chat, infraction history — the operational layer above raw punishments. Every network needs it; nobody should build it from scratch |
| Analytics module | Player session stats, minigame leaderboards, network health trends. Nimbus already has the data pipeline (player events, metrics, audit log) — a stats module aggregates it into queryable form |
| Chat module | Cross-server chat channels, private messages, chat filtering. Complements the existing mute enforcement in the Punishments module |
Dashboard
| Goal | Why it matters |
|---|---|
| Dashboard → stable | Move from beta to a stable channel once operator workflows are covered end-to-end and edge cases are resolved |
| Per-user API tokens | Operators need scoped tokens for CI/CD and third-party integrations without exposing the master key |
| Auth event audit view | Dashboard page surfacing login events, session history, and failed attempts from the audit log |
Community & Ecosystem
| Goal | Why it matters |
|---|---|
| Published Maven artifact for Module API | nimbus-module-api on Maven Central so third-party module authors don't need a local JAR or GitHub Packages setup |
| Community module registry | Discovery page for community-built modules — README, version matrix, install command |
| Migration guide depth | CloudNet and SimpleCloud guides exist; expanding them with worked examples and gotchas from real migrations |
Next — Path to 2.0
Bigger architectural work that depends on community demand and real-world scale data. These are directions, not commitments.
Cluster-Aware Backups
Stream tar+zstd archives from agent nodes to the controller. Phase 1 (0.9.1) ships local-only; agent-node services are skipped with PARTIAL status. Design notes are parked in the GitHub issue tracker and will be revived when multi-node users surface the need.
Agent-Node Docker Support
The Docker module (0.10.0) is controller-only; agents still run bare processes. Needs a small cluster protocol tweak so agents can report container runtime info in heartbeats. Tracked alongside pre-built image support and Windows named-pipe sockets.
Performance Baselines
Quantified performance so operators can capacity-plan:
- Published benchmarks: startup time, scaling latency, API throughput, memory overhead per service
- Performance regression tests in CI
- Tuning guide for large networks (500+ services, 10+ nodes)
Later — Long-Term Goals
These are directions, not commitments. They'll be pursued if there's real demand and they align with the vision. Ordered roughly by expected impact.
Pluggable Template Storage (S3 / SFTP)
Template storage backends beyond the local filesystem. Becomes important for large clusters where copying templates between nodes is a bottleneck.
- S3, MinIO, or compatible object storage
- SFTP for remote file servers
- Hash-based cache invalidation (the foundation already exists in agent template sync)
Multi-Controller High Availability
Remove the controller as a single point of failure. This is the most architecturally complex item on the roadmap and will only be pursued if large networks need it.
- Leader election for placement decisions
- Shared state via database (already the case for most data)
- Automatic failover when the leader dies
- Agents reconnect to any available controller
Kubernetes Operator
For operators who do want Kubernetes — a native operator that manages Nimbus controllers and agents as Kubernetes resources. This is the furthest-out item and may never be built, since the opt-in Docker module (shipped in 0.10.0) covers the "I want containers" use case for most networks without layering on an orchestrator.
Completed Milestones
For detailed release notes, see the Changelog.
| Version | Date | Theme |
|---|---|---|
| v1.0.0 | April 24, 2026 | First stable release — API stability guarantee, strict_config default flipped to true, deprecated shims removed, all 1.0-readiness items resolved |
| v0.14.0 | April 24, 2026 | Cleanup — deprecated module API type aliases, ApiErrors compat facade, and nimbus.players permission node all removed |
| v0.13.0 | April 21, 2026 | API stabilization — strict TOML validation, cluster protocol version handshake, module API package reorganization, ApiError enum, SDK surface freeze, full permission registry |
| v0.12.0 | April 20, 2026 | Production hardening — cgroup v2 managed sandbox, startup crash diagnosis, five new Prometheus metrics, structured reload report, opt-in JSON logging, hard-fail on unknown server versions |
| v0.11.0 | April 19, 2026 | Auth module — dashboard gains real multi-user login (MC-account 6-digit code, magic link, WebAuthn/passkeys, TOTP 2FA + recovery codes) with nimbus.dashboard.* permission tree via the Perms module; API tokens keep working as implicit admin. Module-owned plugins co-locate next to their modules on disk. Dashboard rewrites the login screen as a wizard and ships a /profile section |
| v0.10.0 | April 17, 2026 | Docker module — opt-in container backend per group/dedicated, resource limits, daemon doctor check, dashboard module page + group toggle + service badge; new LocalServiceHandleFactory + ServiceMemorySource extension points |
| v0.9.1 | April 15, 2026 | Backup module — scheduled tar+zstd snapshots with GFS retention, native multi-threaded zstd, SHA-256 manifests, live TOML config editing, full dashboard editor |
| v0.9.0 | April 14, 2026 | Punishments + Resource Packs modules, runtime plugin deployment (templates fully user-owned), Velocity + backend enforcement plugins, scoped bans |
| v0.8.0 – v0.8.2 | April 12–13, 2026 | Production readiness audit — 94 findings resolved across security, stability, data integrity, performance; cluster TLS keystore restart bug |
| v0.7.0 – v0.7.3 | April 11–12, 2026 | Multi-node cluster — TLS setup wizard, placement pinning, state sync, failover, daemon mode |
| v0.6.0 – v0.6.2 | April 10, 2026 | Dedicated services — single-instance servers, unified memory reading, dashboard design system |
| v0.5.0 – v0.5.3 | April 9, 2026 | Modded support — client routing, mod list matching, NeoForwarding, protocol filtering |
| v0.4.0 – v0.4.7 | April 8–9, 2026 | Web dashboard (ALPHA) — Next.js UI, modpack import, CurseForge, server pack upload |
| v0.3.0 – v0.3.1 | April 7, 2026 | Competitive features — template stacking, warm pool, player module, Remote CLI |
| v0.2.0 – v0.2.1 | April 7, 2026 | Security & production readiness — migrations, audit logging, cluster TLS, PID persistence |
| v0.1.0 – v0.1.4 | April 1–5, 2026 | Foundation — core engine, 30+ commands, REST API, SDK, proxy, scaling, cluster, cross-version plugins |
How This Roadmap Works
This roadmap is organized by time horizon, not by version number:
- Now — Actively in progress or queued for the next release cycle
- Next — Required outcomes before Nimbus reaches 1.0 stability
- Later — Long-term directions that depend on community demand
Items move between sections as priorities shift. The Changelog tracks what actually shipped. If you want to influence what comes next, open an issue or join the discussion.