self-hosted local registry deployments can succeed without pushing the image, leading to No such image at runtime

[flowq-C]

Summary

On self-hosted local builds targeting a local registry like localhost:5000, deployments can be marked as successful while the runner later fails with No such image, because the built image was never pushed to the registry.

Environment

• Trigger.dev self-hosted
• Version: v4.4.3
• Local build flow
• Local registry image tags like localhost:5000/...

Expected behavior

If self-hosted local builds use a local registry image tag such as localhost:5000/..., the built image should still be pushed so supervisors/runners can pull it.

Actual behavior

The deployment can complete successfully, but the supervisor later fails to pull the image:

No such image: localhost:5000/...

In our case, older image tags existed, but the new deployment tag did not exist after a successful deploy.

Reproduction

1. Use self-hosted Trigger.dev v4.4.3 with a local registry tag like localhost:5000/...
2. Perform a local deploy
3. Deployment reports success
4. Trigger a run
5. Supervisor attempts to pull the deployment image and fails with 404 / no such image

What we found

In the local build code path, shouldPush() returns false by default for image tags starting with:

• localhost
• 127.0.0.1
• 0.0.0.0

That seems wrong for self-hosted local-registry setups, because the built image then never reaches the registry that supervisors/runners are expected to use.

Evidence

Relevant logic in buildImage.ts:

case undefined: {
  return imageTag.startsWith("localhost") ||
    imageTag.startsWith("127.0.0.1") ||
    imageTag.startsWith("0.0.0.0")
    ? false
    : true;
}

Observed runtime failure:

• deployment marked successful
• supervisor log: No such image: localhost:5000/...
• previous tags existed, new tag for the new deployment did not

Impact

Self-hosted local-registry deployments can appear successful but fail at runtime when the runner tries to pull the image.

Question

Should local-registry targets in self-hosted mode default to push=true, or is there another supported path that supervisors are expected to use here?

[flowq-C]

Additional validated detail from our live self-hosted repro:

This turned out to be slightly broader than only shouldPush() == false for localhost-style tags.

What we observed across the full path:

• shouldPush() skipping localhost-style tags was one real failure mode
• but even after forcing push, the buildx/buildkit container could not reliably use localhost:5000 as the effective registry target in a self-hosted local-registry setup
• in our setup we hit multiple follow-up failures depending on how the registry was addressed:
  • localhost:5000 -> connect refused from the buildkit container
  • builder-reachable host IP -> HTTPS/HTTP mismatch unless the registry is explicitly treated as insecure
  • builder-reachable host IP -> 401 Unauthorized until auth was available for that exact registry host

So the practical self-hosted bug surface is:

1. localhost-style registry tags should not default to push=false
2. the local build path also needs a supported way to address an HTTP local registry from the buildkit container
3. auth/config should be robust when the effective registry host differs from the original image tag

We validated this end-to-end on a real self-hosted stack and only got stable local deploys after fixing all three dimensions.

[flowq-C]

Full root cause + working patch for self-hosted local registry

Following up on PR #3260 which was closed by the vouch-gate bot.

After extensive debugging of our self-hosted v4.4.3 setup, the localhost registry problem has three independent layers. Fixing only one still breaks the deployment.

---

Layer 1: shouldPush() returns false for localhost-tagged images

The shouldPush() function in buildImage.ts explicitly returns false for tags starting with localhost, 127.0.0.1, or 0.0.0.0. For self-hosted setups using a local registry this silently skips the push step — the deployment appears to succeed but the supervisor later fails with No such image.

Fix: Force push = true unconditionally for local builds:

// In localBuildImage(), replace shouldPush() call:
const push = true; // was: const push = shouldPush(imageTag);

---

Layer 2: localhost:5000 IPv6 / connectivity issues inside BuildKit containers

Even after forcing push = true, the BuildKit worker containers resolve localhost:5000 differently from the host. On our setup this caused intermittent connection failures to the registry.

Fix: Rewrite localhost:5000 to the Docker bridge gateway IP in the output options:

const resolvedImageTag = imageTag.replace('localhost:5000/', '172.24.1.1:5000/');
outputOptions.push(`name=${resolvedImageTag}`);

---

Layer 3: Missing registry.insecure=true for HTTP local registries

Local registries at localhost:5000 or 172.24.x.x:5000 are HTTP-only. BuildKit defaults to HTTPS and fails the push if registry.insecure=true is not set.

Fix:

outputOptions.push('push=true');
if (imageTag?.includes(':5000/')) {
  outputOptions.push('registry.insecure=true');
}

---

Combined working result

With all three layers fixed, --local-build deployments on self-hosted v4 produce a proper image push and the supervisor can pull the image at runtime.

The PR #3260 addressed Layer 1. Layers 2 and 3 were discovered during subsequent validation when the push was re-enabled.

Happy to provide a revised PR that addresses all three layers if the vouch path can be resolved.