Public Access and TLS

Database services can be private to the server or exposed through generated public hostnames.

Public Hostnames

When a root domain is configured, Forge generates database hostnames from the stable service slug. Public access is off by default; enable Expose public TCP endpoint from the database service settings before using the generated hostname from outside the project runtime network.

Example:

postgres-db.apps.forgecloud.cc:29980

Use the generated hostname and the public port shown by Forge for tools or clients outside the Docker runtime network. App services on the same Forge runtime network should keep using the private service hostname and internal database port.

DNS

Public database hostnames depend on the wildcard root domain resolving to the server. If the wildcard DNS record is missing or still propagating, Forge leaves the replacement endpoint unpromoted and the hostname will not work from outside the server.

When the Forge root domain changes, Forge keeps the previous working hostname as an active compatibility endpoint. The service settings page shows the current primary hostname and any active aliases. Keep the old DNS record in place; this release does not expose endpoint retirement.

PostgreSQL TLS Assets

For supported PostgreSQL-family services, Forge prepares TLS assets used by public database access. Private key material remains protected and is not returned as a service variable.

Open the PostgreSQL service’s Settings tab and use the PostgreSQL TLS section to inspect the active status, certificate hostnames, authority type, and SHA-256 fingerprint. When Forge uses a per-service authority, select Download CA to save the PEM certificate required by clients using sslmode=verify-full. The CA private key and server private key are never downloadable.

When the service uses a public certificate authority, Forge does not offer an unrelated service CA download. Clients use their operating system trust store instead.

During a root-domain migration, Forge issues a replacement server certificate from the existing per-service Forge CA with every active hostname in the certificate SAN list. Forge installs the certificate atomically, reloads PostgreSQL without recreating the container, and verifies every hostname before promoting the new primary. If verification fails, the old primary remains unchanged and Forge restores the previous certificate.

Clients using a Forge per-service CA and sslmode=verify-full continue to use the same downloaded CA while both hostnames are active.

After a supported recovery or hostname change, verify every displayed hostname with sslmode=verify-full before directing external clients to it.

Logical Replication

PostgreSQL-family database services can enable logical replication. When enabled, Forge deploys Postgres with:

wal_level=logical
max_replication_slots=10
max_wal_senders=10

Use this when downstream tools need logical replication or change data capture. Leave it disabled if you do not need it.

Security Notes

• Prefer private project-local database URLs for app services on the same server.
• Use public database hostnames only when external access is needed.
• Keep generated credentials in service variables.
• Rotate credentials after sharing public access with temporary tools.
• Confirm firewall and DNS behavior before assuming a public hostname is reachable.
• Do not delete a compatibility DNS record merely because the new endpoint is active. Forge does not expose endpoint retirement in this release, so compatibility endpoints remain active aliases.
• Connected-server endpoint promotion stays blocked until that server’s Forge Agent can prove equivalent certificate and transport handling.