# 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) ### PUQ Web Hosting module **[WHMCS](https://puqcloud.com/)** ##### [Order now](https://puqcloud.com/) | [Download](https://download.puqcloud.com/WHMCS/servers/PUQ_WHMCS-WEB-Hosting/) | [Community](http://community.puqcloud.com/) ## 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: ![Vanity client dashboard](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-3qhj4cj1.png) ## 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*). ![Vanity shop widget landing](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-7rjlzvub.png) > 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](https://puqcloud.com/)** ##### [Order now](https://puqcloud.com/) | [Download](https://download.puqcloud.com/WHMCS/servers/PUQ_WHMCS-WEB-Hosting/) | [Community](http://community.puqcloud.com/) 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**. ![Vanity group — General + reserved names](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-irnsdwhn.png) 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). ![Vanity group — DNS servers](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-htwpjyau.png) 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. ![Vanity domains — sellable parents](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-tqzdfq8n.png) Click **Add domain** and configure each parent domain: ![Edit vanity parent domain](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-sjxvimxo.png) | Field | What it means | |-------|---------------| | **Parent domain** | The domain you own and sell on (e.g. `benchwords.com`). Sold as `name.` (site) + `name@` (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. ![Vanity group — Variables](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-ptkphxg4.png) 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](https://puqcloud.com/)** ##### [Order now](https://puqcloud.com/) | [Download](https://download.puqcloud.com/WHMCS/servers/PUQ_WHMCS-WEB-Hosting/) | [Community](http://community.puqcloud.com/) 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. ![Deployment mode = Vanity](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-luwtsekg.png) ## Step 2 — Vanity limits The **Vanity limits** tab sets the slot sizes and the per‑slot caps: ![Vanity limits](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-abzudfqc.png) | Field | Meaning | |-------|---------| | **Website quota** | Disk for the `name.` website. `0` = no website (skip the web role). | | **Mailbox quota** | Disk for the single `name@` 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**: ![Vanity config options](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-wmd82t9m.png) 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: ![WHMCS admin — vanity service](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-lzbkhdhe.png) 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](https://puqcloud.com/)** ##### [Order now](https://puqcloud.com/) | [Download](https://download.puqcloud.com/WHMCS/servers/PUQ_WHMCS-WEB-Hosting/) | [Community](http://community.puqcloud.com/) 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. ![Vanity order — choose name](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-myonrpqt.png) 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: ![Vanity order — name taken](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-ncvhqgtj.png) A free name turns green and unlocks **Continue**: ![Vanity order — name available](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-vcxlzg7p.png) ## 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: ![Vanity checkout](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-lallujan.png) ## 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: ![Vanity client dashboard](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-iwh2njhu.png) 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: ![Vanity client sidebar](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-oumoqi1l.png) ### 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. ![Vanity mailbox settings](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-t4zucrsz.png) 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)."* ![Admin — vanity service overview](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-qyiu5gpa.png) The SSL tab confirms it — only the **website** certificate is shown; mail SSL belongs to your provider mail domain, not to each slot: ![Admin — vanity SSL](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-y8gf324y.png) > 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](https://puqcloud.com/)** ##### [Order now](https://puqcloud.com/) | [Download](https://download.puqcloud.com/WHMCS/servers/PUQ_WHMCS-WEB-Hosting/) | [Community](http://community.puqcloud.com/) 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. ![Vanity shop widget landing](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-m2avryoh.png) ## 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**: ![Vanity widget config](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-nnrdznhw.png) 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: ![Vanity widget download](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-vnykkn7o.png) > **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: ![Widget — reserved name](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-mlvj6bo8.png) A free name turns green and enables the button: ![Widget — available name](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-vojy9gxn.png) On **Get it now** the button shows a spinner while it redirects… ![Widget — going to checkout](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-5s4tkuvk.png) …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: ![Widget — lands on WHMCS checkout](https://doc.puq.info/uploads/images/gallery/2026-06/embedded-image-pvjqq502.png) > 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.