v0.7.1 has no sysbox-deploy-k8s image, so the Kubernetes install path is stuck on v0.7.0

[SoftMemes]

v0.7.1 was tagged on 2026-07-31 and its .deb assets are attached to the GitHub release, but nothing in the Kubernetes install path points at it:

• sysbox-k8s-manifests/sysbox-install.yaml on master still reads image: registry.nestybox.com/nestybox/sysbox-deploy-k8s:v0.7.0-0 (line 66). Its last bump is 27cb713, "Update sysbox k8s manifest to use release v0.7.0", 2026-03-03.
• That file has historically been bumped once per release (v0.6.2, v0.6.3, v0.6.4, v0.6.5, v0.6.6, v0.7.0 each have a commit), so the absence of a v0.7.1 bump reads as "the image was never published" rather than a stale manifest.
• I can't confirm from outside whether a v0.7.1-0 tag exists: registry.nestybox.com/v2/ requires authentication and returns no WWW-Authenticate header, so there's no anonymous token flow to enumerate tags with.

This looks like the same publishing gap as #1029. That report used a malformed URL (releases/v0.7.0/ with the 0.7.1 filename), which makes it easy to dismiss, so for the record the correctly-formed URL 404s too while v0.7.0 is fine:

$ curl -sIL -o /dev/null -w '%{http_code}\n' https://downloads.nestybox.com/sysbox/releases/v0.7.1/sysbox-ce_0.7.1.linux_amd64.deb
404
$ curl -sIL -o /dev/null -w '%{http_code}\n' https://downloads.nestybox.com/sysbox/releases/v0.7.0/sysbox-ce_0.7.0-0.linux_amd64.deb
200

nestybox.com itself is also not resolving/connecting for me right now, which may be the same underlying cause.

Why this one stings for k8s users specifically

The two v0.7.1 fixes that matter most to a Kubernetes deployment are exactly the ones the k8s path can't reach:

• "Fix deadlock in sysbox-fs that could occur when many Docker containers are started/stopped concurrently inside a Sysbox container" (Hangs when running simultaneous docker containers inside a sysbox container #998)
• "Support Sysbox on Ubuntu 24.04 with kernel 6.8+ under containerd 2.x" (sysbox v0.7.0 doesn't work on Ubuntu 24.04 + kernel 6.8 + containerd v2 — install + mount failures #1013)

Nested-container churn and containerd 2.x are the normal condition on an EKS node pool, not an edge case.

We run sysbox 0.7.0 via sysbox-deploy-k8s:v0.7.0-0 on EKS Ubuntu 24.04, kernel 6.17.0-1019-aws, containerd 2.2.1, and hit what looks like the #998 family: one container's mount/umount2 seccomp-notify tracer stopped serving 48 seconds into its life, during a burst of ~27 inner pods starting at once. The node journal shows the same pair of lines quoted in #998 —

sysbox-fs[...]: level=warning msg="failed to receive fd(s) via SCM_RIGHTS: connection reset by peer"
sysbox-fs[...]: level=warning msg="Error during syscall mount processing on fd 21, pid 176040, req Id ..., cntr 0ca9241141
1e (error receiving fd via SCM_RIGHTS: connection reset by peer)"
sysbox-fs[...]: level=info msg="reaper: reaped pid 176689"

— after which that container is never mentioned again while five others on the same node keep logging normally, and every mount(2) inside it returns ENOSYS for the remaining hours of its life. Across nine nodes and up to 19 days of journals we see the bare SCM_RIGHTS warning 5 times; only the one that landed inside an in-flight mount request was fatal.

I'm not claiming v0.7.1 definitely fixes this variant — #1018 is still open and looks like the same fuse_flush family — but we can't find out, because there's no way to install v0.7.1 on Kubernetes.

Ask

Either publish nestybox/sysbox-deploy-k8s:v0.7.1-0 and bump sysbox-install.yaml, or say what the intended upgrade path is for k8s users on v0.7.0. If building the deploy image ourselves from sysbox-pkgr/k8s and mirroring it is the expected answer for now, that's fine — it would just be good to have it stated, since the manifest currently reads as though v0.7.0 is the latest release.