starred/godoxy-yusing
1
0
Fork 0
mirror of https://github.com/yusing/godoxy.git synced 2026-01-11 14:20:32 +01:00
Code Issues 18 Packages Projects Releases 10 Wiki Activity

Feature request: Support Docker provider over TLS (HTTPS / mTLS) #125

New Issue
Open
opened 2025-12-29 14:25:24 +01:00 by adam · 11 comments
adam commented 2025-12-29 14:25:24 +01:00
Owner
Copy Link

Originally created by @henryxrl on GitHub (Dec 18, 2025).

Hi, first of all, thank you for GoDoxy — it’s a very well-designed project and the agent-based model makes a lot of sense for multi-host environments.

I’d like to request (or at least discuss) support for connecting the Docker provider over TLS (HTTPS / mTLS).

Use case

In my homelab / internal infrastructure, I already expose the Docker API securely using mTLS, for example:

https://host:63377

This is done via a Docker socket proxy + reverse proxy (Caddy), and is already used by other tooling in my stack.

From a security and operational standpoint:

  • The Docker socket is never exposed in plaintext
  • Access is strictly controlled via client certificates
  • This setup is already battle-tested in my environment

However, when using GoDoxy’s Docker provider, the connection appears to assume plain HTTP only. When pointing it to an HTTPS endpoint, GoDoxy sends a plain HTTP request, resulting in:

Client sent an HTTP request to an HTTPS server

This makes it impossible to reuse an existing TLS-secured Docker API endpoint.

Existing implementations

Several popular tools already support Docker API over TLS, including:

For example, Homepage supports configurations like:

my-docker:
  host: dockerproxy
  port: 443
  protocol: https

my-remote-docker:
  host: 192.168.0.101
  port: 2375
  tls:
    keyFile: tls/key.pem
    caFile: tls/ca.pem
    certFile: tls/cert.pem

This makes it possible to integrate securely with remote Docker hosts without requiring an agent on every machine.

What I’m asking for

Support for Docker provider over TLS, ideally including:

  • https:// Docker API endpoints
  • Optional mTLS (client cert / key)
  • Standard TLS options (CA, cert, key, insecure_skip_verify, etc.)

For example:

providers:
  docker:
    my-remote-host:
      host: 192.168.0.101
      port: 63377
      protocol: https
      tls:
        keyFile: tls/key.pem
        caFile: tls/ca.pem
        certFile: tls/cert.pem

Notes / expectations

I fully understand that:

  • The agent-based model is the recommended and safest approach
  • This feature is not strictly required if agents are acceptable

That said, TLS support for the Docker provider would be very valuable for:

  • Existing infrastructures that already expose Docker API securely
  • Agent-less or low-footprint setups
  • Advanced homelab / internal environments with strong network controls

If this is intentionally out of scope, I’d appreciate clarification on whether TLS support is fundamentally incompatible with the current design.

Thanks again for the project and for taking the time to consider this.

Originally created by @henryxrl on GitHub (Dec 18, 2025). Hi, first of all, thank you for GoDoxy — it’s a very well-designed project and the agent-based model makes a lot of sense for multi-host environments. I’d like to request (or at least discuss) support for **connecting the Docker provider over TLS (HTTPS / mTLS)**. --- ### Use case In my homelab / internal infrastructure, I already expose the Docker API securely using mTLS, for example: ```text https://host:63377 ``` This is done via a Docker socket proxy + reverse proxy (Caddy), and is already used by other tooling in my stack. From a security and operational standpoint: - The Docker socket is never exposed in plaintext - Access is strictly controlled via client certificates - This setup is already battle-tested in my environment However, when using GoDoxy’s Docker provider, the connection appears to assume plain HTTP only. When pointing it to an HTTPS endpoint, GoDoxy sends a plain HTTP request, resulting in: ```text Client sent an HTTP request to an HTTPS server ``` This makes it impossible to reuse an existing TLS-secured Docker API endpoint. --- ### Existing implementations Several popular tools already support Docker API over TLS, including: - Homepage https://gethomepage.dev/configs/docker/#using-docker-socket-proxy - Dozzle https://dozzle.dev/guide/remote-hosts - DPanel https://dpanel.cc/manual/system-env-tcp For example, Homepage supports configurations like: ```yaml my-docker: host: dockerproxy port: 443 protocol: https my-remote-docker: host: 192.168.0.101 port: 2375 tls: keyFile: tls/key.pem caFile: tls/ca.pem certFile: tls/cert.pem ``` This makes it possible to integrate securely with remote Docker hosts without requiring an agent on every machine. ### What I’m asking for Support for **Docker provider over TLS**, ideally including: - `https://` Docker API endpoints - Optional mTLS (client cert / key) - Standard TLS options (CA, cert, key, insecure_skip_verify, etc.) For example: ```yaml providers: docker: my-remote-host: host: 192.168.0.101 port: 63377 protocol: https tls: keyFile: tls/key.pem caFile: tls/ca.pem certFile: tls/cert.pem ``` ### Notes / expectations I fully understand that: - The agent-based model is the recommended and safest approach - This feature is not strictly required if agents are acceptable That said, TLS support for the Docker provider would be very valuable for: - Existing infrastructures that already expose Docker API securely - Agent-less or low-footprint setups - Advanced homelab / internal environments with strong network controls If this is intentionally out of scope, I’d appreciate clarification on whether TLS support is fundamentally incompatible with the current design. Thanks again for the project and for taking the time to consider this.
adam commented 2025-12-29 14:25:25 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Dec 19, 2025):

