Docker Compose: missing tls=true label when certificateType is "none" with HTTPS enabled

To Reproduce

When configuring a domain on a Docker Compose application with HTTPS enabled and certificateType set to None, Dokploy does not generate the tls=true Traefik label on the websecure router. This causes Traefik to not terminate TLS for that domain, resulting in a 404 for all HTTPS requests, even though the container is running correctly and the custom certificate is being properly used.

Upload a custom certificate in Settings → Certificates
Create a Docker Compose application
Add a domain with: HTTPS: ON / Certificate: None
Deploy the stack
Access the domain over HTTPS

Current vs. Expected behavior

The generated Docker Compose labels should include:

traefik.http.routers.<router-name>-websecure.tls=true

but the websecure router is generated without any TLS label

Compare this with certificateType: letsencrypt, which correctly generates:

- traefik.http.routers.<router-name>-websecure.tls.certresolver=letsencrypt

Workaround

Manually add the missing label directly in docker-compose.yml:

labels:
  - traefik.http.routers.<router-name>-websecure.tls=true

Provide environment information

Operating System:
  OS: Ubuntu 24.04.4 LTS
  Arch: arm64
Dokploy version: 0.28.6
VPS Provider: Hetzner

Which area(s) are affected? (Select all that apply)

Docker Compose

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

No response

Will you send a PR to fix it?

No

@luigigorlero

Hi @luigigorlero! I'm Dosu and I’m helping the dokploy team.

Thanks for the detailed report! I can confirm this is a bug in Dokploy's label generation.

The issue is in packages/server/src/utils/docker/domain.ts - when certificateType="none", the code doesn't add any TLS labels:

if (entrypoint === "websecure") {
    if (certificateType === "letsencrypt") {
        labels.push(`traefik.http.routers.${routerName}.tls.certresolver=letsencrypt`);
    } else if (certificateType === "custom" && customCertResolver) {
        labels.push(`traefik.http.routers.${routerName}.tls.certresolver=${customCertResolver}`);
    }
    // Missing: else if (certificateType === "none") { ... }
}

Interestingly, regular (non-compose) applications handle this case differently in packages/server/src/utils/traefik/domain.ts, though they set tls = undefined which isn't quite right either for the custom certificate use case.

The fix would be adding:

} else if (certificateType === "none") {
    labels.push(`traefik.http.routers.${routerName}.tls=true`);
}

This enables TLS without specifying a cert resolver, allowing Traefik to use the custom certificate you uploaded.

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.

This appears to be a high-severity issue. Do we have any forecast for when it will be fixed?

This appears to be a high-severity issue. Do we have any forecast for when it will be fixed?

Is it ? It’s a Traefik misconfiguration that is workaroundable with a patch to your compose.

fix(compose): add tls=true label for certificateType 'none' with HTTP…

fix(docker): add tls=true label when certificateType is 'none'

fix: scope tls fix to compose labels, leave traefik file config uncha…

fix: add tls=true label for domains when certificateType is none (#4018…

🚀 Release v0.29.5 (#4475)

🚀 Release v0.29.6 (#4514)

🚀 Release v0.29.8 (#4562)

chore(release): 0.37.0 [skip ci]

Navigation Menu

Repository navigation

Docker Compose: missing tls=true label when certificateType is "none" with HTTPS enabled #4018

To Reproduce

Current vs. Expected behavior

Workaround

Provide environment information

Which area(s) are affected? (Select all that apply)

Are you deploying the applications where Dokploy is installed or on a remote server?

Additional context

Will you send a PR to fix it?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Docker Compose: missing tls=true label when certificateType is "none" with HTTPS enabled #4018

Description

To Reproduce

Current vs. Expected behavior

Workaround

Provide environment information

Which area(s) are affected? (Select all that apply)

Are you deploying the applications where Dokploy is installed or on a remote server?

Additional context

Will you send a PR to fix it?

Activity

dosubot commented on Mar 17, 2026

djleonskennedy commented on Mar 27, 2026

luigigorlero commented on Mar 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions