Second of the three publishes that carry the checksum annotations from
3.0.0+up2026.8.2.java8. Same chart content, only the published Java line
changes: appVersion moves to the dated tag 2026.8.2-java17 and the
minecraft.version default moves to 1.20.1, the line's matching Minecraft
version (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need
Java 21).
Refs #82.
smb.conf is rendered from samba.shares and mounted with subPath, so adding,
renaming or re-scoping a share rewrote the ConfigMap while the running smbd
kept its old share list: the pod template was unchanged, nothing restarted,
and the kubelet does not refresh subPath mounts. The share simply did not
exist for clients while the release looked healthy - the failure mode from #82.
The pod template now carries checksum/config over the rendered ConfigMap.
users.conf cannot be covered the same way: it comes from a 1Password-backed
Secret whose content Helm never sees, and the operator's auto-restart only
handles Deployments, not this StatefulSet. values.yaml now documents that
limitation and the manual rollout restart it requires.
Major bump: runtime behavior changes - a share change now costs a restart of
the samba pod, which drops open SMB sessions (share data lives on PVCs and is
unaffected).
The StatefulSet now carries two annotations over its two configuration
sources, so a change to either produces a new pod template and a controlled
restart:
checksum/config the rendered ConfigMap (init.sh) - complete, Helm sees
the whole content
checksum/secret-ref the rendered OnePasswordItem - the op:// item path only,
because the Secret's content is materialized by the
operator and is unknown to Helm at render time
Two separate annotations rather than one combined hash: they carry different
guarantees, and a single number would blur "covers everything" and "covers the
path but not the content" into one value that nobody can interpret in a
kubectl describe.
The operator's own operator.1password.io/auto-restart is deliberately NOT set:
it restarts Deployments only. Verified in the operator source (main, 9c3b1b9):
restartWorkloadsWithUpdatedSecrets lists nothing but appsv1.DeploymentList and
getPodTemplate has a single case for *appsv1.Deployment. On this StatefulSet
the annotation would be inert while suggesting the opposite, so the remaining
gap - a rotated value inside the vault item - is documented in values.yaml
instead.
First of the three stage-3-style publishes, so the java8 line goes first and
main ends up on java21. Only the published Java line differs between them:
appVersion 2026.8.2-java8 and the matching minecraft.version default 1.12.2.
Major bump: runtime behaviour changes. A configuration change now costs a full
server restart - 124 s measured for ftb-skies on Longhorn.
Refs #82.
The delegation nginx serves the .well-known documents from an nginx.conf that
is rendered from ingress.domain and mounted with subPath. Changing the domain
rewrote the ConfigMap but left the running pod untouched: the pod template was
unchanged, so nothing rolled, and the kubelet never refreshes a subPath mount.
The pod kept serving the old delegation while looking perfectly healthy - the
failure mode from #82.
The pod template now carries checksum/config over the rendered delegation
ConfigMap, so a changed nginx.conf rolls the deployment.
Also documents the limit that remains for homeserver.yaml: it comes from a
1Password-backed Secret, whose content Helm never sees, and the operator's own
auto-restart only ever covers Deployments - not this StatefulSet. That case
needs a manual rollout restart, which the values.yaml now says out loud.
Major bump: runtime behavior changes - a delegation config change now costs a
restart of the nginx pod (a few seconds, no persistent state).
The deployment now carries a checksum/config annotation over the rendered
ConfigMap, so a changed routing table produces a new pod template and a
controlled rollout.
Without it a mapping change was inert but looked successful: the file is
mounted with subPath (kubelet never refreshes those in a running container)
and mc-router reads ROUTES_CONFIG only at startup. That combination caused the
minecraft-server stage-3 outage - the ConfigMap pointed at the renamed
services, the running router kept proxying to the old ones, and the pod stayed
Ready throughout.
Major bump: runtime behaviour changes. A mapping change now costs a router
restart (~4.5 s in k3d, so roughly 17-19 s in the real cluster) during which
clients cannot connect. That restart is what makes the change take effect at
all.
Refs #82.
A changed ConfigMap did not restart any pod in this repo: no chart carries
a checksum/config annotation, so the pod template stays identical and the
running container keeps its old config. With subPath mounts (the usual form
here) the kubelet never refreshes the file either, so the change is silently
ineffective - see #82, where this caused a real outage while every bundle was
green and the pod Ready.
template-chart is the reference implementation, so it gets the annotation on
both pod templates (Deployment and StatefulSet), and the README style guide
gets a new binding section 9 covering the rule, the reason, and the limit for
1Password-backed Secrets.
Major bump: runtime behavior changes - a config change now costs a restart.
Last of the three stage-3 publishes, leaving main on the line of the only
running server. Same chart content as 2.0.0+up2026.8.2.java8 and .java17, only
the published Java line changes: appVersion moves to the dated tag
2026.8.2-java21 and the minecraft.version default moves to 1.21.1, the version
ftb-skies-2 actually runs (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17,
1.20.5+ need Java 21).
Second of the three stage-3 publishes. Same chart content as
2.0.0+up2026.8.2.java8, only the published Java line changes: appVersion moves
to the dated tag 2026.8.2-java17 and the minecraft.version default moves to
1.20.1, which is the line's matching Minecraft version (Java 8 runs up to
1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need Java 21).
Stage 3 of the Fleet migration. Two changes, both breaking, hence the major
bump from 1.0.0 to 2.0.0.
Dated image tags: appVersion moves from the rolling line tag "java8" to the
immutable upstream release tag "2026.8.2-java8". The rolling tags are rebuilt
continuously, so a pod restart could pull a different image than the previous
start without that being recorded anywhere. 2026.8.2 is the newest upstream
release (published 2026-08-23) and exists for all three Java lines.
Whitelist semantics: the chart now wires ENABLE_WHITELIST (and ENFORCE_WHITELIST)
in both positions, so minecraft.whitelist.enabled: false actually switches the
whitelist off. Previously the chart only emitted whitelist variables while
enabled was true and had no way to express "off" - and because server.properties
lives on the PVC, a release that had once written white-list=true kept it
forever. players stays guarded by enabled, since a non-empty WHITELIST enables
the whitelist in the image regardless of ENABLE_WHITELIST.
The default flips from enabled: true to enabled: false. Under the corrected
semantics the old default (enabled with an empty player list) would mean a
server nobody can join; false matches both the image and vanilla Minecraft.
PR C of three, and the last of the stage-2 sequence. Same chart as
1.0.0+upjava8 and 1.0.0+upjava17, published for the third Java line, so
main comes to rest on the line of the only server that is actually
running.
minecraft.version moves with it (1.20.1 -> 1.21.1): a Minecraft version
only runs on a matching JVM, and 1.20.5+ needs Java 21. This default now
equals what ftb-skies-2 sets in its own values file, so the install-test
boots the production version rather than an arbitrary Java-21-capable one.
The CI values deliberately do not override minecraft.version, so this
default is what the install-test exercises.
PR B of three. Same chart as 1.0.0+upjava8, published for the second Java
line: appVersion selects the image tag, so the JVM is fixed per published
chart version.
minecraft.version moves with it (1.12.2 -> 1.20.1), because a Minecraft
version only runs on a matching JVM: Java 8 goes up to 1.16.5, 1.18-1.20.4
need Java 17. Since 1.0.0 this default is no longer overridden in the CI
values, so the install-test boots exactly this version and a mismatched
default would fail CI instead of passing on a CI-only override.
Stage 2 of the Fleet migration for minecraft-server. Major bump: runtime
behaviour changes (probes, hardening) and the values interface breaks
(resource renames, strict schema).
Two real bugs first:
- The container declared port 35565 while the Service targeted 25565. It
only worked because targetPort was numeric. Both are now server.port
(25565) and the Service targets the named port.
- The download-serverpack init container was guarded by the map
.Values.curseforgeServerpack instead of .enabled, so it rendered for
every release and silently no-opped on an empty wget URL.
Conventions:
- Resources renamed to <release>-<chart>-<kind>, templates to
<app>.<kind>.yaml. The PVC deliberately keeps its historical name -
renaming it would provision a new, empty volume and orphan the worlds.
- Probes (liveness/readiness/startup) via the image's own mc-health, so
Ready means the server answers a server-list ping. Startup budget 20 min.
- Hardened, values-configurable security contexts: non-root uid 1000,
read-only root filesystem with an emptyDir at /tmp, all caps dropped.
- Resources from values with the limitFactor helper; an unset memory
request is derived from the JVM heap so the two cannot drift apart.
- Additive env block rendered through tpl, pinned init image, storage
class as a value, RCON wiring only when actually enabled.
- curseforge/ftb/curseforgeServerpack are now mutually exclusive.
- minecraft.version is pinned to the Java line instead of LATEST.
- The mc-router auto-discovery annotation is gone; the service type it
implicitly switched is now the explicit value server.service.type.
Schema pilot (#68): values.schema.json with additionalProperties false on
every chart-owned level, rejecting all three known dead keys.
Last of the three Java-line publishes; main comes to rest on java21, the line
of the only running server, and the registry holds all three tags.
Only the two version lines in Chart.yaml change. Because the source chart in
cluster-config is itself on java21, this final state renders byte-identical to
it for mc-ftb-skies-2 with its real values file - the published end state is
exactly what cluster-config runs today.
The CI install values move along with the appVersion, as in the java17 PR:
the JVM is fixed per published chart version and no single Minecraft version
boots on all three lines. Since the chart has no probes, a version the JVM
cannot load would crash after the rollout returned and still leave a green
install-test behind. minecraft.version therefore moves 1.20.1 -> 1.21.1, which
is also what ftb-skies-2 sets in its real values file, so CI exercises the
production version. ci/ is outside the chart directory and is neither packaged
nor published.
Second of the three Java-line publishes. Only the two version lines in
Chart.yaml change; the rendered output differs from the published java8 chart
in exactly one line, the image tag.
The CI install values move along with the appVersion: the image tag is the
Java line, so the JVM is fixed per published chart version and the Minecraft
version has to match it (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17).
No single Minecraft version boots on all three lines, and because the chart
has no probes a version the JVM cannot load would still leave a green
install-test behind. minecraft.version therefore moves 1.12.2 -> 1.20.1.
ci/ is outside the chart directory and is neither packaged nor published.
Imports the chart from cluster-config functionally unchanged, wires it into
the publish/validate/install-test pipelines and publishes it as the first of
three Java lines (0.4.0+upjava8).
The only deviation from the source chart is the chart-global scaleDown flag
plus a server.replicas value, following the satisfactory pattern: two of the
three servers stand at 0 replicas in the cluster, which the chart could not
express, and Fleet would otherwise start them on reconcile. The default
(scaleDown: false) still renders replicas: 1, so the rendering of the running
server is unchanged - verified byte-identical against the three real values
files for all three Java lines.
Known deficiencies (hardening, probes, naming scheme, hardcoded values,
missing icon, the misleading mc-router auto-discovery annotations) are left
untouched on purpose and are scheduled for stage 2.
Chart 1.0.0+up1.25.1 -> 1.0.1+up1.46.4 (patch: plain app-version update,
no values-schema and no chart-side behavior change). appVersion is the
image tag; itzg/mc-router publishes Docker tags without the "v" prefix
that the git tags carry since 1.35.0, so "1.46.4" is correct.
Verified against the upstream sources at v1.46.4 rather than the release
titles alone:
- --api-binding and --port are unchanged, so the chart's args still
apply.
- The ROUTES_CONFIG env var and the routes config schema
({"default-server": ..., "mappings": {addr: "host:port"}}) are
byte-for-byte identical to 1.25.1. Confirmed in a cluster: both
mappings, including a per-mapping port override, are loaded.
- There is still no /health endpoint, so the probes keep using
GET /routes. The "Accept: application/json" matcher that made the
header mandatory in 1.25.1 was dropped in 1.32.2; the header is kept
because it is harmless and correct.
- The image moved from scratch to cgr.dev/chainguard/static in 1.46.0
and now declares USER 65532. The chart keeps pinning uid/gid 10000, so
the runtime identity does not change.
Only the values comments that the update made inaccurate are touched; no
value, default or template changes. The comments now also record that
every unmodelled mc-router flag is reachable through server.env, which
is why the new 1.26-1.46 options need no new chart values.
Stage 2 of the Fleet migration for minecraft-router: bring the chart up to the
repo style guidelines. Chart 0.1.1+up1.25.1 -> 1.0.0+up1.25.1 (major: resource
renames, mappings becomes required, probes and security hardening change the
runtime behavior; appVersion unchanged).
- Resources renamed to {{ .Release.Name }}-{{ .Chart.Name }}-<kind>, templates
to <chart>.<kind>.yaml; the deployment label now matches its own selector.
- mappings is required and must not be empty (the old default rendered
"<nil>": "<nil>:25565"); every entry needs domain and internalUrl.
- Ports come from values: server.port (router listen port, also passed as
--port), server.backendPort (default backend port, overridable per mapping),
server.apiPort (--api-binding, used by the probes). Defaults stay 25565 /
25565 / 8080, server.outwardPort keeps its 25565 default and comment.
- _helpers.tpl added (resources/limitFactor and replicas/scaleDown helpers),
resources come from values, no CPU limit.
- replicas value plus the chart-global scaleDown flag.
- Additive env block rendered through tpl (value / secretKeyRef /
configMapKeyRef).
- Values-configurable securityContext.pod / .container with hardened defaults:
non-root uid/gid 10000, readOnlyRootFilesystem, no privilege escalation, all
capabilities dropped.
- Liveness, readiness and startup probes on the mc-router API: GET /routes with
an "Accept: application/json" header (the API router matches on that header
and answers 404 without it).
- icon added to Chart.yaml.
- CI fixture supplies mappings; README chart table entry updated.
Takes the existing mc-router chart over from cluster-config as-is so the
deployment can move to Fleet without any change to the rolled-out state.
Convention alignment follows in stage 2, the app update in stage 3.
The only deviation from "unchanged": Chart.yaml carried name:
minecraft-server (copy-paste from the sister chart). The publish job pushes
by the glob <directory>-*.tgz while helm package names the archive after the
Chart.yaml name, so without this correction the push finds no file.
Version 0.1.1+up1.25.1 - chart semver stays at 0.1.1, the +up suffix is repo
policy and does not affect rendering.
Also wires up CI: publish workflow, change-app-version choice list,
install-test values (CI-only node-port override, since 25565 is outside the
k3d default range) and the README chart table.
README.md gains a comprehensive 'Chart style guidelines' section - the
binding end state of the conventions overhaul (#32, batches 0-4) for all
current and future charts: naming (incl. the PVC-name exception and the
StatefulSet migration pattern), versioning scheme and semver rules,
image pinning, the ingress standard (domain + clusterIssuer strictly
required without defaults, className default nginx, annotations merge,
TLS secret name, homeassistant exception), security hardening with
mandatory documentation of deviations, probes, the auto-limits scheme,
the secrets.<name>SecretRef convention, tpl-rendered env blocks,
scaling, and the icon/lint/CI-fixture/no-dependencies rules.
The Versioning section now points there and documents that app-version
updates go through PRs. CLAUDE.md's conventions section is aligned as a
compact summary referencing the README guide.
Per the maintainer decision (option a: ingress.clusterIssuer strictly
required in ALL charts) the two remaining defaults are removed as well:
- cyberchef: drop the letsencrypt default; bump raised from minor to
major (6.0.0+up11.4.0) as this is a breaking values change.
- urlaubsverwaltung: drop the letsencrypt-issuer default; major bump
to 6.0.0+up6.7.0.
- CI test-values for both charts now set clusterIssuer explicitly.
A repo-wide grep confirms no chart carries a clusterIssuer default
anymore.
- apache-tika, gotenberg, cyberchef, homeassistant, patchmon: additive env
value blocks rendered through tpl (value, secretKeyRef and configMapKeyRef
forms), following the template-chart/outline pattern; patchmon gets separate
blocks for the server container and the guacd sidecar.
- homeassistant: ingress.className now defaults to nginx; an empty className
omits ingressClassName from the rendered Ingress, so the flexible upstream
ingress style stays intact.
- outline, paperless-ngx: remove the ingress.clusterIssuer defaults
(letsencrypt / letsencrypt-issuer) - the value is now strictly required,
consistent with the repo-wide ingress standard; CI test-values set it
explicitly.
Chart bumps: apache-tika 7.2.0, gotenberg 4.2.0, cyberchef 5.2.0,
patchmon 5.2.0, homeassistant 4.2.0 (minor); outline 5.0.0,
paperless-ngx 10.0.0 (major).
Batch-3 major PR for paperless-ngx (issue #32):
- secrets.redisRef/databaseRef/paperlessRef -> redisSecretRef/
databaseSecretRef/paperlessSecretRef (consistent with the other
SecretRef values in the same block); CI fixtures updated
- TLS secret renamed to the standard tls-<release>-<chart>-ingress
(domain no longer part of the name)
- busybox init/cronjob image pinned via paperless.busybox.image
values, default bumped 1.28 -> 1.38.0
- probes values-configurable (defaults unchanged, incl. the 600s
startup budget); consume CronJob deliberately stays probe-less
- ingress standard: ingress.className (default nginx) and
ingress.annotations merge; domain/clusterIssuer stay required
- additive paperless.env block rendered through tpl (value,
secretKeyRef, configMapKeyRef forms)
- disabled scripts ConfigMap renamed to ...-configmap; PVC names kept
as documented naming-scheme exception (comments in the templates)
- chart 8.0.1+up3.0.5 -> 9.0.0+up3.0.5 (breaking values changes)
- Rename all resources from <chart>-<release>-uv-<kind> to the repo
standard <release>-<chart>-<kind> (deployment, service, ingress, both
OnePasswordItem secrets); drop the uv infix. No PVCs in this chart, so
no storage migration is needed.
- TLS secret renamed to the standard tls-<release>-<chart>-ingress
(was tls-<chart>-<release>-ingress).
- Probes lifted into values (urlaubsverwaltung.livenessProbe/
readinessProbe/startupProbe); defaults are exactly the previously
hardcoded, issue-#9-calibrated settings.
- Repo-standard flexible ingress: ingress.className (default nginx),
ingress.annotations merged with the cert-manager annotation,
ingress.enabled flag; domain/clusterIssuer stay required.
- Additive urlaubsverwaltung.env block rendered through tpl with
value/secretKeyRef/configMapKeyRef forms.
- CI fixtures updated to the new secret names.
Major bump 4.1.2+up6.7.0 -> 5.0.0+up6.7.0 (resource renames).
- Values-driven securityContext for the Synapse pod/container with hardened
defaults: runAsNonRoot as uid/gid 1000 (matching the image's previous gosu
drop target), readOnlyRootFilesystem, allowPrivilegeEscalation false, all
capabilities dropped; /tmp mounted as emptyDir. The now-ineffective UID/GID
env vars are removed (the securityContext controls the user).
- Naming scheme: delegation Deployment renamed to ...-delegation-nginx-deployment,
ConfigMap to ...-delegation-nginx-configmap (references and service selector
updated).
- matrix.configSecretRef moved to secrets.configSecretRef (repo standard).
- Probes for Synapse and the delegation nginx are values-configurable;
defaults are the previous hardcoded settings.
- Flexible ingress standard: ingress.className (default nginx) and
ingress.annotations merged with the cert-manager annotation.
- Additive matrix.env block rendered through tpl (value/secretKeyRef/
configMapKeyRef forms).
- CI fixtures: secret ref moved, seed job image synced to appVersion.
- Chart 4.2.1+upv1.159.0 -> 5.0.0+upv1.159.0 (major; app version unchanged).
Repo-standard flexible ingress (required clusterIssuer instead of the
hardcoded letsencrypt-issuer, domain moved from config.domain to
ingress.domain, className value, annotations merge, standard TLS secret
name), secrets.<name>SecretRef structure, core secret renamed to the
standard -secret name, additive tpl-rendered env block, documented PVC
naming exception. Major bump 4.1.2+up4.7.0 -> 5.0.0+up4.7.0.
All audit findings for the calibre-web-automated chart (#32) in one major
bump, 3.1.1+upv4.0.6 -> 4.0.0+upv4.0.6:
- Rename StatefulSet, Service, OnePasswordItem secret and Ingress from the
inverted <chart>-<release>-cwa-<kind> scheme to
<release>-<chart>-<kind>; spec.serviceName and all references follow.
Both PVCs deliberately keep their historical names (documented naming
exception; renaming would orphan the data).
- TLS secret renamed to the standard tls-<release>-<chart>-ingress.
- Ingress on the repo standard: ingress.className (default nginx),
ingress.annotations merged with the chart-managed annotations,
ingress.clusterIssuer now required (was silently defaulted to
"letsencrypt-issuer").
- Security hardening, values-configurable via securityContext.pod /
securityContext.container: allowPrivilegeEscalation false, all
capabilities dropped except the minimal set the s6-overlay init needs
(CHOWN, DAC_OVERRIDE, FOWNER, KILL, SETGID, SETUID). Documented
deviations: the image must start as root (s6 drops to PUID 1000) and
readOnlyRootFilesystem stays false (read-only mode disables PUID/PGID
remapping upstream and breaks the ImageMagick policy setup).
- Additive env value rendered through tpl (value / secretKeyRef /
configMapKeyRef forms).
- CI fixtures: secret renamed to the new scheme, clusterIssuer added to
test-values.
Part of #32.
jklein