Vanity Mode

Vanity mode is the module's signature feature. It turns one domain you own into thousands of sellable “personal site + email” products: a customer picks a name and instantly gets name.yourdomain.com as a website and name@yourdomain.com as an email address. This chapter covers the whole story — what it is and why it sells, how to set up a vanity server group and its sellable domains, how to build the vanity product, what the order and client experience look like, and the standalone shop widget you can drop on any marketing site. It is intentionally detailed: Vanity is a complete go‑to‑market in itself.

• What Vanity Mode Is (and Why It Sells)
• Setting Up the Vanity Group & Sellable Domains
• The Vanity Product
• Vanity: Order & Client Experience
• The Vanity Shop Widget

What Vanity Mode Is (and Why It Sells)

PUQ Web Hosting module WHMCS

Order now | Download | Community

The idea in one sentence

You own a memorable domain — say benchwords.com — and you rent out names on it. A customer who picks ruslan gets:

• a website at ruslan.benchwords.com, and
• an email address ruslan@benchwords.com,

…provisioned in seconds, billed by WHMCS, and fully self‑service. One domain you already own becomes an unlimited catalogue of "personal site + email" products.

Why customers buy it

Registering a domain, configuring DNS, setting up mail and getting a website online is intimidating for most people. Vanity removes all of that: pick a name on a brand they already like, and they have a real site and a real inbox. It is the simplest possible hosting product to buy — which makes it the easiest to sell.

This is exactly what the customer ends up with — a clean two‑card dashboard, Website and Email, with nothing else to configure:

How it differs from normal hosting

A normal (Split/Unified) service gives the customer a whole domain and the full toolbox — DNS records, multiple mailboxes, SSL, backups, subdomains. A vanity slot is deliberately minimal:

	Normal hosting	Vanity slot
Domain	the customer's own domain	one name on your domain
Website	full account	a per‑service web account for name.yourdomain.com
Mailbox	create/delete many	exactly one fixed mailbox name@yourdomain.com
DNS	full zone editor	nothing to manage — one record on your zone
SSL / Backups / Subdomains	customer‑managed	handled for them (mail SSL lives on your provider domain)

The customer never sees DNS, SSL, backups or zone editing — those don't apply to a slot. The trimmed client menu reflects that.

The safety guarantee (read this)

Vanity mode is destructive‑safe by design. No matter what a customer does — order, change password, set forwards, cancel — the module only ever touches:

• the per‑service web user for that one subdomain,
• one mailbox on your shared provider mail user, and
• one DNS record (in push mode) for the subdomain.

It never touches the parent mail domain, the DNS zone, or your provider Hestia user. One customer's actions can never affect another customer or your base domain. You will see this guarantee restated on the setup screen — it is a load‑bearing invariant of the whole model.

Two ways to sell it

1. Inside WHMCS — a normal product with a live name‑availability check on the order form (covered in The vanity product and Order & client experience).
2. Anywhere — a standalone shop widget (two small files) you drop on any marketing domain. It shows a "claim your name" landing page and sends buyers straight into your prefilled WHMCS cart (covered in The vanity shop widget).

The next pages set it up end‑to‑end: first the server group + sellable domains, then the product, then the order/client experience, then the widget.

Setting Up the Vanity Group & Sellable Domains

PUQ Web Hosting module WHMCS

Order now | Download | Community

A vanity offer is built on a special server group whose purpose is Vanity. This page sets up that group and the parent domains you will sell names on.

Step 1 — Make a group a Vanity group

Create a server group (Infrastructure → Server Groups → Add Server Group), open it, and on the General tab set Group purpose to Vanity.

Switching to Vanity changes the group editor: the hosting‑config tabs disappear and a Vanity domains tab appears. A vanity group only has four tabs — General, Variables, DNS servers, Vanity domains.

Reserved names

The General tab has a Reserved names box (one per line). These are names customers may not register on this group's domains (e.g. admin2, your own brand words, etc.). They are enforced on the order form, the client setup page, the API and at provisioning — on top of the built‑in technical reservations (www, mail, admin, ns1, _dmarc, …), which you never need to list yourself.

Step 2 — Attach DNS servers

On the DNS servers tab, tick the nameservers that will carry the subdomain records for this group's domains. Subdomain records are pushed to every attached DNS node (active‑active).

