File ownership
Ownership rules separate recipe files from local configuration and player data. Updates stop at conflicts instead of overwriting local drift.
managedeula.txt generatedserver.properties preserveworld/ dataCompose recipes, lock inputs and manage your servers in Docker.
Catalog installs handle these four steps for you.
luminesk.tomlDeclare sources, settings, ownership and the Docker runtime.
luminesk.lockResolve exact source hashes, recipe revisions and image digests.
.lumineskpkgBuild a deterministic package. Verify it before applying the plan.
Docker runtimeStart the locked image and wait for the declared readiness checks.
Sources, files, runtime and updates live in an explicit contract. Inspect it before it touches your instance.
Explore the formatExcerpt from the recipe authoring guide. The manifest is yours to review; Luminesk generates the lock.
[ownership]
preserve = ["settings.yml"]
data = [".tmp", "worlds", "plugins", "players", "behavior_packs", "resource_packs"]
[update]
strategy = "transactional"
backup = ["worlds", "plugins", "players", "behavior_packs", "resource_packs", "settings.yml"]
retain_backups = 3
rollback_on_failure = trueRead the complete recipe Run in your recipe source directory. Resolution binds mutable inputs to exact content and the current platform.
nesk validate --dir ./my-lumi-core --static
nesk lock --dir ./my-lumi-core
nesk cache verifyUnderstand the lockfile For an installed instance, inspect local changes and preview the update before applying it.
nesk diff --dir ./servers/example
nesk update --dir ./servers/example --dry-runExplore transactional updates Use structured results and explicit non-interactive behavior in your scripts. Missing required inputs return an error.
nesk status --dir ./servers/example --json --non-interactiveRead the CLI contract Ownership rules separate recipe files from local configuration and player data. Updates stop at conflicts instead of overwriting local drift.
managedeula.txt generatedserver.properties preserveworld/ dataPreview updates. Apply a transaction. If apply or readiness fails, restore the previous state when possible.
Failed check → rollback
See how recovery worksStable JSON, explicit inputs and non-interactive commands for repeatable automation.
nesk status --json --non-interactiveDiscover cores in the official catalog or compose a recipe of your own. Available versions and platforms depend on the recipe.
Choose a Java recipe and inspect its inputs, sources and platform requirements.
nesk search --edition javaBrowse catalog recipes Start with the Lumi walkthrough. Find other Bedrock cores in the catalog.
nesk search --edition bedrockTry the Lumi recipe * Linux/macOS bundles target AMD64 and ARM64; Windows targets AMD64. Each server recipe and Docker image must support your target platform.
SHA-256 checks for remote bytes. Immutable OCI image digests. Deterministic packages verified before use.
Verification modelExplicit download limits, revalidated redirects and safe archive paths keep external inputs within defined boundaries.
Source guaranteesDocker runs argument arrays with a read-only root by default. Recipes declare mounts, ports and resource limits.
Runtime boundaryReview release checksums, SBOM and build provenance in GitHub Releases. Transaction rollback complements independent world backups.
Install nesk, choose a recipe, review the plan. Then bring your world online.
Docker Engine or Docker Desktop is required for servers. Python 3.13+ is required only for Python tool installs. Windows AMD64 uses Linux containers.
Full installation guidecurl -fsSL https://nesk.farin.cc/sh | sh -s -- --yesirm https://nesk.farin.cc/ps1 | iexThe installer verifies the binary’s SHA-256 before installing. Review the Unix or PowerShell script before running it. Installer approval does not accept the Minecraft EULA.
With uv and Python 3.13+ installed:
uv tool install luminesk-cliKeep using the same installation method for upgrades.
Includes Python. Choose the target machine, verify SHA256SUMS, then extract the complete ZIP.