Hi, first of all thanks for loving this project.

GoDoxy’s Docker provider, the connection appears to assume plain HTTP only

For agents it's already using mTLS, GoDoxy generates certs for each agent, at the moment you click the "Copy Docker Compose" button.

Everything including reverse proxying, health monitoring and data like cpu/memory usage, is throughout mTLS. It provides more than just docker-over-mTLS.

That said, TLS support for the Docker provider would be very valuable for

I see your point, many users would prefer full control and manage stuff manually.

I’d appreciate clarification on whether TLS support is fundamentally incompatible with the current design

Of course it's compatible as mTLS is already being used for agents. It's doable.

@yusing commented on GitHub (Dec 19, 2025): Hi, first of all thanks for loving this project. > GoDoxy’s Docker provider, the connection appears to assume plain HTTP only For agents it's already using mTLS, GoDoxy generates certs for each agent, at the moment you click the "Copy Docker Compose" button. Everything including reverse proxying, health monitoring and data like cpu/memory usage, is throughout mTLS. It provides more than just docker-over-mTLS. > That said, TLS support for the Docker provider would be very valuable for I see your point, many users would prefer full control and manage stuff manually. > I’d appreciate clarification on whether TLS support is fundamentally incompatible with the current design Of course it's compatible as mTLS is already being used for agents. It's doable.
adam commented 2025-12-29 14:25:25 +01:00
Author
Owner
Copy Link

@henryxrl commented on GitHub (Dec 19, 2025):

Thanks a lot for the detailed reply — this helps clarify the design a lot.

I fully understand now that:

  • GoDoxy agents already use mTLS
  • Reverse proxying, health checks, and metrics are all transported over mTLS
  • So TLS itself is clearly not a limitation of the architecture

The issue I’m running into is specifically with the Docker provider (non-agent mode).

In my setup:

  • The remote Docker API is exposed via tcp://host:63377
  • It is protected by HTTPS + mTLS (same model as Homepage / Dozzle)
  • This works fine with tools that support Docker-over-mTLS

However, from testing and reading the code/docs, the GoDoxy Docker provider currently:

  • Assumes plain HTTP
  • Has no way to specify:
    • protocol: https
    • CA certificate
    • client cert / key
  • Which results in errors like:
    “Client sent an HTTP request to an HTTPS server”

So the blocker is not TLS compatibility in general, but that the Docker provider doesn’t expose a TLS/mTLS configuration surface, even though agents already prove it’s doable.

Concretely, something like this (conceptually) would make Docker-over-mTLS possible:

providers:
  docker:
    my-remote-host:
      host: 192.168.0.101
      port: 63377
      protocol: https
      tls:
        caFile: /certs/ca.pem
        certFile: /certs/client.pem
        keyFile: /certs/client-key.pem

I totally get that agents are the preferred and more powerful solution, but supporting TLS for the Docker provider would be extremely useful for users who:

  • already run Docker socket proxy with mTLS
  • or want a lightweight, agentless integration

Happy to help test or provide more details if needed.

