v1.4.3

Changed

• itzg/mc-proxy:2026.9.1 moved to itzg/mc-proxy:2026.9.2. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 2026.9.1 -> 2026.9.2

Verdict: SAFE TO APPLY — the notes only bump the internal mc-image-helper dependency, no config, port, or volume changes named.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• none. The only listed change is: "Update dependency itzg/mc-image-helper to v1.69.0" and "...to v1.69.1" — both internal helper-tool bumps inside the image, not a companion service (database/cache/search engine) that would need a separate pin.

Before applying

• Update the digest/tag pin in the compose file's x-images block (itzg/mc-proxy:2026.9.1@sha256:... → 2026.9.2@sha256:...), since that is the single source of truth for the version actually deployed.
• No data migration, no env changes, no manual steps beyond the routine pull/restart.

Notes read

• 2026.9.2 (2026-09-18) — the only release notes provided, covering the full 2026.9.1...2026.9.2 range via the linked compare. No UPGRADING/BREAKING_CHANGES/CHANGELOG section was included for this range.

v1.4.2

Changed

• itzg/mc-proxy:2026.9.0 moved to itzg/mc-proxy:2026.9.1. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 2026.9.0 -> 2026.9.1

Verdict: SAFE TO APPLY — the notes contain only internal dependency bumps (mc-image-helper, a build-time GitHub Action), no breaking changes, no variable changes, and no companion-service version is named.

Breaking changes

• none found in the notes

Variables

• none

Data and dependencies

• none. The only version references are Update dependency itzg/mc-image-helper to v1.67.2 and Update dependency itzg/mc-image-helper to v1.68.0 — an internal build helper bundled in the image, not a database/cache/search-engine companion service that would need a matching pin in the compose file.

Before applying

• None required beyond the normal git pull / redeploy flow this template is designed for. No config edit, backup, or manual migration is called for by these notes.

Notes read

• 2026.9.1 (2026-09-11), full changelog range 2026.9.0...2026.9.1 — this is the only version step in the range, so no earlier tags needed reading.

v1.4.1

Changed

• update.sh names any new required variable before it moves. An update can add a required variable; docker compose up used to stop on it after the checkout, with the tree already on the new tag. The script now lists the variables that appeared in .env.example since your version and refuses, before anything has moved, when a required one is not in your .env. Names only, never values.

Upgrading

git pull (or ./update.sh). Nothing running changes: this release adds or extends the update script and touches no image pin.

Full history in CHANGELOG.md.

v1.4.0

Added

• Per-image version overrides. Every pin in the x-images block is
  now ${<PREFIX>_IMAGE_TAG:-repo:${<PREFIX>_IMAGE_VERSION:-tag@sha256:digest}}.
  Set <PREFIX>_IMAGE_VERSION in .env to run a different version of one
  image while every other pin stays as tested (Compose pulls that tag
  without a digest), or <PREFIX>_IMAGE_TAG to replace the whole
  reference as before. A deployment that sets neither is unchanged. The
  freshness job, the Trivy matrix and the fleet digest automation resolve
  the nested default before reading a pin. Needs Docker Compose v2.5 or
  newer (2022): v2.0 to v2.4 leave the inner ${...} unexpanded and
  docker compose up fails with an invalid reference instead of
  deploying something unexpected.

Changed

• itzg/mc-proxy 2026.8.2 to 2026.9.0.

Upgrading

git pull (or ./update.sh). A deployment that sets no _IMAGE_VERSION or _IMAGE_TAG variable renders exactly the same image references as before, so docker compose up -d recreates nothing. Requires Docker Compose v2.5 or newer.

Full history in CHANGELOG.md.

v1.3.0

Security

• Container hardening. Every service runs with
  security_opt: no-new-privileges:true (no privilege escalation via
  setuid binaries even if a process escapes its initial capability
  set). Infrastructure containers (the reverse proxy, databases,
  caches, backups) drop every Linux capability and add back only what
  their entrypoints need (bind :80/:443, chown a data directory, drop to
  the service user). Application containers keep the default capability
  set: upstream images assume it, and a wrong guess there is a boot loop
  in production, not a hardening win. CI boots the stack under these
  settings on every push.

Upgrading

git pull and docker compose up -d (or ./update.sh). Containers are recreated once with the new security settings; data volumes are untouched.

Full history in CHANGELOG.md.

v1.2.0 — resource limits you can tune from .env

Added

Resource limits on every service, as .env-overridable defaults. Each service now carries memory and CPU limits plus reservations (<SERVICE>_MEMORY_LIMIT, _CPU_LIMIT, _MEMORY_RESERVATION, _CPU_RESERVATION; the knobs and their defaults are listed in .env.example). Set any of them in .env and the override survives every git pull.

The defaults are what CI boots the stack under, so they are known to be enough for a fresh install. Under real load, a service that is OOM-killed shows OOMKilled=true in docker inspect — raise its _MEMORY_LIMIT and recreate.

Upgrading

git pull and docker compose up -d (containers are recreated with the new limits). If you already run on a small host and a service gets killed, set a higher limit in .env before recreating.

Full details in CHANGELOG.md.

v1.1.0 — unattended updates with update.sh

Added

update.sh — unattended updates to the newest tagged release, and nothing else. A tag is cut only after CI has booted the pinned images and passed the smoke tests, so "update to the latest tag" means "update to a combination a machine has already run" — the guarantee a floating latest can never give.

• refuses to cross a major version on its own (--allow-major after you read the notes)
• refuses a checkout with local modifications (your customization belongs in .env, which updates never touch)
• --dry-run shows what would be applied

Put it on a timer for hands-off minor/patch updates:

17 5 * * *  /opt/minecraft-server-proxy-docker-compose/update.sh >> /var/log/minecraft-server-proxy-docker-compose-update.log 2>&1

It is deliberately a host-side script and not a container in the stack: an in-stack updater needs the Docker socket and turns "someone pushed to a repo" into "someone deployed to your machine" with no operator in the loop.

Full details in CHANGELOG.md.

v1.0.0 — working velocity.toml, pinned proxy image, CI verification

First semver release, and it fixes a config that was silently ignored: velocity.toml was mounted over the /config directory itself, which the itzg image does not read. Velocity booted with its defaults and listened on 25577 while the compose published 25565, so the proxy never answered on the advertised port. The file is now mounted as /config/velocity.toml, which the image copies into /server on startup, one mount that works on every OS (the old per-OS comment block is gone).