Domains and HTTPS

Generated addresses

Configure a generated domain on an HTTP service to get an address under up.upferry.com. The panel displays the exact hostname. It belongs to a service in an environment, rather than to the whole project. A copied environment gets its own generated addresses; ordinary redeployments keep the existing ones.

Use this address to test deployment, application behavior, and health checks before moving a production hostname.

Connect your own domain

1. Add the hostname, for example api.example.com, in the service's domain settings for the intended environment.
2. Use the DNS target displayed in the panel. A CNAME target is a hostname without https:// or a path.
3. If the domain is in an accessible connected Cloudflare zone, Upferry can manage its DNS. An existing conflicting record requires an explicit update.
4. For DNS hosted elsewhere, change the record at that DNS provider. For a subdomain, use the CNAME record the panel requests. Apex domains may require provider-specific flattening or different settings.
5. Wait for DNS propagation and HTTPS readiness. Open the real hostname and test the application before stopping the old host.

A domain purchased at Namecheap can use Cloudflare DNS if its nameservers have been moved there. The registrar and the active DNS provider are not always the same company. Do not change unrelated mail records.

Private service networking

Services in the same project environment can connect using the service name or <service>.upferry.internal, such as postgres.upferry.internal:5432. Use the generated database variables or variable references instead of hardcoding container IPs.

Private names are for workloads in that environment. They are not public internet hostnames and will not normally resolve on your laptop. Network Permissions can further restrict allowed connections. A public address does not become allowed merely because the corresponding internal service is allowed.