Domains and Aliases

An account always has one primary domain. On top of it you can add two kinds of secondary domain, and the difference between them is the single most useful thing to understand about hosting several domains in one account.

Type	Document root	DNS zone	Mail
Primary	~/public_html	Its own	Full: mailboxes, DKIM, sending and receiving
Alias (parked)	The primary’s ~/public_html	Its own	None of its own — mail is redirected to the primary
Addon	~/domains/<domain>	Its own	Full: its own mailboxes and DKIM

In one sentence: an alias is another name for the same site; an addon domain is a different site inside the same account.

Domain aliases (parked domains)

Use an alias when a domain must lead to a site you already host:

• example.net and example.org protecting the brand of example.com
• an old domain kept alive after a rename
• a shorter domain used in print or advertising

The alias gets its own DNS zone pointing at this server and its own certificate, but it serves the primary’s document root. There is nothing extra to upload.

Its mail is redirected to the primary domain. An alias has no mailboxes of its own — when it is added, CorePanel installs a whole-domain redirect so that anything@example.net is delivered to anything@example.com and nothing bounces.

Aliases should usually redirect, not duplicate

By default a new alias serves a full copy of the primary’s site under two more hostnames, which search engines see as duplicate content. Set its canonical host to primary and every request to the alias answers a single-hop 301 to the primary’s canonical hostname instead. See Canonical hostnames below.

Addon domains

Use an addon domain when the domain is a different website that you want to keep inside the same account — the same customer, the same FTP login, the same quota:

• a second project of the same client
• a separate landing page or campaign site
• a site with its own mailboxes

An addon gets its own document root at ~/domains/<domain>, its own DNS zone, its own certificate, and a full mail identity with its own DKIM key. Mailboxes on an addon domain work exactly like mailboxes on the primary.

That document root sits beside the primary’s public_html, not inside it, so the addon is reachable only under its own domain — never as a path under the primary. See Files and FTP access for the full home-directory layout.

Existing content is never destroyed

If the document root of an addon already exists — content uploaded by FTP before the domain was added, for instance — CorePanel reuses it. And if adding the domain then fails for another reason, the rollback only removes a document root that CorePanel itself created, never one that was already there.

Adding a domain

From the account workspace, open Account domains → Add domain, enter the domain, and pick its type (alias or addon). From the CLI:

corepanel domain add <accountId> example.net --type alias
corepanel domain add <accountId> otherproject.com --type addon

CorePanel provisions the vhost, the DNS zone and the certificate, then records the domain against the account.

Rules and limits

• A domain name can belong to only one account on the server. Adding one that already exists anywhere is rejected.
• Aliases and addons consume separate limits (Domain aliases and Addon domains). 0 means unlimited.
• An addon also consumes one of the server’s websites — 20 on the free Personal edition, unlimited on Pro and Business. An alias does not: it republishes a document root that is already counted, so parking a domain keeps working at the cap.
• Every domain also gets its www. name automatically. You do not add www yourself.
• The primary domain cannot be deleted while the account exists.

Canonical hostnames: www or not

CorePanel serves every domain under both example.com and www.example.com. Unless one of them redirects to the other, the same site answers 200 under two names — bad for SEO and confusing in analytics.

The canonical host setting decides which name is the real one:

Setting	Behaviour
www	www.example.com is canonical; example.com answers 301 to it. Default for new domains.
nonwww	example.com is canonical; www.example.com answers 301 to it.
none	Both names serve the site directly, no redirect.
primary	Aliases only. Every hostname of the alias redirects, in one hop, to the primary domain’s canonical hostname.

Redirects preserve the path and the query string, so a deep link keeps working.

Existing domains were left alone

Domains that existed before this setting was introduced keep none — changing how a live site answers is an operator decision, not an upgrade side effect. New domains are created with www canonical.

Serving mode

Each domain also has a serving mode (plain, cms, spa) that controls how the web server handles a request for a path that is not a file on disk. New domains get plain, where a missing path is a 404. Change it — on a domain or a subdomain — with the edit button on its row in the account workspace. See Serving Modes.

Force HTTPS

Each domain also decides whether plain HTTP answers a redirect to HTTPS. New domains are created with it on; domains that arrive through an import or a restore are created with it off, because a migrated site usually still has http:// integrations pointing at it.

The redirect only fires while the hostname has a valid certificate, so enabling it early is harmless and a failed renewal cannot take the site offline. Same edit button, HTTPS section. See Force HTTPS.

Deleting a domain

Deleting a secondary domain removes its vhost, its DNS zone, its certificate and — for an addon — its DKIM key and, optionally, its document root. Any subdomains under it go with it.

The account’s usage counter is released, so the slot becomes available again.

Which one should I use?

Does the domain need to show a different website?
├── No  → alias, canonical host "primary"      (redirects to the main site)
├── No, but it must serve the same content
│        under its own name → alias, canonical host "www"/"nonwww"
└── Yes → does it need its own mailboxes or its own DNS-level identity?
          ├── Yes → addon domain
          └── No, and it belongs to another customer → a separate account

When in doubt between an addon domain and a new account: an addon shares the quota, the FTP user and the fate of the account it lives in. Different customers get different accounts.