If a domain uses External / wildcard DNS (next step), the module writes no DNS at all and this selection is irrelevant for that domain.

Step 3 — Add the parent domains you sell

Open the Vanity domains tab. This is the core of the setup. Note the banner restating the safety guarantee — the module only adds/removes the per‑service subdomain, one mailbox, and (in push mode) one DNS record; it never touches the parent mail domain, the zone, or your provider Hestia user.

Click Add domain and configure each parent domain:

Field	What it means
Parent domain	The domain you own and sell on (e.g. benchwords.com). Sold as name.<domain> (site) + name@<domain> (mailbox).
Mail server + Provider mail username	The shared Hestia mail user that already owns the mail domain. This user must already own the mail domain on HestiaCP before you sell slots on it. Every customer mailbox is created on this one user.
Mail domain	Usually the parent domain; leave blank to use it.
DNS mode	External / wildcard — you maintain a *.domain wildcard (or manage DNS yourself) and the module touches no DNS. Push — the module writes the name A/AAAA record into your existing zone.
Web servers	Which Web nodes may host this domain's sites. The least‑loaded ticked node is chosen at order time. Tick at least one (leave empty only for a mail‑only vanity product).
Status	Active (sellable) to offer it; otherwise hidden from new orders.

DNS mode tip: a *.benchwords.com wildcard A‑record pointing at your web tier is the simplest setup — every new name.benchwords.com resolves immediately with zero per‑order DNS work. Use Push mode only when you need exact per‑name records in a zone the module manages.

Step 4 — Variables (optional)

The Variables tab works the same as for standard groups — group‑wide {name} values used by DNS zone templates. Most vanity setups don't need it (the subdomain record is the only DNS the module writes). Note that a vanity group shows only four tabs — General / Variables / DNS servers / Vanity domains — the hosting‑config tabs are hidden.

Once the group has at least one Active parent domain with a mail user and a web server, it is ready. The next page wires up the product that sells from it.

The Vanity Product

PUQ Web Hosting module WHMCS

Order now | Download | Community

With the vanity group ready (previous page), create a WHMCS product that sells from it. Create a normal product (Setup → Products/Services), set its module to PUQ Web Hosting, and point its Server Group at your vanity group.

Step 1 — Set the deployment mode to Vanity

On Module Settings → General, set Deployment mode to Vanity. The limits tabs collapse into a single Vanity limits tab.

Step 2 — Vanity limits

The Vanity limits tab sets the slot sizes and the per‑slot caps:

Field	Meaning
Website quota	Disk for the name.<domain> website. 0 = no website (skip the web role).
Mailbox quota	Disk for the single name@<domain> mailbox. 0 = no mailbox (mail‑only off).
Cron jobs / Max databases / Max FTP / Default PHP	Caps for the website account (same meaning as normal hosting).
Auto‑install Let's Encrypt / Rate limit	Auto‑SSL on the website + outbound mail rate limit.

Tick Web and/or Mail on the General tab to control which the buyer gets (a website‑only or mailbox‑only vanity product is possible).

Step 3 — Create the Configurable Options & Custom Field

The product needs two things wired into WHMCS so the order form can expose them:

