Portainer silently ignores Docker Compose secrets when version is 3.9 or higher

Short answer

Treat this as a deployment-path problem rather than a Compose-spec rule. A top-level secrets: block only becomes a real Docker secret when the stack is deployed to a Swarm cluster through a path that ends in docker stack deploy. If Portainer handles the stack through a Compose CLI interpreter instead, the secrets key is never translated into Swarm secrets, and the UI has no dedicated warning for that. The reported “3.9 or higher” cutoff looks like Portainer-side version gating, not something the Compose file format itself defines. I cannot confirm the exact threshold or that it still exists in your release, so verify against your own instance.

What is confirmed vs. what is likely

Confirmed on the Docker side: secrets are a Swarm feature. On a standalone Docker Engine, a secrets: block cannot create anything, whatever the version: string says. Separately, docker compose v2 has its own secrets semantics — it mounts files under /run/secrets from local sources and does not create Swarm secrets.

Likely, and worth checking on your version: Portainer selects a Compose interpreter based on the declared version, and for 3.9+ it may route to one that does not support the secrets key. The omission is silent in the UI; any message lives in the Portainer server or agent container logs, and it may be absent entirely.

Verify in five minutes

1. Deploy the stack through Portainer as you normally do.
2. On a Swarm manager, list secrets:

   docker secret ls

3. Confirm the services exist and inspect one:

   docker stack services <stackname>
   docker service inspect <stackname>_<service> \
     --format '{{json .Spec.TaskTemplate.ContainerSpec.Secrets}}'

4. Search the logs for the ignored key:

   docker logs portainer 2>&1 | grep -i secret
   docker logs portainer_agent 2>&1 | grep -i secret

5. Control test with the same file, bypassing Portainer:

   docker stack deploy -c compose.yml mystack
   docker secret ls

If step 5 creates the secret and step 2 does not, the file is fine and Portainer's deploy path is the variable. If step 5 also creates nothing, the problem is the target (not a Swarm manager) or the file itself.

Can you make Portainer warn you?

There is no documented toggle that turns unsupported-Compose-feature checks into a blocking error in the UI. Practical substitutes: create secrets out of band and reference them as external, so a missing secret fails the deploy instead of being skipped; or deploy with docker stack deploy and use Portainer only for visibility.

secrets:
  db_password:
    external: true

One detail that changes the advice

Is the Portainer endpoint a Swarm cluster or a standalone Docker host? On standalone, no Compose version will ever create secrets, and the fix is file-based secrets via docker compose or an external secret manager. On Swarm, the fix is the deploy path above.

Because Portainer's handling here has changed across releases, treat this as a conservative draft and re-test after upgrading Portainer or its agent.