Subdomains

A subdomain is a hostname under a domain the account already owns: blog.example.com, staging.example.com, api.example.com. It gets its own document root and its own certificate, and is served independently from the parent site.

Typical uses: a staging copy of a site, a blog on a different CMS, a documentation site, an API endpoint, a customer-facing dashboard.

What a subdomain gets

Document root	~/domains/<fqdn> — for example ~/domains/blog.example.com
DNS	An A record inside the parent’s existing zone, not a zone of its own
Certificate	Its own, issued automatically
PHP	The account’s PHP version, in the account’s pool
Serving mode	Its own — plain by default (Serving Modes)
Force HTTPS	Its own — on by default (Force HTTPS)

Because the record lives in the parent zone, a subdomain only works on a domain whose DNS CorePanel serves.

Adding a subdomain

From the account workspace open Subdomains → Add subdomain, or use the server-wide Subdomains page and pick the account first. You provide:

• the label — the left-most part only (blog, not blog.example.com);
• the parent domain — one of the account’s own domains;
• optionally the serving mode.

From the CLI:

corepanel subdomain add <accountId> blog example.com

Rules

• The parent must be a primary or addon domain owned by the account. An alias cannot host subdomains — it has no site of its own to hang them off.
• The label must be a valid DNS label: 1–63 characters, lowercase letters, digits and internal hyphens (no leading or trailing hyphen).
• www and webmail are reserved. CorePanel already provisions www.<domain> with every domain and a shared webmail.<domain> for the mail interface, so those names cannot be taken.
• The full hostname must be unique across the whole server — it cannot collide with any domain or subdomain, in any account.
• Subdomains consume the account’s Subdomains limit (0 = unlimited).

Uploading content

Upload to the subdomain’s own directory, ~/domains/<fqdn>. It is created empty and appears in FTP inside domains/, next to public_html rather than within it.

~/public_html/                    example.com
~/domains/blog.example.com/       blog.example.com
~/domains/otherproject.com/       an addon domain

Keeping it out of public_html is what makes the subdomain reachable only under its own hostname: a directory inside the primary’s document root would also be served as https://example.com/blog.example.com/, with the primary’s settings rather than the subdomain’s.

Mail on subdomains

Subdomains have no mailboxes. Mail is a property of a domain — primary, alias or addon — and a subdomain is not one of those. An address like info@blog.example.com is not something CorePanel provisions; use info@example.com, or make the name an addon domain if it genuinely needs its own mail identity.

WordPress and applications on a subdomain

A subdomain is a normal serving target, so you can:

• install WordPress on it — pick the subdomain as the install target;
• point a reverse proxy route on it at a local service;
• deploy an application under it.

Running staging on staging.example.com and production on example.com inside the same account is the common pattern, and both are covered by the same backup.

Deleting a subdomain

Deleting removes its vhost, its certificate, its A record from the parent zone and its document root, and frees the slot against the account’s limit. Deleting the parent domain — or the whole account — removes its subdomains first, automatically.