Dokku deployment fails with "[FATAL tini (7)] exec launcher failed" using Herokuish builder

I am running a Ruby on Rails application on Dokku v0.35.18 using the herokuish builder. Recently, my deployments have started failing. When I run dokku ps:restart my-app or deploy via git push, the process fails during the health checks.

The web container enters a restart loop, and the deployment logs show the following health check failures:

When I inspect the logs from the failed container, I see a recurring fatal error:

This indicates that the launcher binary, which the Herokuish buildpack process uses to start the application, is missing from the final Docker image.

Environment Details:

• Dokku Version: 0.35.18
• Docker Version: 28.2.2, build e6534b4
• Builder: herokuish
• Buildpack Image in use during failure: gliderlabs/herokuish:latest-24

My investigation of the deployment trace shows that Dokku correctly identifies the start command (bundle exec puma -C config/puma.rb) but sets the container entrypoint to launcher, which is standard for buildpack-based apps. The failure happens because this entrypoint is not found within the container's file system.

Why would the launcher binary be missing from an image built with the gliderlabs/herokuish:latest-24 buildpack, and what is the correct way to resolve this?

Answer

I found a solution that works by pinning the Herokuish buildpack to a specific version instead of relying on the latest-24 tag.

The Workaround

The issue was resolved by running the following command on the Dokku host:

Shell

dokku buildpacks:set-property --global gliderlabs/herokuish:v0.10.3-24

This command configures Dokku's buildpack plugin to use the specific v0.10.3-24 version of the Herokuish image for all builds, rather than the latest-24 tag. After setting this property, I rebuilt the application, and the deployment succeeded without the exec launcher failed error.

Explanation of the Root Cause

My hypothesis is that the Docker image tagged as gliderlabs/herokuish:latest-24 is either broken or incomplete.

1. Image Tagging Issue: The latest tag for any Docker image is mutable and can be updated by the maintainer at any time. It appears a recent update to the gliderlabs/herokuish:latest-24 image introduced a regression where the essential launcher binary was not included in the final image artifact.

2. Build vs. Runtime Failure: The failure is not in Dokku's runtime logic or the application code itself, but in the artifact being deployed. Dokku correctly followed the buildpack deployment procedure, which assumes the presence of the launcher. When the launcher was missing, the container could not start, leading to the health check failures.

3. The Solution: By pinning the buildpack to a specific, known-good version (v0.10.3-24), I ensured that a stable and complete version of the Herokuish builder was used. This version correctly includes the launcher binary, allowing the application container to start successfully.

Pinning dependencies, including buildpack versions, is a good practice to create more stable and predictable builds.