Use FQDNs for internal service hostnames

[joubertredrat]

Dokploy currently uses standard names for services. This provides unique identifiers, but the raw service name can be difficult to recognize and distinguish in database connection strings and logs.

I’d like to propose making each service reachable through a full FQDN that keeps its service name and adds a configurable internal domain suffix. For example:

core-production-db-qwa21x.dokploy.internal

This would preserve the uniqueness of the existing service name while making it clear that the value is an internal hostname.

Current behavior

A connection string may use a service name directly as its hostname:

postgresql://app:secret@core-production-db-qwa21x:5432/appdb

Although this works, the hostname does not indicate that it is an internal address. Adding a domain suffix would make the intent more apparent:

postgresql://app:secret@core-production-db-qwa21x.dokploy.internal:5432/appdb

How Docker Compose supports this

Docker Compose supports setting a container hostname and adding network-level aliases. Dokploy could use a network alias to make the service name FQDN resolve to the service inside the Docker network:

services:
  database:
    image: postgres:17
    hostname: core-production-db-qwa21x.dokploy.internal
    networks:
      internal:
        aliases:
          - core-production-db-qwa21x.dokploy.internal
    environment:
      POSTGRES_DB: appdb
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${DB_PASSWORD}

  api:
    image: example/api:latest
    environment:
      DATABASE_URL: postgresql://app:${DB_PASSWORD}@core-production-db-qwa21x.dokploy.internal:5432/appdb
    networks:
      - internal

networks:
  internal:

The FQDN would be an alias available within the Docker network; it would not need to resolve through public DNS.

Proposed behavior

For each service, Dokploy could:

• Keep the existing service name identifier.
• Generate an internal FQDN by appending a configurable suffix, such as .dokploy.internal.
• Register that FQDN as a network alias for the service.
• Display the FQDN alongside the internal connection details in the UI.
• Keep the current service name hostname available for backward compatibility.

For example, if a service’s name is core-production-db-qwa21x, its internal FQDN would be:

core-production-db-qwa21x.dokploy.internal

Examples

postgresql://app:secret@core-production-db-qwa21x.dokploy.internal:5432/appdb

mysql://app:secret@core-production-db-qwa21x.dokploy.internal:3306/appdb

redis://:secret@core-production-db-qwa21x.dokploy.internal:6379/0

mongodb://app:secret@core-production-db-qwa21x.dokploy.internal:27017/appdb?authSource=admin

jdbc:postgresql://core-production-db-qwa21x.dokploy.internal:5432/appdb

Backward compatibility

This could be additive: Dokploy would register the new FQDN as an alias while retaining the existing service name hostname. Existing connection strings would continue to work, and users could adopt the FQDN when convenient.

Open questions

• Should .dokploy.internal be the default suffix, or should users be able to configure the suffix?
• Should Dokploy display both the existing service name hostname and the FQDN in the internal connection details?
• Should the FQDN be available as an environment variable for use in Compose definitions?
• Should this apply to standalone database resources as well as services in Docker Compose stacks?

[imrja8]

Hello, thanks for the idea!

You can already do this manually. In your app or database, go to Advanced → Swarm Settings → Network, set the network to dokploy-network, and add your alias, e.g. core-production-db-qwa21x.dokploy.internal. Make sure to keep dokploy-network in the list, otherwise the service is taken off it.

For Docker Compose, you can add the alias yourself like in your example.

Having Dokploy create and show this name automatically isn't supported yet, so I'll leave this open as an idea.