Setting Up Custom Domain
For users that want to bring their own domain for their CVM.
If you prefer video content, check the YouTube tutorial here.
Prerequisites
Host your domain on Cloudflare
Have access to the Cloudflare account with API token
Create Cloudflare API Token
If you have not generated an API Token for your custom domain management then follow these steps:
Deployment
For this deployment example, we will be an nginx
application where the dstack-ingress
container that will forward traffic the TARGET_ENDPOINT
that points to the nginx
application with an exposed port 80
. It is important to know that this can change based on how your docker app's compose file is configured.
Now on to the deployment. Go to you Phala Cloud Dashboard and deploy a new CVM. Select docker-compose.yml option for deployment then take the past the docker compose file below into the Advanced tab of the CVM configration page.
services:
dstack-ingress:
image: kvin/dstack-ingress@sha256:2cc3bc50d71faa4d313084237b0f5d1d25963024f2484c7a6414aed075883cdd
ports:
- "443:443"
environment:
- CLOUDFLARE_API_TOKEN=${CLOUDFLARE_API_TOKEN}
- DOMAIN=${DOMAIN}
- GATEWAY_DOMAIN=${GATEWAY_DOMAIN}
- CERTBOT_EMAIL=${CERTBOT_EMAIL}
- SET_CAA=true
- TARGET_ENDPOINT=http://app:80
volumes:
- /var/run/tappd.sock:/var/run/tappd.sock
- cert-data:/etc/letsencrypt
restart: unless-stopped
app:
image: nginx # Replace with your application image
restart: unless-stopped
volumes:
cert-data: # Persistent volume for certificates
Explanation of environment variables:
CLOUDFLARE_API_TOKEN
: Your Cloudflare API tokenDOMAIN
: Your custom domain (i.e.your-domain.com
)GATEWAY_DOMAIN
: The dstack gateway domain. (e.g._.dstack-prod5.phala.network
for Phala Cloud prod5 server)CERTBOT_EMAIL
: Your email address used for Let's Encrypt email notificationsTARGET_ENDPOINT
: Where the ingress should forward all incoming traffic—i.e. the upstream service application:port. In this case, we point to thenginx
app on port80
.SET_CAA
: Set totrue
to enable CAA record setup
Now copy and paste the docker-compose.yaml code above into the Advanced Tab similar to the screnshot below.

Next you need to grab your Cloudflare API Token for your domain, and fill in your environment variables. For this example, deploy to prod5 ( domain:dstack-prod5.phala.network
).

Click Create button and your CVM will deploy in a couple minutes with the custom domain. Here is an example of a custom domain deployed to phala.incipient.ltd.

Congratulations! You've successfully deployed your CVM with a custom domain. Your application is now secured with Zero Trust HTTPS, thanks to the seamless integration of Cloudflare DNS and Let's Encrypt. If you are interested in the verification of this process check the Domain Attestation and Verification.
Knowledge
Now you have the knowledge base on the custom domain deployment with a basic nginx dstack application. The features you have used to enable your custom domain are defined below:
Automatic SSL certificate provisioning and renewal via Let's Encrypt
Cloudflare DNS configuration for CNAME, TXT, and CAA records
Nginx reverse proxy to route traffic to your application
Certificate evidence generation for verification
Domain Attestation and Verification
The dstack-ingress system provides mechanisms to verify and attest that your custom domain endpoint is secure and properly configured. This comprehensive verification approach ensures the integrity and authenticity of your application.
Evidence Collection
When certificates are issued or renewed, the system automatically generates a set of cryptographically linked evidence files:
Access Evidence Files:
Evidence files are accessible at
https://your-domain.com/evidences/
Key files include
acme-account.json
,cert.pem
,sha256sum.txt
, andquote.json
Verification Chain:
quote.json
contains a TDX quote with the SHA-256 digest ofsha256sum.txt
embedded in the report_data fieldsha256sum.txt
contains cryptographic checksums of bothacme-account.json
andcert.pem
When the TDX quote is verified, it cryptographically proves the integrity of the entire evidence chain
Certificate Authentication:
acme-account.json
contains the ACME account credentials used to request certificatesWhen combined with the CAA DNS record, this provides evidence that certificates can only be requested from within this specific TEE application
cert.pem
is the Let's Encrypt certificate currently serving your custom domain
You can check the example of the deployment at phala.incipient.ltd/evidences/.

CAA Record Verification
If you've enabled CAA records (SET_CAA=true
), you can verify that only authorized Certificate Authorities can issue certificates for your domain:
dig CAA your-domain.com
The output will display CAA records that restrict certificate issuance exclusively to Let's Encrypt with your specific account URI, providing an additional layer of security.
TLS Certificate Transparency
All Let's Encrypt certificates are logged in public Certificate Transparency (CT) logs, enabling independent verification:
CT Log Verification:
Visit crt.sh and search for your domain
Confirm that the certificates match those issued by the dstack-ingress system
This public logging ensures that all certificates are visible and can be monitored for unauthorized issuance
Last updated
Was this helpful?