What problem will this feature address?
Dokploy deploys mutable tags (e.g. :latest) and recreates containers with no image-authenticity check at admission. For security-sensitive production you want both:
- deploy a specific immutable
@sha256 digest, not a moving tag, and
- verify the image signature (cosign/sigstore) before it runs, failing closed on an unsigned/unverifiable image.
Today neither is possible from within Dokploy. The deploy runs docker compose up inside the dokploy container, which has no cosign, no docker buildx (for imagetools digest resolution), no access to host signing keys, and no registry credentials usable for verification. So operators must bolt on an out-of-band host script (resolve tag → digest, cosign verify, pin the compose to @sha256, then docker compose up) and keep Auto Deploy OFF, because a panel git-sync resets the checked-out compose back to :latest and silently reverts the pin. The net effect: the panel Deploy button becomes "deploy unverified :latest" — a supply-chain footgun (compounded by the known "compose redeploy does not pull" staleness).
Describe the solution you'd like
An opt-in, per-app secure admission step in Dokploy's deploy pipeline (Compose apps and Applications):
- Resolve each
image: tag → immutable @sha256 digest at deploy time and deploy by digest.
- Verify each digest's signature with cosign/sigstore before recreate. Configurable trust:
- keyed (a committed/configured public key), and/or
- keyless/OIDC identity (certificate-identity + issuer),
- with an option to skip the transparency log (
--insecure-ignore-tlog) for private/air-gapped registries that don't publish to a public Rekor.
- Fail closed: an unsigned or unverifiable image aborts the deploy (no fallback to the mutable tag).
- Surface the resolved digests + the verification result in the deploy log / UI.
Ideally a per-app toggle — e.g. "Pin to digest + verify signature" — with fields for the verification key/identity. Then the panel Deploy button itself becomes the secure path: no out-of-band script, and no need to disable Auto Deploy to protect a pin.
Describe alternatives you've considered
- Out-of-band on-host script (what we run today): resolve →
cosign verify (fail-closed) → pin the compose in the Dokploy checkout → docker compose up, executed by an operator over SSH, with Auto Deploy disabled so a panel/git-sync doesn't revert the pin. Works, but it bypasses the panel, requires cosign/buildx + keys + registry creds on the host (the dokploy container has none of them), and the panel Deploy button stays an "unverified :latest" footgun.
- Custom Command field → can't help: the command runs inside the
dokploy container, which lacks cosign/buildx, the host signing key, and registry creds.
pull_policy: always / pre-pull → ensures freshness but not authenticity, and doesn't pin to a digest.
Additional context
This is primarily for self-hosted / private-registry deployments that adopt the sigstore/cosign supply-chain model (both keyed and keyless are common; private setups often run without a public Rekor, hence the ignore-tlog option). Native support would let Dokploy be the single, auditable admission point instead of operators scripting around it and disabling Auto Deploy to keep a pin from being reverted.
Will you send a PR to implement it?
No
What problem will this feature address?
Dokploy deploys mutable tags (e.g.
:latest) and recreates containers with no image-authenticity check at admission. For security-sensitive production you want both:@sha256digest, not a moving tag, andToday neither is possible from within Dokploy. The deploy runs
docker compose upinside thedokploycontainer, which has nocosign, nodocker buildx(forimagetoolsdigest resolution), no access to host signing keys, and no registry credentials usable for verification. So operators must bolt on an out-of-band host script (resolve tag → digest,cosign verify, pin the compose to@sha256, thendocker compose up) and keep Auto Deploy OFF, because a panel git-sync resets the checked-out compose back to:latestand silently reverts the pin. The net effect: the panel Deploy button becomes "deploy unverified:latest" — a supply-chain footgun (compounded by the known "compose redeploy does notpull" staleness).Describe the solution you'd like
An opt-in, per-app secure admission step in Dokploy's deploy pipeline (Compose apps and Applications):
image:tag → immutable@sha256digest at deploy time and deploy by digest.--insecure-ignore-tlog) for private/air-gapped registries that don't publish to a public Rekor.Ideally a per-app toggle — e.g. "Pin to digest + verify signature" — with fields for the verification key/identity. Then the panel Deploy button itself becomes the secure path: no out-of-band script, and no need to disable Auto Deploy to protect a pin.
Describe alternatives you've considered
cosign verify(fail-closed) → pin the compose in the Dokploy checkout →docker compose up, executed by an operator over SSH, with Auto Deploy disabled so a panel/git-sync doesn't revert the pin. Works, but it bypasses the panel, requirescosign/buildx+ keys + registry creds on the host (thedokploycontainer has none of them), and the panel Deploy button stays an "unverified:latest" footgun.dokploycontainer, which lackscosign/buildx, the host signing key, and registry creds.pull_policy: always/ pre-pull → ensures freshness but not authenticity, and doesn't pin to a digest.Additional context
This is primarily for self-hosted / private-registry deployments that adopt the sigstore/cosign supply-chain model (both keyed and keyless are common; private setups often run without a public Rekor, hence the ignore-tlog option). Native support would let Dokploy be the single, auditable admission point instead of operators scripting around it and disabling Auto Deploy to keep a pin from being reverted.
Will you send a PR to implement it?
No