@henryxrl commented on GitHub (Dec 19, 2025): Thanks a lot for the detailed reply — this helps clarify the design a lot. I fully understand now that: - GoDoxy agents already use mTLS - Reverse proxying, health checks, and metrics are all transported over mTLS - So TLS itself is clearly not a limitation of the architecture The issue I’m running into is specifically with the **Docker provider (non-agent mode)**. In my setup: - The remote Docker API is exposed via tcp://host:63377 - It is protected by HTTPS + mTLS (same model as Homepage / Dozzle) - This works fine with tools that support Docker-over-mTLS However, from testing and reading the code/docs, the GoDoxy Docker provider currently: - Assumes plain HTTP - Has no way to specify: - protocol: https - CA certificate - client cert / key - Which results in errors like: “Client sent an HTTP request to an HTTPS server” So the blocker is not TLS compatibility in general, but that **the Docker provider doesn’t expose a TLS/mTLS configuration surface**, even though agents already prove it’s doable. Concretely, something like this (conceptually) would make Docker-over-mTLS possible: ```yaml providers: docker: my-remote-host: host: 192.168.0.101 port: 63377 protocol: https tls: caFile: /certs/ca.pem certFile: /certs/client.pem keyFile: /certs/client-key.pem ``` I totally get that agents are the preferred and more powerful solution, but supporting TLS for the Docker provider would be extremely useful for users who: - already run Docker socket proxy with mTLS - or want a lightweight, agentless integration Happy to help test or provide more details if needed.
adam commented 2025-12-29 14:25:25 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Dec 20, 2025):

try nightly image with the following:

providers:
  docker:
    my-remote-host:
      host: 192.168.0.101
      port: 63377
      protocol: https
      tls:
        ca_file: /certs/ca.pem
        cert_file: /certs/client.pem
        key_file: /certs/client-key.pem
@yusing commented on GitHub (Dec 20, 2025): try `nightly` image with the following: ```yaml providers: docker: my-remote-host: host: 192.168.0.101 port: 63377 protocol: https tls: ca_file: /certs/ca.pem cert_file: /certs/client.pem key_file: /certs/client-key.pem ```
adam commented 2025-12-29 14:25:25 +01:00
Author
Owner
Copy Link

@henryxrl commented on GitHub (Dec 20, 2025):

Hmm, when I switch to nightly image, I immediately encounter this issue:

godoxy-proxy     | 12-20 11:41 INF GoDoxy version v0.0.0
godoxy-proxy     | 12-20 11:41 INF icons loaded icons=4656
godoxy-proxy     | panic: interface conversion: interface {} is map[string]types.DockerProviderConfig, not map[string]string
godoxy-proxy exited with code 2 (restarting)

This happens even with a minimal config that previously worked on stable, e.g.:

providers:
  docker:
    local: $DOCKER_HOST

From the error, it looks like:

  • the config loader already parses providers.docker into
    map[string]types.DockerProviderConfig
  • but some runtime code still assumes the old shape
    map[string]string (name → endpoint)

So this seems like a partial migration / leftover type assertion in the docker provider path. Any fixes?

@henryxrl commented on GitHub (Dec 20, 2025): Hmm, when I switch to `nightly` image, I immediately encounter this issue: ```text godoxy-proxy | 12-20 11:41 INF GoDoxy version v0.0.0 godoxy-proxy | 12-20 11:41 INF icons loaded icons=4656 godoxy-proxy | panic: interface conversion: interface {} is map[string]types.DockerProviderConfig, not map[string]string godoxy-proxy exited with code 2 (restarting) ``` This happens even with a minimal config that previously worked on stable, e.g.: ```yaml providers: docker: local: $DOCKER_HOST ``` From the error, it looks like: - the config loader already parses providers.docker into `map[string]types.DockerProviderConfig` - but some runtime code still assumes the old shape `map[string]string (name → endpoint)` So this seems like a partial migration / leftover type assertion in the docker provider path. Any fixes?
adam commented 2025-12-29 14:25:26 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Dec 21, 2025):

Pushed a fix, update a try again

@yusing commented on GitHub (Dec 21, 2025): Pushed a fix, update a try again
adam commented 2025-12-29 14:25:26 +01:00
Author
Owner
Copy Link

@henryxrl commented on GitHub (Dec 22, 2025):

Thanks for the quick update! I'll try it out tomorrow!

@henryxrl commented on GitHub (Dec 22, 2025): Thanks for the quick update! I'll try it out tomorrow!
adam commented 2025-12-29 14:25:26 +01:00
Author
Owner
Copy Link

@henryxrl commented on GitHub (Dec 22, 2025):

I'm running into this error:

12-22 11:31 ERR config init error
• config load error
  • route provider errors
    • docker@int-srv-mac-mini: unable to parse docker host `<map[string]interface {} Value>`

It looks like GoDoxy is still trying to parse the docker provider config using the non-nightly (string-based) docker host logic, even though I’m on nightly.