• a Configurable Option named vanity_domain (its values are the parent‑domain strings from the group's Vanity domains list — this is how the buyer picks which domain), and
• a product Custom Field named vanity_name (text, required — the buyer's chosen name).

The module creates both for you. Open the Config options tab and click Create / sync missing:

You'll see vanity_domain come up as dynamic (its values come straight from your group's sellable domains), the website/mailbox quota options, and the vanity_name custom field marked PRESENT. It's safe to re‑run any time — existing options and values are never changed. Tune the prices afterwards under WHMCS Configurable Options.

Step 4 — (Optional) client permissions

The Client tab toggles which client‑area actions are visible. For vanity, the relevant control is Mailbox settings — forwards / auto‑responder (the customer gets one fixed mailbox, so "create/delete mailbox" don't apply). Leave DNS/SSL/backup toggles off for a clean vanity experience.

What it looks like to your staff

Once a vanity service exists, its WHMCS service page shows the vanity configurable options — the parent Domain, Website quota and Mailbox quota — instead of the full split set:

The product is now ready to sell. The next page walks the buyer's experience and the client area they get.

Vanity: Order & Client Experience

PUQ Web Hosting module WHMCS

Order now | Download | Community

This page follows a vanity order from the WHMCS cart through to the live customer dashboard.

On the order form

The vanity product's order form asks the buyer to choose a name and a domain, with a single helper line: “lowercase letters, digits and hyphens — this is your website name and your email name.” Website/mailbox quota dropdowns and a live price summary sit alongside.

As the buyer types, the module checks availability live against your API. A taken or reserved name is rejected with the reason, and a live preview shows exactly what they'll get:

A free name turns green and unlocks Continue:

In the cart

At checkout the cart line is human‑readable — it shows the resolved Website (name.domain) and Email (name@domain) plus the chosen quotas, so the buyer sees precisely what they're paying for:

Deployment

After payment the service deploys with the same live splash as any product (web account → mailbox → SSL), then flips to the dashboard. See Deployment & Segmentation → How deployment works for the progress screens.

The vanity client dashboard

The customer lands on a deliberately simple, two‑card dashboard — Website and Email — each with an Open button and a Settings button, plus a small usage gauge:

The sidebar is trimmed to only what applies to a slot — Information, Mailbox, Web settings, FTP, Databases, Cron Jobs, Logs. There is no DNS editor, no SSL page and no backups page, because those don't apply to a vanity slot:

The single mailbox page

Because a slot has exactly one mailbox, there is no mailbox list — just a Mailbox settings page for name@domain: storage, change password, forwarding, and an auto‑responder. Open webmail is one click.

The customer can still manage their website like normal hosting — PHP version & HTTPS (Web settings), FTP accounts, databases, cron jobs and logs — all scoped to their name.domain site.

What your staff see

The admin service panel for a vanity service makes the shared model explicit: the Website card shows the per‑service web user and a "single record on the provider zone (cluster‑managed)" note; the Email card shows the one mailbox on the shared provider mail user, and notes that "Mail SSL is managed on the provider mail domain (not per‑service)."

The SSL tab confirms it — only the website certificate is shown; mail SSL belongs to your provider mail domain, not to each slot:

Everything the customer does stays inside their own slot. The parent domain, the shared mail account and the DNS zone are never modified per order — exactly as promised on the setup screen.

The Vanity Shop Widget

PUQ Web Hosting module WHMCS

Order now | Download | Community

Besides selling vanity slots through the normal WHMCS cart, the module ships a standalone “claim your name” widget — two small files you can drop on any marketing domain (you can deploy it on hundreds of them). It shows a polished landing page that live‑checks names and sends the buyer straight into your prefilled WHMCS cart.

How it works (and why it's safe)

The widget is just two files — index.html (the landing page) and proxy.php. The browser talks only to the widget's own proxy.php, which holds your shared API key and talks server‑to‑server to your WHMCS. The key never reaches the visitor, and proxy.php caches answers so it stays fast.

• The visitor picks a name, a domain and the website / mailbox sizes; the widget shows a live total price.
• As they type, the name is checked live against your WHMCS — reserved/taken names are rejected, free names are accepted with a name.domain / name@domain preview.
• On Get it now the widget redirects the visitor to your WHMCS cart with the product, domain, name and quotas already filled in.

Configure it (addon → Settings → Vanity widget)

In the addon, open Settings → Vanity widget:

1. Shared API key — used by proxy.php to authenticate to your WHMCS. Regenerating it invalidates all deployed widgets until you update them.
2. Vanity product — pick the vanity product to sell (grouped by product group; only this module's vanity products are listed).
3. Copy the small config block into the top of proxy.php (it already contains your WHMCS URL + key + product id).
4. Cart behaviour — choose what Get it now does: open the normal product‑config page, or skip configuration and land straight on the filled cart (review & pay).

Then download the two files and upload both to the web root of each marketing domain:

Prerequisites: the product must be a Vanity product whose group has Vanity domains configured, and it must have the vanity_domain Configurable Option + the vanity_name Custom Field (the product's Config options tab creates them — see The vanity product).

The buyer's flow on the widget

A reserved name is rejected inline, with the live preview:

A free name turns green and enables the button:

On Get it now the button shows a spinner while it redirects…

…and the visitor lands on your WHMCS cart with the Vanity product, the website and email, the quotas and the price already filled in — they just pay:

One vanity product can be fronted by a single WHMCS order form and by as many drop‑anywhere widgets as you like — every landing page funnels into the same prefilled cart.