A custom domain lets you serve external traffic under your brand domain (like www.your-brand.com) instead of a long platform default domain.
This tutorial walks you step by step through custom domains and ICP filing — how to wire it up from filing to verification.
Entry points everywhere: static hosting, cloud functions and Cloud Run all support binding
CloudBase now gives static hosting, cloud functions and Cloud Run each their own domain-binding entry, so you don't jump around after binding. The HTTP gateway also supports a unified view of all bindings.
Pick the mode you need: static hosting offers "app mode" (one domain per site) and "path mode" (multiple resources under one domain); for cloud functions and Cloud Run, fill in a "trigger path" when binding.
Choose one of three access types (static hosting recommends CloudBase CDN; API services generally don't select it).
More stable production, more unified brand, and filing without a server
Default domains are for testing; your own domain is for production
The default domain (like xxx.tcloudbaseapp.com) is officially recommended for testing only. Once you bind your own domain for external business, your brand is more unified, search engine indexing is more stable, and shared links get higher click-through.
Two more practical scenarios: one CloudBase environment running multiple sites (official site, blog, campaign page) distinguished by different custom domains; and exposing cloud functions / Cloud Run APIs under a brand domain + custom path, which is far cleaner than throwing out the default domain.
Filing isn't just a formality: your CloudBase environment can handle it
A custom domain serving mainland-China traffic must have completed ICP filing — otherwise it can't be bound in CloudBase, and won't resolve. For developers, filing's value isn't just "compliance":
- CloudBase environments support filing: no need to buy a separate server just to file. Save an expense, and one less machine to maintain.
- Filing is the precondition for binding and serving: once you have the filing number, the domain can be bound in CloudBase and serve traffic.
- Up to 2 websites can be filed per environment: a qualifying environment can apply for filing service codes for multiple sites, enough for multi-site scenarios.
- Domains already filed elsewhere need "transfer-in": if the domain was filed with another provider, it can't be bound directly to CloudBase — the system will block it or flag it as unfiled. You need "new access filing (filing transfer-in)" first, attaching the filing info to Tencent Cloud before binding.
From filing to launch: three steps to wire up a custom domain
Precondition one: ICP filing
Filing within CloudBase requires three conditions at once:
- Plan version: Personal or higher (free trial environments don't support filing)
- Remaining validity: the environment has > 6 months remaining
- Fixed IP: the environment has "Cloud Run fixed IP" enabled
Once conditions are met, go to the "Filing management" page of the environment in the console, click "File now", and the system guides you to the Tencent Cloud filing console to pull the environment and submit the application.
The regulator's review usually takes 1–20 working days; you get the filing number on approval.
Precondition two: SSL certificate
Prepare an SSL certificate, upload it in the SSL certificate console, and select it when binding the domain to enable HTTPS.
The overall flow in three phases
The whole process is three steps: add the domain in the console → add a resolution record at your DNS provider → come back and verify it's effective.
Below, using the most common "static hosting + app mode + CloudBase CDN" as an example, we bind an official-site domain www.your-brand.com.
Phase one: add the domain in the console
Step 1 · Confirm prerequisites: before starting, prepare three things — the domain has completed ICP filing (if not, file within CloudBase per the section above); the SSL certificate is uploaded; static hosting is set up in the environment with site files uploaded.
Step 2 · Open the static hosting detail page: CloudBase console → select the target environment → left menu "Static website hosting" → click into the app deployment list → click the app name to open its detail page.
Step 3 · Open the custom domain entry: find "Custom domain" (a tab or button) on the detail page and click "Add custom domain".
Step 4 · Fill in the four config items: fill them in and submit. This only demonstrates the CloudBase CDN path; for the custom CDN config flow, click "Read more".
Step 5 · Wait for association, copy the CNAME value: after submission, the platform needs 3–5 minutes to complete domain association. Once done, the console gives you a CNAME record value (like xxx.tcloudbaseapp.com); click "Copy" — this step is the key to the whole flow, and the next phase depends on it.
Phase two: add a resolution record at your DNS provider
Step 6 · Add a CNAME record: sign in to the DNS provider where your domain lives (DNSPod, etc.), open the domain's resolution page, and click "Add record".
The most common pitfall: under the same host record, CNAME conflicts with other record types (A, TXT, etc.). If saving prompts "record conflict", delete the existing other records under that host record first, then add the CNAME.
Phase three: verify it's effective
Step 7 · Confirm resolution is effective: DNS usually takes 5–30 minutes. You can check with:
nslookup your-custom-domain
If the result shows the CNAME domain CloudBase provided, resolution is live.
Step 8 · Check status in the console and verify in the browser: back in the CloudBase console, wait for the domain status to become "normal / effective" (refresh the page if not updated). Then open https://www.your-brand.com in a browser — if you see the site, over HTTPS, the binding succeeded.
How to bind cloud functions / Cloud Run
The flow is identical (add domain in console → add CNAME in DNS → verify), with two differences:
- Fill in an extra trigger path: besides the domain, you fill in a trigger path when binding. Cloud functions often use
/apior/; Cloud Run fills it per the service route. One function/service can bind multiple domains, each with a different path. - CDN is usually "not used": API services generally don't need CDN acceleration — select "don't use CDN" (choose CloudBase CDN only if you need static-resource acceleration).
Entries:
- Cloud functions → function management → cloud function list → function detail page → custom domain
- Cloud Run → service management → service list → service detail page → custom domain
Multi-domain management and unbinding
When one resource binds multiple domains, the list shows them more clearly, with one-click CNAME copy, jump-to-resolution and unbind.
To see all binding relationships in one place, go to HTTP gateway → domain-associated resources. HTTP gateway supports two forms (app/file) for static hosting resources.
Each environment supports up to 50 custom domains (Enterprise max) — watch the quota.
Closing
CloudBase has compressed the custom-domain chain to three steps: file the environment, add the domain in the console, and verify.
If you haven't yet put your site on your own domain, come try it. Whatever step trips you up, or whatever domain capability you'd like CloudBase to add, share it in the comments.
