**Version:** v0.3.0 (API), Linux release install via `get.hypeman.sh`, ubuntu-latest (GitHub-hosted runner). Still present on `main` (`eed540f`: `cmd/api/config/config.go` defaults `Registry.Insecure: false`). ## Symptom With the builder image prepared and the base image mirrored, a build reaches its final step and fails: ``` #8 ERROR: failed to push 10.100.0.1:4973/builds/wimkkr6qogszrvqqsgv38qyi: failed to do request: Head "https://10.100.0.1:4973/v2/builds/…/blobs/sha256:…": http: server gave HTTP response to HTTPS client ``` ## Cause The built-in registry rides the API's own listener, which serves **plain HTTP**. But `registry.insecure` defaults to `false`, and that flag is what the build manager hands the builder VM (`lib/builds/manager.go` → `BuildConfig.RegistryInsecure`), where it decides BuildKit's scheme (`builder_agent/main.go`: `isHTTPS := !config.RegistryInsecure`). The example config has no `registry:` section at all, so a default install ships the contradiction: an HTTP registry that instructs its only client to speak HTTPS. Notably the API-side **mirror** pushes over HTTP regardless of the flag, which is why base-image mirroring works while the builder's push fails — two clients of the same registry with two TLS opinions. ## Workaround ```yaml # /etc/hypeman/config.yaml registry: insecure: true ``` ## Suggested fix Either derive the flag from what the listener actually is (the API knows whether it terminates TLS), or default `registry.insecure: true` to match the shipped listener, or at minimum document the required config line. Refusing to start a registry whose advertised scheme is known-wrong would also surface this at install time instead of at the first build's last step. Found while building [barista](https://github.com/mpuig/barista.sh) on hypeman — full journal evidence in [our findings doc, §10](https://github.com/mpuig/barista.sh/blob/main/docs/upstream-hypeman-findings.md).