Native deploy-time digest pinning + cosign/sigstore signature verification (fail-closed admission)

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:

1. deploy a specific immutable @sha256 digest, not a moving tag, and
2. 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

Start by tracing the deploy pipeline for Compose apps and Applications, especially where docker compose up recreates containers inside the dokploy container. Define the opt-in admission flow around digest resolution and cosign/sigstore verification, then verify that unsigned or unverifiable images abort deployment and that digests and verification results appear in deploy logs or the UI.