Support preview deployments from pre-built Docker images (built via CI/CD)

[rouvenschandl]

What problem will this feature address?

Currently, preview deployments always trigger a build process on the production server, which can cause slowdowns and even downtime for other running services.

Describe the solution you'd like

It would be great if Dokploy supported deploying preview environments directly from a pre-built Docker image, which is built on CI/CD (e.g., GitHub Actions). Users could specify an image from a registry (such as DockerHub or GitHub Container Registry), and Dokploy would use that image for the preview deployment, skipping the build step on the production server entirely.

Describe alternatives you've considered

Do not use preview deployments.

Additional context

No response

Will you send a PR to implement it?

Maybe, need help

[paulrauchbach]

I've wanted this feature myself for a long time. I've looked into the codebase and I'm pretty sure I know what the required changes are. My current plan is:

• extend the application schema with a previewBuildRemote: boolean field. I also thought about infering this from application.sourceType, i.e. previewBuildRemote = application.sourceType === 'docker', though I think its a nice extra option for the user. This way the user can still choose to use local building for preview deployments and remote building for application builds.
• create an endpoint /api/deploy/preview/[refreshToken]. I think its necessary here to take in an additional parameter previewDockerImage. To validate the image is the one the user wants to deploy I thought about using application.dockerImage as a prefix to previewDockerImage, i.e. previewDockerImage would have to start with application.dockerImage for it to be accepted. If the endpoint is called the preview deployment is started by pulling the image, updating the GitHub issue, etc.

The application flow using this feature would be: User specifies docker as provider. User enables preview deployments with previewBuildRemote set to true. User creates pull_request. User builds the application (e.g. by using GitHub actions). User curls /api/deploy/preview/[refreshToken] with parameter previewDockerImage set to the just build image. Application pulls and runs the image.

Feel free to give feedback to my current plan. I'm still very new to the project and just began digging into the codebase, so excuse any obvious simplifications to my approach I might have missed. Also I've obviously omitted a few thinks like updating the frontend, etc. But I think these are the 'important' changes.

[rouvenschandl]

I've wanted this feature myself for a long time. I've looked into the codebase and I'm pretty sure I know what the required changes are. My current plan is:

* extend the `application` schema with a `previewBuildRemote: boolean` field. I also thought about infering this from `application.sourceType`, i.e. `previewBuildRemote = application.sourceType === 'docker'`, though I think its a nice extra option for the user. This way the user can still choose to use local building for preview deployments and remote building for application builds.

* create an endpoint `/api/deploy/preview/[refreshToken]`. I think its necessary here to take in an additional parameter `previewDockerImage`. To validate the image is the one the user wants to deploy I thought about using `application.dockerImage` as a prefix to `previewDockerImage`, i.e. `previewDockerImage` would have to start with `application.dockerImage` for it to be accepted. If the endpoint is called the preview deployment is started by pulling the image, updating the GitHub issue, etc.

The application flow using this feature would be: User specifies docker as provider. User enables preview deployments with previewBuildRemote set to true. User creates pull_request. User builds the application (e.g. by using GitHub actions). User curls /api/deploy/preview/[refreshToken] with parameter previewDockerImage set to the just build image. Application pulls and runs the image.

Feel free to give feedback to my current plan. I'm still very new to the project and just began digging into the codebase, so excuse any obvious simplifications to my approach I might have missed. Also I've obviously omitted a few thinks like updating the frontend, etc. But I think these are the 'important' changes.

Looks good at first glance! When I find the time, I’ll take a closer look. Have you already started implementing anything? @paulrauchbach