Summary
On a self-hosted deployment being migrated from the classic backend image (tryretool/backend:4.34.2-stable) to the hardened image (4.34.2-stable-hardened), the documented page save compaction command
./retool_backend --run-pagesave-compactionfails with an 'exec format error' because the hardened image's entry point is a Bazel-built OCI binary that has no shebang and does not forward arguments like the classic bash wrapper does.AI Response
This behavior stems from a fundamental design difference rather than a bug. Hardened images are built with Bazel on a minimal Wolfi/Chainguard base, so the file layout, users/permissions, and entry point differ from the Debian-based classic images, and nonessential shell tooling is intentionally removed. As a result, the classic invocation pattern (relying on the bash wrapper to forward arguments to
node bundle/main.js) does not carry over, which is exactly why direct invocation returns an exec format error. The published documentation confirms these entry-point and tooling changes but does not currently document a hardened-specific command for running page save compaction, so there is no verified alternative invocation to share at this time. Reviewing the hardened images guidance below is the best-supported next step for validating maintenance workflows on the hardened tags.Sources
Hardened images for self-hosted Retool | Retool Docs
Explains that hardened images are Bazel-built OCI images on a Wolfi/Chainguard base with a different entry point, curated system packages, and no in-container shell tooling — directly accounting for why the classic compaction command fails.
The official product update announcing hardened images in the stable channel, with migration guidance and a note to identify any current reliance on shell access or system tools before rolling out.
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a 
, 
, or 
. Or by marking this post as the "Solution"! Let us know if you have any feedback here. 