# Subdomains

> Give a project its own hostname under a domain you already host — blog.example.com, staging.example.com — with its own document root and certificate.

Source: https://www.corepanel.net/docs/accounts/subdomains/
Last updated: 2026-08-03
Part of the CorePanel documentation — https://www.corepanel.net/docs

---

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](https://www.corepanel.net/docs/web/serving-modes)) |
| **Force HTTPS** | Its own — on by default ([Force HTTPS](https://www.corepanel.net/docs/web/https-redirect)) |

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** — what goes in front of the parent zone (`blog`, not `blog.example.com`);
- the **parent domain** — one of the account's own domains;
- optionally the **serving mode**.

From the CLI:

```bash
corepanel subdomain add <accountId> blog example.com
corepanel subdomain add <accountId> dev.blog example.com   # nested
```

### 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.
- Each label must be a valid DNS label: 1–63 characters, lowercase letters, digits and
  internal hyphens (no leading or trailing hyphen).
- The label may be **more than one label** for a nested subdomain: `dev.blog` under
  `example.com` gives `dev.blog.example.com`. It is one site like any other — one vhost,
  one record in the `example.com` zone. Other panels create these (cPanel does), so an
  [import](https://www.corepanel.net/docs/cpanel-import) brings them over as they are. The one thing to know is
  certificates: a wildcard covers a **single** label, so `*.example.com` does not cover
  `dev.blog.example.com` and CorePanel issues a certificate for that exact name instead.
- `www` and `webmail` are **reserved** as a whole label. CorePanel already provisions
  `www.<domain>` with every domain and a shared `webmail.<domain>` for the mail interface,
  so those names cannot be taken. They are free inside a nested label — nothing else
  answers for `www.blog.example.com`.
- 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/dev.blog.example.com/   dev.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](https://www.corepanel.net/docs/wordpress) on it — pick the subdomain as the install target;
- point a [reverse proxy route](https://www.corepanel.net/docs/reverse-proxy) on it at a local service;
- deploy an [application](https://www.corepanel.net/docs/applications) 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](https://www.corepanel.net/docs/backups).

## 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.