Operations

Operate SourbyCraft like a runtime with a boundary, not a vanilla server with a different banner. The commands report region state; shutdown has an order; the updater has a mode; and a backup is not a copy you hope is consistent.

Commands

See Observability for how to read the numbers and why a global average can hide a late region.

Logs

The server log lives under logs/. The useful operational signals are the startup identity, the region/scheduler messages, warnings from the compatibility bridge, and stall records. A long startup is not automatically a failure; a missing first tick is.

• Capture the full startup log before changing flags; a truncated log hides the first failure.
• Treat bridge warnings as migration work, not noise to suppress.
• Do not paste a log with player IPs, tokens, or world seeds into a public issue without redaction.

Updater

The updater supports off, notify, andauto modes. Notify is the default in the 48 release notes: the server is told about a release and does not install it until the operator chooses. Auto installs the release.

Shutdown

Shutdown has an order. Aurora halts region work before plugins disable, so a plugin’sonDisable cannot schedule work against a region that has already stopped. Build 48.4 refuses a synchronous chunk load from the shutdown thread with an owned message. An already loaded chunk still serves the write.

A stopped BRIDGE_IO lane reports that it is stopping and keeps its per-plugin rate limit. It does not emit a warning and stack trace per skipped task.

# Give the runtime time to halt regions and disable modules.
docker compose stop -t 90 sourbycraft

# Never use SIGKILL as a shutdown strategy.
# docker compose kill sourbycraft

# Inspect the last stop before restarting.
docker compose logs --tail=200 sourbycraft

Docker

• Use a Java 25 JRE image and pin its digest for repeatability.
• Mount the jar read-only; mount the server directory as a persistent volume.
• Publish only the Minecraft port. Do not expose RCON to the public internet.
• Set a stop grace period long enough for the world to save and modules to disable.
• Keep the previous known-good jar outside the container for rollback.

Backups

A world backup is only useful if you have restored it. Stop the server or use a filesystem snapshot that is consistent with the world write; copying live region files and calling it a backup is a gamble. Keep more than one generation and test the restore on a separate directory.

• Back up the world, config/, sourbycraft_config/, plugins/, and mods/.
• Record the release tag and checksum with the backup.
• Verify permissions and ownership after a restore; a readable world can still be the wrong copy.

Incident capture

When a tick stalls or a region refuses work, capture evidence before changing anything: the full log segment, /mspt, /perf output, the stall record, the region and owner thread, the plugin/mod list, and the exact release checksum.

Do not run a profiler indefinitely to “see what happens.” A bounded window is evidence; permanent profiling is another workload.