Deploy custom image tag
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 37.4k
- Forks
- 3k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 73
Description
What problem will this feature address?
Usually in our deployment flow, we tend to build a Docker image on our Github Actions CI, to then push it into the Staging / Production servers, that will download the image and serve it in the containers directly, however, this is not possible with DokPloy to directly set it up, so we are "forced" to have in-server builds of the Dockerfiles, the problem with that is that we have 4 containers per environment that use the exact same image, which means that in each deployment we will have the same image built 4 times per environment (8 times in total, because we have 2 environments), while with the original workflow we could just build it one time and just pull it.
Describe the solution you'd like
Somehow allow the possibility to push the image tag that we want to deploy, this way it can just pull it for all the containers. Either support it with the webhook or the API call to do a new deployment, I wouldn't care really as long as we have a way of doing so.
Describe alternatives you've considered
So the workaround I did is to create a Custom Github Action that will update the Docker Provider on every app and deploying every one of those individually, this will cause the deployments to queue, and the first one in queue will download the image, while the others will use it locally as it's already downloaded by the first one.
This works fine, but I'm wondering if it would be best to have this logic internally. I'm willing to publish my Github Action publicly so it can be used by other users if needed, I don't have an issue with that, so I guess we could all use this workaround with Github
Additional context
For context, I used to use Caprover and they have their Github Actions in which you can configure the image you want to deploy, like so:
- name: Deploy Image to Staging CapRover
uses: caprover/deploy-from-github@v1.1.2
with:
server: "${{ vars.CAPROVER_SERVER }}"
app: "${{ vars.APP_NAME }}"
token: "${{ secrets.APP_TOKEN }}"
image: ${{ needs.build.outputs.image_url }} # Here
Also, for some more context on how I deal with the API, here's a little Postman Flow that I have for manual deployments, I use it for rollbacks mainly, because I would have to go through the applications one by one to do those changes:
Will you send a PR to implement it?
No, but I can publish my Github Action
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the existing webhook and API deployment entry points and how the Docker provider is configured. Compare them with the four-container-per-environment workflow described here, and define completion as accepting a requested image tag and reusing it across the deployment. The issue names no files or tests, so those must be located before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, github-actions, typescript
- Domain
- backend-api-design, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100