Webhook deployment fails with "Webhook Docker Image Name Not Found" after v0.25.10 update

[tolgamorf]

To Reproduce

1. Update Dokploy to v0.25.10
2. Trigger a deployment via webhook URL for any Docker-based application
3. Observe the error response

Current vs. Expected behavior

Expected Behavior

Webhook should trigger a deployment successfully, as it did in previous versions.

Actual Behavior

Webhook returns the following error:

{"message":"Webhook Docker Image Name Not Found"}

Provide environment information

- **Dokploy Version:** v0.25.10
- **Provider:** Docker
- **Number of affected apps:** 7

Which area(s) are affected? (Select all that apply)

Docker, Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

After updating to v0.25.10, all webhook URLs for deploying applications have stopped working. Previously, webhooks were functioning correctly for all my applications.

• GHCR was previously added to Docker Registry and authenticated
• Docker image field is configured with a valid image path (e.g., ghcr.io/username/app-name:latest)
• Only the Docker image input is filled (Registry URL, Username and Password are empty)
• Manual deployment via the "Deploy" button works correctly
• This issue affects all applications that were previously working with webhooks before the update

Will you send a PR to fix it?

No

[tolgamorf]

I also tried refreshing the webhook URLs, but the new URLs did not work either.

[juandl]

Same issue here

[hkhangus]

Same issue here

[drithh]

Yea, is there an alternative way to fix this, i got the same issue

[SR6Glory]

Same issue here

[drithh]

Temporary hack, instead of calling the webhook, you can trigger the deploy API manually. Copy the request as curl when you click deploy.

curl --location 'http://ip:3000/api/trpc/application.deploy?batch=1' \ --header 'Accept: */*' \ --header 'content-type: application/json' \ --header 'Cookie: better-auth.session_token=token' \ --data '{"0":{"json":{"applicationId":"applicationId"}}}'

You may optionally extend the session_token’s expires_at value, which i think typically lasts 3–7 days.

[seriaati]

Inspected the source code of Dokploy and made this, it mocks as a GitHub registry_package event Webhook and sends all the information needed by Dokploy: (Add as a step in your GitHub Actions workflow)

- name: Trigger deployment webhook
        env:
          COMMIT_MESSAGE: ${{ github.event.head_commit.message }}
          COMMIT_SHA: ${{ github.sha }}
          PACKAGE_URL: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
        run: |
          set -euo pipefail
          jq -n --arg id "$COMMIT_SHA" --arg msg "$COMMIT_MESSAGE" --arg url "$PACKAGE_URL" '{head_commit: {id: $id, message: $msg}, registry_package: {package_version: {package_url: $url}}}' > payload.json
          curl -sS --fail-with-body --retry 3 --retry-delay 2 --retry-connrefused \
            -X POST "${{ secrets.DEPLOYMENT_WEBHOOK_URL }}" \
            -H "x-github-event: registry_package" \
            -H "Content-Type: application/json" \
            --data-binary @payload.json \
            -w "\nHTTP %{http_code}\n"

[juandl]

You can generate an api key and use the api to execute a deploy, https://docs.dokploy.com/docs/api

[DieselNiu]

0.25.7 same issue

[Siumauricio]

Yes, we recently added support for ghcr packages. I think we need to add documentation for this. The change now is that you must use it in the webhooks section of your repository, paste the webhook URL, and select the registry packages event, and it should work (we need to add documentation for this similar to dockerhub).

The other option is to use the API directly and use the application.deploy endpoint and just pass it the applicationId.

[Arthurdw]

Yes, we recently added support for ghcr packages. I think we need to add documentation for this. The change now is that you must use it in the webhooks section of your repository, paste the webhook URL, and select the registry packages event, and it should work (we need to add documentation for this similar to dockerhub).

The other option is to use the API directly and use the application.deploy endpoint and just pass it the applicationId.

Does this mean there is no way to just have a simple endpoint to trigger a re-deploy if you are using your own registry?

[juandl]

Yes, we recently added support for ghcr packages. I think we need to add documentation for this. The change now is that you must use it in the webhooks section of your repository, paste the webhook URL, and select the registry packages event, and it should work (we need to add documentation for this similar to dockerhub).

The other option is to use the API directly and use the application.deploy endpoint and just pass it the applicationId.

This seems to be a break change that was not mentioned on any release.

[seriaati]

I would say that I'm not a huge fan of this change because GitHub's webhook doesn't have granular control, like only triggering for a specific branch, or triggering different ones for different branches. Our team had been triggering the webhook manually in GitHub CI and it had worked well so far, and this approach provided us with more granular control.

