Domains
Coolify uses domains to route public HTTP and HTTPS traffic through the proxy to an application or a web-facing service container.
The domain's DNS record points to the server running the resource. The Coolify proxy then matches the hostname and path and forwards the request to the correct container port.
Choose a domain option
Choose the option that matches how you plan to use the resource.
A domain does not expose a standalone database. Use the database's public port when an external client must connect.
These instructions assume the server uses the integrated Traefik or Caddy proxy. With Custom (None), you must configure routing and TLS in your own proxy. See Proxy overview before continuing.
Add a custom domain
Before starting, point the domain to the resource server and verify its DNS records. Inbound TCP ports 80 and 443 must be open on the resource server, and the application must listen on the container port that Coolify will target.
Enter the domain in Coolify
Open the application or Service, then select Domains in its settings sidebar.
- Select Add domain.
- Choose https or http in Protocol.
- Enter the hostname in Domain, for example
app.shadowarcanist.com. - Set Port when the proxy must target a specific container port, and Path when routing a prefix such as
/api. - For Docker Compose, choose the non-database Service that receives the request.
- Select Add domain to save the route. Review any DNS or domain-conflict warning before proceeding.
Redeploy and verify the domain
Redeploy the resource so the proxy uses the new configuration.
After the deployment completes:
- Confirm the hostname resolves to the expected server or CDN.
- Open the configured URL in a browser.
- Confirm it loads the intended application.
- For an
https://URL, confirm the browser shows the expected certificate.
If DNS was changed recently, you may need to wait for the previous record's TTL to expire.
Supported domain formats
The domain form separates Protocol, Domain, Port, and Path. The examples below show the resulting URLs; add each hostname as a separate domain.
| Goal | Resulting URL |
|---|---|
| Route one hostname | https://app.example.com |
| Route multiple hostnames | https://app.example.com,https://www.example.com |
Target container port 3000 | https://app.example.com:3000 |
Route a path to container port 80 | https://app.example.com/api |
Route a path to container port 8080 | https://app.example.com:8080/api |
When Port is empty, a standard application uses the first value in Ports exposes, and a static site uses port 80. Docker Compose routes use the selected service's detected port when available. Set Port explicitly when the detected default does not match the application.
Add multiple hostnames with Add domain, one at a time. Coolify normalizes application domains and rejects duplicate entries.
When a value contains both a port and a path, put the port before the path:
- Correct:
https://app.shadowarcanist.com:8080/api - Incorrect:
https://app.shadowarcanist.com/api:8080
Route to a port or path
The port in a domain value selects the port inside the container. It does not create a public host-port mapping. Visitors still reach an https:// domain through the proxy on port 443.
| Domain value | Proxy behavior |
|---|---|
https://app.shadowarcanist.com | Send requests for the hostname to the resource's default container port. |
https://app.shadowarcanist.com:3000 | Send requests for the hostname to port 3000 inside the container. |
https://shadowarcanist.com/api | Send requests beginning with /api to the resource's default container port. |
https://shadowarcanist.com:8080/api | Send requests beginning with /api to port 8080 inside the container. |
Path-based routes let several resources share one hostname. For example, one application can use https://shadowarcanist.com, while another uses https://shadowarcanist.com/api.
Coolify creates a path-prefix route from the value. More specific paths take priority over the root route in the proxy's routing model.
Control prefix stripping
By default, Coolify strips the configured prefix before forwarding the request. A request to https://shadowarcanist.com/api/users reaches the application as /users.
For an application, open Advanced > Proxy and choose Keep paths as-is in Path prefixes when it expects to receive /api/users instead.
Keep every resource serving a shared hostname running and healthy. If a path route is unavailable, the result depends on the remaining proxy routes and application responses.
Configure HTTPS and redirects
Use an https:// URL when you want the integrated proxy to configure TLS. Coolify generates the route, and Traefik or Caddy requests and renews the certificate.
An http:// value creates an HTTP route. Other resource or proxy settings can still redirect that route to HTTPS.
The hostname must resolve through the resource server or a correctly configured CDN, ports 80 and 443 must reach the Coolify proxy, and the domain must be present in the resource configuration.
If the browser shows a certificate warning, follow Let's Encrypt not working. For wildcard certificates, follow the guide for Traefik or the Caddy DNS challenge.
Redirect www and non-www
Add both hostnames on Domains and create DNS records for both. Edit a domain, then use www redirect to choose the canonical hostname. For a Compose application, this choice applies to all domains of the selected service.
| www redirect | Behavior |
|---|---|
| No redirect | Serve both configured hostnames without a Coolify-managed redirect. |
| Redirect to www | Redirect the non-www hostname to the configured www hostname. |
| Redirect to non-www | Redirect the www hostname to the configured non-www hostname. |
Coolify will not enable Redirect to www unless a www URL is present in Domains. The corresponding www DNS record must also resolve to the resource server.
Control search engine indexing
Coolify can mark individual application and service domains as Noindex without changing application code. The integrated Traefik or Caddy proxy then adds this response header for that domain:
X-Robots-Tag: noindex, nofollowA resource with several domains can keep its production domain indexable while marking a staging or temporary domain as noindex.
- Open the application or Service and select Domains in its settings sidebar.
- Edit the domain.
- Choose Noindex in Search engine indexing, then save. Choose Indexable to remove the header.
- Redeploy the resource to apply the updated proxy configuration.
- Check the response header:
curl -sI https://staging.example.com | grep -i x-robots-tagA noindex domain returns:
x-robots-tag: noindex, nofollowPreview deployment domains are always served as noindex. Removing a domain also removes its stored indexing selection; renaming a domain preserves the selection for the renamed domain.
Search crawlers can choose whether to honor this header, and anyone who knows the URL can still open it. Use authentication or network restrictions when access must be limited.
For applications, the selector is available while General > Container labels > Label management is set to Managed by Coolify (auto-generated). When you choose manual label management, add the equivalent X-Robots-Tag response header in your custom proxy labels.
Use generated domains
Coolify can generate an application domain from the server's Wildcard Domain setting.
Before configuring generated domains, create and verify a wildcard DNS record for the server.
Configure the server wildcard domain
In Coolify, open Servers, select the server, and open General. Enter https://shadowarcanist.com in Wildcard Domain, then save the server.
Generate an application domain
Open an application on that server, select Domains, then Add domain. Use Generate domain in the form, review the generated values, and add the domain.
Coolify generates a hostname such as https://<application-id>.shadowarcanist.com. Open the generated URL after redeploying the application to confirm it works.
The wildcard setting affects generated domains; it does not change domains already assigned to resources.
When Wildcard Domain is empty, Coolify can generate an sslip.io domain from the server IP address. Use that URL to verify a deployment or proxy route before configuring your own domain.
Use sslip.io testing domains
When a server has no Wildcard Domain configured, Coolify generates an sslip.io domain from the server IP address when you create a resource.
sslip.io is a free, public DNS service that resolves any subdomain that contains an IP address back to that IP address. There is nothing to register, no DNS record to create, and no certificate to install — it is a magic resolver:
1.2.3.4.sslip.ioresolves to1.2.3.4anything.1.2.3.4.sslip.ioalso resolves to1.2.3.4myapp.staging.1.2.3.4.sslip.ioalso resolves to1.2.3.4
Because the IP address is encoded into the hostname, sslip.io answers for an unlimited number of subdomains without anyone configuring DNS in advance. This gives you a working URL on a fresh server in seconds, before you point a real domain.
The generated URL always uses http://. Do not change it to https://: Let's Encrypt rate-limits the entire shared sslip.io zone, so certificate issuance fails. Use your own domain, or a wildcard you own, when you need HTTPS.
sslip.io domains are best for trying Coolify on a new server, sharing a quick preview link, and internal demos — any flow where plain HTTP and an instantly working URL are enough. Move to a custom domain, or a wildcard you own, before you need TLS, go to production, or share the link with end users.
Resolve domain conflicts
Coolify warns when the same complete domain is already assigned to another application, service, or the Coolify dashboard in the same team.
Reusing a domain can make routing unpredictable and can prevent the correct TLS certificate from being served. Only one resource can receive the traffic reliably.
Open the resource linked in the conflict message and remove or change its domain. Override the warning only when you are deliberately replacing that route.
Set the Coolify dashboard domain
Self-hosted users can assign a domain to the Coolify dashboard from Settings > General.
Set URL to a complete value such as https://coolify.shadowarcanist.com only after you point its DNS record to the server running Coolify. Do not reuse an application or service domain for the dashboard.
Read Instance settings for the complete setting reference.
Continue with domain routing
Use these guides to prepare the public route or investigate a domain that does not work as expected.
Configure the firewall
Open the ports required for HTTP, HTTPS, and certificate issuance on the resource server.
Troubleshoot certificates
Check DNS, proxy reachability, rate limits, and certificate resolver errors.
Troubleshoot proxy routing
Trace a failed route from the proxy to the application container and its target port.
Cloudflare managed records
With a team Cloudflare integration token, Coolify can create, replace, and remove managed DNS records from resource Domains pages. Follow Cloudflare DNS management for token permissions and record lifecycle.