Why CNAME-based portals matter (and the hostage problem most platforms create)
When your customers’ portals live on your domain, you hold their identity. That’s leverage that’s bad for them and bad for you long-term.
By Kuhler · Editorial
There’s a hidden choice in every B2B platform that serves end-customers: where does the end-customer’s portal live? On your subdomain (manufacturer.io/customer-name), or on theirs (portal.customer.com)?
It looks small. It isn’t. The choice cascades into trust, leverage, and renewals.
The hostage problem
When your customer’s portal lives on your subdomain, you hold their identity. They can’t leave without their own customers noticing the URL change. They can’t move to a competitor without breaking links and bookmarks. You have leverage at every renewal — and they know it.
Some platforms exploit this. Renewal prices creep up. Feature gates appear. Migration paths get mysteriously complex. The platform’s incentive isn’t to delight you; it’s to make leaving expensive.
White-labeling under the customer’s domain isn’t a feature. It’s a posture.
Why CNAME flips the dynamic
When the portal lives at portal.customer.com, the customer owns the URL. They’ve told their own customers to bookmark it. They control the DNS record. Pulling the CNAME deactivates the portal in seconds — no one else needs to be involved.
That’s scary for vendors who built their business on lock-in. It’s liberating for vendors who plan to earn renewals on the merits.
What it takes to do this right
- Auto-issued SSL via Let’s Encrypt — manual cert management at scale doesn’t work
- Real per-tenant branding — color, logo, contact info isolated per customer
- Postgres row-level security so one customer never sees another’s data
- API + export — the customer can pull their data on the way out
It also takes a posture decision: that you’re willing to make leaving easy. That decision compounds over years. Customers who feel free to leave tend not to.