The new change also made it not possible to carry the commit message into the deployment description (as I'm aware, correct me if I'm wrong).

I haven't looked into the Dokploy API yet, but if we can specify a custom deployment message then I think we will just move over to that.

[juandl]

Yeah, we use webhook.. under the same concept "webhook", from another CI tool and slack bot, etc.

We did a bypass using the api, but is not that "okay" for us, because it contains an secret key.

[w95]

Same issue here

[tolgamorf]

In my case, I was building my app locally, pushing the image to ghcr, and then calling the webhook URL within the same script after everything was successful. It worked like a charm. But, since this webhook update, I had to change my script to make an API call to /api/application.deploy in order to deploy the app. The downside is, now I need to include the Dokploy API key and also the app ID in my .env variables.

By the way, accessing the app ID is a bit of a hassle; you need to fetch /api/project.all and then find the app ID manually from the JSON response. I am happy to hear if there is a better and easier way to get the app ID, maybe in the Dokploy UI?

[drithh]

From the application/service detail url, u can get the ID

http://ip/dashboard/project/-P1C6vobji3u4Dze7c0Kv/environment/env_prod_-P1C6vobji3u4Dze7c0Kv_1757640339.341349/services/application/Cm0DawyTQ40600yP3bEjq?tab=deployments

For example, this applicationId is Cm0DawyTQ40600yP3bEjq

[YMS-GBH]

Same issue, i use docker image on my gitlab registry and since the update i get "Webhook Docker Image Name Not Found"

[kurtulusmengukan]

Hi,

I solved the issue: You need to send the Docker image you want to deploy in the JSON body of the webhook. Example:

curl -X POST "YOUR_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "x-github-event: registry_package" \
  -d '{"registry_package": {"package_version": {"package_url": "ORG/IMAGE_NAME:TAG"}}}'

package_url → the Docker image and tag you want to deploy
This way, the webhook can detect the image and the deployment succeeds ✅

When successful, the webhook responds with:

{
  "message": "Application deployed successfully"
}

[thanhlmm]

I don't think this change make any sense. We should make it stateless like what previous version and GH CI interface as well

[outluch]

Agree. It is more logical to work like a button in ui: deploy. If we need to change image it is some other functionality. And probably it is already possible to do with api

[andylee20014]

same issue, hope fix it next update

[YMS-GBH]

Hi,

I solved the issue: You need to send the Docker image you want to deploy in the JSON body of the webhook. Example:

curl -X POST "YOUR_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "x-github-event: registry_package" \
  -d '{"registry_package": {"package_version": {"package_url": "ORG/IMAGE_NAME:TAG"}}}'

package_url → the Docker image and tag you want to deploy This way, the webhook can detect the image and the deployment succeeds ✅

When successful, the webhook responds with:

{
  "message": "Application deployed successfully"
}

maybe this need to be added to the docs. Thanks you for finding this

[sidharthv96]

Hi,

I solved the issue: You need to send the Docker image you want to deploy in the JSON body of the webhook. Example:

curl -X POST "YOUR_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "x-github-event: registry_package" \
  -d '{"registry_package": {"package_version": {"package_url": "ORG/IMAGE_NAME:TAG"}}}'

package_url → the Docker image and tag you want to deploy This way, the webhook can detect the image and the deployment succeeds ✅

When successful, the webhook responds with:

{
  "message": "Application deployed successfully"
}

This works after using the full ghcr.io link, not just ORG/IMAGE_NAME.

But I don't understand why this change was made, as now my configuration for an app is duplicated inside the dashboard and the CI job.

[Enmvnuel]

Hi,

I solved the issue: You need to send the Docker image you want to deploy in the JSON body of the webhook. Example:

curl -X POST "YOUR_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "x-github-event: registry_package" \
  -d '{"registry_package": {"package_version": {"package_url": "ORG/IMAGE_NAME:TAG"}}}'

package_url → the Docker image and tag you want to deploy This way, the webhook can detect the image and the deployment succeeds ✅

When successful, the webhook responds with:

{
  "message": "Application deployed successfully"
}

Thank you very much, brother. I spent hours and hours trying to fix it, thinking it was my instance or the AWS security groups.

[Siumauricio]

I see that this change has negatively impacted many people; Do you think we should reverse this change?

[serenity-ops]

man - this almost made me run mad - full blown argument with app users about not seeing changes, and this was the change???

[juandl]

I see that this change has negatively impacted many people; Do you think we should reverse this change?

Maybe a toggle or something to keep both ?

[toanbku]

Same issue

[pt-nolas]

I see that this change has negatively impacted many people; Do you think we should reverse this change?

that would be great