Here’s exactly what I did:

  1. Switched the image tag from latest to nightly (from TAG=latest to TAG=nightly in .env)

  2. Added an extra volume mount:

    "/path/to/caddy-clients:/app/certs_internal:ro"

    where /path/to/caddy-clients's folder structure looks like this:

    Image

  3. In config.yml, under providers, I added a remote docker provider:

    docker:
    local: $DOCKER_HOST
    int-srv-mac-mini:
        host: int-srv-mac-mini.internal
        port: 63377
        protocol: https
        tls:
            ca_file: /app/certs_internal/int-srv-mac-mini/ca.pem
            cert_file: /app/certs_internal/int-srv-mac-mini/client-cert.pem
            key_file: /app/certs_internal/int-srv-mac-mini/client-key.pem

    where int-srv-mac-mini.internal correctly resolves to the Mac mini’s IP.

@henryxrl commented on GitHub (Dec 22, 2025): I'm running into this error: ```console 12-22 11:31 ERR config init error • config load error • route provider errors • docker@int-srv-mac-mini: unable to parse docker host `<map[string]interface {} Value>` ``` It looks like GoDoxy is still trying to parse the docker provider config using the non-nightly (string-based) docker host logic, even though I’m on nightly. Here’s exactly what I did: 1. Switched the image tag from latest to nightly (from `TAG=latest` to `TAG=nightly` in `.env`) 2. Added an extra volume mount: ``` "/path/to/caddy-clients:/app/certs_internal:ro" ``` where `/path/to/caddy-clients`'s folder structure looks like this: <img width="396" height="738" alt="Image" src="https://github.com/user-attachments/assets/90280502-67a0-476b-bf78-6f6b70e38f03" /> 3. In `config.yml`, under `providers`, I added a remote docker provider: ```yaml docker: local: $DOCKER_HOST int-srv-mac-mini: host: int-srv-mac-mini.internal port: 63377 protocol: https tls: ca_file: /app/certs_internal/int-srv-mac-mini/ca.pem cert_file: /app/certs_internal/int-srv-mac-mini/client-cert.pem key_file: /app/certs_internal/int-srv-mac-mini/client-key.pem ``` where `int-srv-mac-mini.internal` correctly resolves to the Mac mini’s IP.
adam commented 2025-12-29 14:25:26 +01:00
Author
Owner
Copy Link

@henryxrl commented on GitHub (Dec 22, 2025):

While we're at it, you might consider changing protocol to scheme, which is more consistent with existing proxy labels.

@henryxrl commented on GitHub (Dec 22, 2025): While we're at it, you might consider changing `protocol` to `scheme`, which is more consistent with existing proxy labels.
adam commented 2025-12-29 14:25:26 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Dec 23, 2025):

I've left this feature on a separate branch and the nightly image is now on dev branch so you're running into the error. Below is the build for the fix:

AMD64: ghcr.io/yusing/godoxy@sha256:49ad97e75caee984b4d66adfe1c14790f337b604de69e150aee1a96838a2b8ea

ARM64: ghcr.io/yusing/godoxy@sha256:b91680cb0376b51c1b8f80f14570dd36b07e24c672dcb0d65b3d2e33987e29d2

@yusing commented on GitHub (Dec 23, 2025): I've left this feature on a separate branch and the nightly image is now on dev branch so you're running into the error. Below is the build for the fix: AMD64: `ghcr.io/yusing/godoxy@sha256:49ad97e75caee984b4d66adfe1c14790f337b604de69e150aee1a96838a2b8ea` ARM64: `ghcr.io/yusing/godoxy@sha256:b91680cb0376b51c1b8f80f14570dd36b07e24c672dcb0d65b3d2e33987e29d2`
adam commented 2025-12-29 14:25:26 +01:00
Author
Owner
Copy Link

@henryxrl commented on GitHub (Dec 23, 2025):

@yusing Thanks a lot! I’ve tested this in the latest build and it’s working perfectly on my side.

Let me know if you’re planning to ship this in a stable release — and if so, it would be great to have the docs updated as well. Also curious whether protocol will stay as-is or be renamed to scheme in the final version.

@henryxrl commented on GitHub (Dec 23, 2025): @yusing Thanks a lot! I’ve tested this in the latest build and it’s working perfectly on my side. Let me know if you’re planning to ship this in a stable release — and if so, it would be great to have the docs updated as well. Also curious whether `protocol` will stay as-is or be renamed to `scheme` in the final version.
adam commented 2025-12-29 14:25:26 +01:00
Author
Owner
Copy Link

@yusing commented on GitHub (Dec 23, 2025):

Great. Will rename it to scheme and release soon, to be consistent with the scheme field for routes.

@yusing commented on GitHub (Dec 23, 2025): Great. Will rename it to `scheme` and release soon, to be consistent with the `scheme` field for routes.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
pull-request
Mirrored from GitHub Pull Request
 wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/godoxy-yusing#125
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?