[GH-ISSUE #684] Valkey Template exports external network port #3656

New Issue

GiteaMirror · 2026-04-30T06:30:54-05:00

GiteaMirror commented

2026-04-30 06:30:54 -05:00

Originally created by @nikos on GitHub (Jan 16, 2026).
Original GitHub issue: https://github.com/Dokploy/templates/issues/684

To Reproduce

After creating a Valkey service from the Template (using docker compose under the hood) I was surprised that the docker process is exposed although the (default) Isolated Deployment on Docker network is enabled. The internal port 6379 is exposed externally to port 32780.

I was also trying to bind to an private network address (inside of the valkey.conf I set to bind 10.0.0.2, which is the private network I created within my Hetzner cloud setup and assigned to this server), but this did not work:

Could not create server TCP listening socket 10.0.0.2:6379: bind: Cannot assign requested address
Failed listening on port 6379 (tcp), aborting.

Current vs. Expected behavior

I was expecting that the port 6379 is not exported externally, but only available to the docker containers in the same dokploy project.

Provide environment information

Ubuntu 24.04 (Hetzner cloud server), dokploy 0.26.5

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

Docker Compose

version: "3.8"

services:
  valkey:
    image: valkey/valkey:8.1.4
    restart: unless-stopped
    ports:
      - 6379
    volumes:
      - ../files/valkey.conf:/etc/valkey/valkey.conf
      - valkey-data:/data
    command: valkey-server /etc/valkey/valkey.conf
    environment:
      - VALKEY_PASSWORD=${VALKEY_PASSWORD}
    healthcheck:
      test: ["CMD-SHELL", "valkey-cli -a \"$$VALKEY_PASSWORD\" ping | grep PONG"]
      interval: 10s
      timeout: 3s
      retries: 5
      start_period: 10s

volumes:
  valkey-data: {}

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

Same server where Dokploy is installed

Additional context

See docker process

valkey/valkey:8.1.4 "docker-entrypoint.s…" 2 hours ago Up About an hour (healthy) 0.0.0.0:32780->6379/tcp, [::]:32780->6379/tcp

Will you send a PR to fix it?

Maybe, need help

Originally created by @nikos on GitHub (Jan 16, 2026). Original GitHub issue: https://github.com/Dokploy/templates/issues/684 ### To Reproduce After creating a Valkey service from the Template (using docker compose under the hood) I was surprised that the docker process is exposed although the (default) Isolated Deployment on Docker network is enabled. The internal port 6379 is exposed externally to port 32780. I was also trying to bind to an private network address (inside of the `valkey.conf` I set to `bind 10.0.0.2`, which is the private network I created within my Hetzner cloud setup and assigned to this server), but this did not work: `Could not create server TCP listening socket 10.0.0.2:6379: bind: Cannot assign requested address` `Failed listening on port 6379 (tcp), aborting.` ### Current vs. Expected behavior I was expecting that the port 6379 is not exported externally, but only available to the docker containers in the same dokploy project. ### Provide environment information ```bash Ubuntu 24.04 (Hetzner cloud server), dokploy 0.26.5 ``` ### Which area(s) are affected? (Select all that apply) Docker Compose ``` version: "3.8" services: valkey: image: valkey/valkey:8.1.4 restart: unless-stopped ports: - 6379 volumes: - ../files/valkey.conf:/etc/valkey/valkey.conf - valkey-data:/data command: valkey-server /etc/valkey/valkey.conf environment: - VALKEY_PASSWORD=${VALKEY_PASSWORD} healthcheck: test: ["CMD-SHELL", "valkey-cli -a \"$$VALKEY_PASSWORD\" ping | grep PONG"] interval: 10s timeout: 3s retries: 5 start_period: 10s volumes: valkey-data: {} ``` ### Are you deploying the applications where Dokploy is installed or on a remote server? Same server where Dokploy is installed ### Additional context See docker process `valkey/valkey:8.1.4 "docker-entrypoint.s…" 2 hours ago Up About an hour (healthy) 0.0.0.0:32780->6379/tcp, [::]:32780->6379/tcp` ### Will you send a PR to fix it? Maybe, need help

GiteaMirror commented

2026-04-30 06:30:56 -05:00

@Siumauricio commented on GitHub (Jan 28, 2026):

Yeah the docker compose file should use expose instead of ports and you will see no more exposed ports on a random port, you can change manually, for now I will transfer this issue to the templates repo, thanks

@Siumauricio commented on GitHub (Jan 28, 2026): Yeah the docker compose file should use expose instead of ports and you will see no more exposed ports on a random port, you can change manually, for now I will transfer this issue to the templates repo, thanks

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/templates#3656