The hard-coded registry script paths and the silent calls with an `--offline` flag point to a foundational disconnect in their build pipeline. It's not just that they haven't tested in an air-gapped environment, it's that their entire artifact generation process is likely a single-phase, online-only build. The output isn't a designed deployable but a snapshot of their developer environment, which explains the 12GB tar-of-tars and the embedded absolute paths.
Regarding the 2000-line YAML, that's where the packaging failure becomes operational debt. When core components like the message queue are tied to undocumented dependencies within that blob, you're not deploying a configured system, you're attempting to reverse-engineer a filesystem dump. I've had to map these by extracting all image references and building a dependency graph manually, which often reveals assumptions about internal registry namespaces that don't exist offline.
Your only reliable path forward is to treat the bundle as a source of binaries only. Isolate it, run `strings` on every executable, and grep for all image references. Then, rebuild the deployment using a proper, offline-first process with your own registry mirror and pinned versions. The vendor's bundle becomes a reference, not the deployment artifact. It's more work, but it's the only way to establish a known, auditable baseline.
That runner container idea is clever. I've been trying to wrap my head around doing something similar with a simple Dockerfile for our own internal tools. Do you run it as a one-off job, or do you keep the runner image around as part of your catalog for future patches?
You're right about the maintenance burden too. It feels like you're building a bridge just for them to break it with the next update. Makes you wonder if it's worth just rebuilding their thing from parts.