Domains, HTTPS, and ports
Give a deployment a public address and understand how routing, certificates, and extra ports work.
The dashboard's own login normally lives on a Tailscale address or SSH tunnel. A deployment's public address is a separate route for the application you choose to publish. Set it under Public address on the Runtime step of New project, or on an existing project's Settings → Domains.
Add a hostname
- On Settings → Domains, press Add domain and enter the hostname. The panel checks whether another active project owns it and whether DNS currently points to this server.
- Create the shown A record at your DNS provider if you use your own domain. A host behind provider NAT needs the provider's public address; the server may have no public interface address to suggest.
- Read the certificate answer beside the name: HTTPS ready when a matching certificate can be reused, Certificate on deploy when the release will ask for one before it starts its candidate container, or HTTPS unavailable.
- Press Add domain, which saves the page's domains, then press Deploy changes. A saved hostname alone does not move live traffic.
Adding a domain on an existing project requires an administrator.
When the server has a public IPv4 address, the creation form can suggest a stable sslip.io hostname that resolves to it. It does not suggest one from a private or Tailscale address. If you add a custom hostname, keep its DNS pointed at the server and allow inbound HTTP/HTTPS traffic through the provider and host firewall as required for issuance and visitors.
Certificates and routing
For a new public hostname, automatic issuance uses HTTP-01 and requires publicly resolvable DNS plus reachable TCP port 80. Wildcard certificates need DNS-01 credentials and a domain you control. A private service can use an already provisioned matching certificate; public issuance is not implied by a private DNS name.
Just Dashboard can use a supported host nginx setup or a supported public Docker Caddy ingress. If public 80 and 443 are free, an authorized deployment can provision its own managed public Caddy ingress. It does not take over an arbitrary Apache or Traefik listener, a custom Caddy layout, or a 443 port that another service owns. A certificate or route failure is shown in the deployment run; the old live release is not replaced by a candidate that never passed the required steps.
The application container normally publishes its HTTP port to loopback while the public ingress routes the hostname to it. A web deployment may have multiple hostnames. Ask visitors for a password puts an HTTP basic-auth username and password in front of a domain before the application receives the request; this is separate from the application's own sign-in.
Ports outside HTTP
Some applications need a direct port in addition to the web route. Turn on Publish on a fixed host port under Settings → Runtime → Where it listens, then choose the host port and Bind address. A directly published port is a separate network exposure that bypasses the proxy, so review its bind address and firewall rules; Settings warns when the port is open on every interface. Only one release at a time can hold a fixed port, so the project uses stop-first replacement. Preview environments refuse fixed host ports.
The public ingress is for application hostnames. It does not change the network allowlist protecting the dashboard itself. For access to the dashboard, use the installation and access guide.