Wildcard Subdomains in cPanel for Multi-Tenant Apps
If you're building anything where every customer gets their own address - client1.yourapp.com, acme.yourapp.com - typing out a new subdomain in cPanel every time you sign up a customer doesn't scale. A wildcard subdomain fixes that: one DNS record and one cPanel entry, and every possible subdomain resolves automatically. Here's how to set it up properly, and where it usually goes wrong.
What a Wildcard Subdomain Actually Does
A normal subdomain like blog.yourdomain.com needs its own DNS record and its own entry in cPanel. A wildcard subdomain - written as *.yourdomain.com - matches anything in that position. anything.yourdomain.com, client47.yourdomain.com, xyz123.yourdomain.com all resolve to the same server without you touching DNS again.
What happens after the request reaches the server is up to your app, not cPanel. cPanel just makes sure the request doesn't bounce back as "server not found" - the routing to the right customer's data is your application's job.
When You Actually Need One
- Multi-tenant SaaS - each customer gets a branded subdomain instead of a shared login URL.
- Agency demo/staging sites - spin up
clientname.yourdomain.comfor every project without pre-creating DNS entries. - WordPress Multisite (subdomain mode) - every new site in the network needs a subdomain, and WordPress expects the wildcard to already resolve before you finish the multisite setup wizard.
If you only ever need a handful of fixed subdomains - shop., blog., app. - a wildcard is overkill. Add them individually and skip the extra complexity below.
Step 1: Add the Wildcard DNS Record
If your domain uses Getwebup's nameservers, this part is mostly automatic - see Step 2. If you're using an external DNS provider (Cloudflare, Route 53, your registrar's own DNS), add the wildcard manually first:
| Type | Name | Value |
|---|---|---|
| A | * | your server's IP address |
On Cloudflare specifically, a wildcard A record needs a paid plan for the proxy (orange cloud) to work on it - on the free plan, set it to "DNS only" (grey cloud) or the record gets rejected outright for anything but Enterprise. If you hit that wall, keep the wildcard DNS-only and put a separate reverse proxy or app-level TLS termination in front instead.
Step 2: Add the Wildcard Subdomain in cPanel
- Log in to cPanel and open Domains (or Subdomains on older themes).
- Click Create A New Domain (or Create under Subdomains).
- In the subdomain/domain field, type
*as the subdomain name and pick your domain from the dropdown - it'll show as*.yourdomain.com. - Set the document root - usually the same folder your app already lives in, since your code handles the per-tenant logic, not the filesystem.
- Click Submit (or Create).
If your domain runs on Getwebup's nameservers, cPanel writes the wildcard A record into its own DNS zone automatically at this step - you don't need to touch the Zone Editor separately. Check anyway: Domains > Zone Editor > Manage, and confirm a record for *.yourdomain.com is sitting there pointing at your server IP.
Step 3: Route Each Subdomain to the Right Tenant
cPanel now sends every subdomain request to the same document root. Your app needs to read the Host header and decide what to serve. A minimal PHP example:
<?php
$host = $_SERVER['HTTP_HOST'];
$subdomain = str_replace('.yourdomain.com', '', $host);
if ($subdomain === 'www' || $subdomain === 'yourdomain') {
// marketing site / main domain
} else {
$tenant = lookup_tenant_by_slug($subdomain);
if (!$tenant) {
http_response_code(404);
exit('No such workspace.');
}
// load $tenant's data
}
For WordPress Multisite in subdomain mode, you don't write this yourself - WordPress core handles the Host-header routing once the wildcard resolves and wp-config.php has SUBDOMAIN_INSTALL set to true.
SSL for Wildcard Subdomains
This is where most people get stuck. cPanel's free AutoSSL issues certificates per-hostname using HTTP validation, which can't prove ownership of "every possible subdomain" - it only validates ones that actually exist and respond at the time AutoSSL runs. New tenant subdomains show a browser warning until AutoSSL's next scheduled pass picks them up, which can be up to a day later.
Two real fixes:
- A true wildcard certificate issued via DNS-01 validation (Let's Encrypt, via Certbot or acme.sh) - one cert covers
*.yourdomain.compermanently, no per-subdomain issuance needed. This requires API access to your DNS provider and isn't something AutoSSL does out of the box. - Terminate TLS somewhere else - a reverse proxy or CDN in front of cPanel that holds the wildcard cert and forwards plain HTTP to your server. Common when you're already using Cloudflare for the domain.
If new tenant subdomains are showing "Not Secure" right after signup, that's almost always this gap between AutoSSL's per-hostname model and the wildcard's "anything works" DNS behavior - not a broken configuration.
Common Problems
Symptom: anything.yourdomain.com resolves, but a specific subdomain you set up separately doesn't
Cause: a specific A or CNAME record for that subdomain existed before the wildcard, or was added after with a typo, and now conflicts with it.
Fix: DNS resolvers prefer exact matches over wildcards, so a broken specific record wins even though the wildcard would have worked. Check the Zone Editor for a stray entry with that exact subdomain name and fix or remove it.
Symptom: every subdomain shows your default cPanel "It works!" or account suspended page
Cause: the wildcard subdomain's document root doesn't match where your app actually lives, or the app isn't reading the Host header at all yet.
Fix: re-check the document root in Domains, and confirm your application code has the routing logic from Step 3 in place before you announce the feature to customers.
Symptom: subdomains work over HTTP but SSL never catches up
Cause: covered above - AutoSSL's validation model doesn't suit unlimited dynamically-created subdomains.
Fix: move to a DNS-01 wildcard certificate or a proxy/CDN layer that already holds one.
Prevention Checklist
- Set up the wildcard DNS record and cPanel subdomain before you launch the feature, not after the first customer signs up.
- Decide your SSL approach (DNS-01 wildcard cert vs. proxy termination) up front - retrofitting it after customers are already on HTTP is more disruptive.
- Keep a short internal note of which specific subdomains are intentionally separate from the wildcard, so a future DNS cleanup doesn't accidentally delete a working override.
- Test with a throwaway subdomain (
test123.yourdomain.com) after any DNS or cPanel change, rather than waiting for a real customer to hit the bug.
Frequently asked questions
Can I use a wildcard subdomain and individual subdomains on the same domain?
Yes. DNS resolves exact matches before falling back to the wildcard, so a specific record for blog.yourdomain.com keeps working even with *.yourdomain.com also configured. Just make sure the specific record is correct, since a broken one will override the wildcard instead of falling through to it.
Does AutoSSL cover wildcard subdomains automatically?
No. AutoSSL validates and issues certificates per hostname over HTTP, which can't prove ownership of a wildcard pattern. It'll pick up individual subdomains once they exist and respond, but there's a delay, and a true *.yourdomain.com certificate needs DNS-01 validation instead.
Will a wildcard subdomain work if my domain uses external DNS instead of Getwebup's nameservers?
Yes, but you have to add the wildcard A record yourself in that provider's DNS panel - cPanel only auto-manages DNS for domains on its own nameservers. Point it at your server's IP the same way you'd point any other A record.
Is a wildcard subdomain the same thing as an addon domain?
No. An addon domain lets a completely separate domain name share your hosting account. A wildcard subdomain is still one domain (yourdomain.com) but matches an unlimited number of prefixes in front of it - useful when the prefix itself is dynamic, like a customer or project name.