Links
Tags
Creators
Details
2.0.0
Compatibility
Changes
Added
- Tested support lines for Velocity 3.5.1 build 615 on Java 21 and Velocity 4.1.0-SNAPSHOT build 16 on Java 25, using one Java 21 bytecode plugin JAR.
- Explicit, isolated
server_nametocontainer_namemappings with startup/reload preflight. - Real readiness strategies: Minecraft status protocol, Docker health, or either signal, all with bounded per-server deadlines.
- Shared lifecycle coordination so simultaneous players use one startup/readiness operation and stop/start/reload races have legal, deterministic outcomes.
- Bounded off-thread Docker execution, bounded plugin shutdown, cancellation, and saturated-worker handling without blocking Velocity event or command workers.
- Capped exponential retry for failed automatic stops while preserving activity until a confirmed stop.
- Atomic configuration reload: an invalid candidate is rejected completely and the previous immutable snapshot remains active.
- Permission nodes
autostopper.command.statusandautostopper.command.reload, plus the explicitautostopper.adminumbrella. - Typed operational state and sanitized
/autostopper statusdiagnostics with operator actions; raw Docker stderr remains in operator logs. - Pinned legacy/current Compose examples, packaged Velocity runtime tests, a real Docker/Compose/Minecraft release-candidate gate, reproducible Maven Wrapper builds, strict dependency/package checks, SpotBugs, JaCoCo, and deterministic CI gates.
- Installation, security, configuration, troubleshooting, Modrinth, and 1.1.2 migration documentation.
Changed
- Generated inactivity timeout and public documentation now agree on
300seconds. - New installations generate no monitored mappings instead of controlling example containers by default.
- Velocity's actual lowercase data path is documented as
plugins/autostopper/config.yml. - A running Docker container must pass configured readiness before waiting players are connected.
- Inactivity scans retain activity on Docker failures and stop only explicitly mapped, running, player-free servers.
- Managed containers are expected to exist in advance and use
restart: "no"; unmonitored hubs remain outside AutoStopper's lifecycle. - Docker socket/group access is explicitly documented as a privileged, host-root-equivalent trust boundary rather than ordinary non-root isolation.
- The canonical build is the checksummed Maven 3.9.16 Wrapper on JDK 21 through 25.
Removed
- The prototype's custom
/servercommand/interceptor. Velocity owns/serverand its permissions; AutoStopper now observes normal pre-connect events. - Unbounded fixed-delay startup behavior, blocking Docker work on platform workers, and partial or silent configuration fallback.
Migration
Read the complete 1.1.2 to 2.0.0 migration guide before replacing the artifact. The runtime matrix, lowercase data path, permissions, readiness policy, explicit mappings, pinned examples, and Docker security boundary all require operator review.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:PG4gqnzX:GK9jq7yW"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:PG4gqnzX:GK9jq7yW"
}

