{"id":6252,"date":"2026-09-10T11:36:09","date_gmt":"2026-09-10T08:36:09","guid":{"rendered":"https:\/\/www.scalahosting.com\/kb\/?p=6252"},"modified":"2026-09-10T11:36:09","modified_gmt":"2026-09-10T08:36:09","slug":"client-login-own-domain-hosting","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/kb\/client-login-own-domain-hosting\/","title":{"rendered":"Let Your Clients Log In at Their Own Domain – Not Yours"},"content":{"rendered":"\n

When you enable branding on an SPanel server, every site you host serves its own login page. A client whose website is client-site.com signs in at client-site.com\/hostpanel\/login – their domain, your logo, your company name, no shared server address to memorize. <\/p>\n\n\n\n

SPanel is ScalaHosting’s control panel, included free on every managed VPS. This client-facing login experience is the default once branding is on, not something you assemble per account.<\/p>\n\n\n\n

A login URL the client actually recognizes<\/strong><\/h2>\n\n\n\n

Picture a 12-client design agency in Manchester. They build sites, host them, and handle the email. Every month, a client emails support asking, “What’s that login address again? And what is SPanel?” The agency has spent years being the client’s single point of contact, and a stray server hostname in the address bar quietly undoes that.<\/p>\n\n\n\n

That awkward question has a precise cause: the login URL. On many setups, clients sign in at a shared panel hostname that belongs to the infrastructure provider, on a path that names the panel software. The brand the client sees at the door is not the agency’s. This article is about closing that one gap and why the login URL is the most underrated white-label detail there is.<\/p>\n\n\n\n

What “log in at your own domain” actually means<\/strong><\/h2>\n\n\n\n

With branding enabled, every domain on the server receives its own login page at the client’s domain plus the neutral \/hostpanel path, so each client signs in somewhere they already recognize.<\/p>\n\n\n\n

There’s no per-client setup behind this. Because SPanel is reachable through every hosted domain, the moment you create an account for client-site.com<\/em>, that domain answers at client-site.com\/hostpanel\/login<\/em> with your company name and logo. No shared panel.youragency.net<\/em>, no IP address, no instructions that read like a server manual.<\/p>\n\n\n\n

The webmail entry point follows the same branded URL, so a client moving between the panel and their inbox never lands on a vendor address. So does the API endpoint, which matters if you automate account creation: your scripts and the panel speak to the same neutral path. That behavior is documented in the official SPanel API documentation<\/a>.<\/p>\n\n\n\n

Why the login URL is the sharpest differentiator<\/strong><\/h2>\n\n\n\n

Here’s the part most reseller guides skip. <\/p>\n\n\n\n

On the most widely used legacy panel, the login page itself cannot be rebranded. Resellers can change logos inside the panel and on the webmail screen, but the main sign-in page stays the vendor’s, a limitation documented by cPanel-ecosystem hosts themselves, including InMotion Hosting’s support material. <\/p>\n\n\n\n

Even worse, the “log in to your panel” button in many billing setups sends clients to the upstream provider’s domain. One curious client, one search, and they can easily find who really runs their hosting and what it costs.<\/p>\n\n\n\n

SPanel handles the login page the other way around: the client’s own domain is the front door, branded, by default. That single difference is what turns “I resell someone’s hosting” into “I run a hosting company.”<\/p>\n\n\n\n

What the client sees<\/td>Typical legacy-panel reseller setup<\/td>SPanel with branding enabled<\/td><\/tr>
Login URL<\/td>shared provider hostname or panel address<\/td>the client’s own domain + \/hostpanel\/login<\/td><\/tr>
Login page brand<\/td>the panel vendor’s name and logo<\/td>your company name and your logo<\/td><\/tr>
Login path<\/td>often names the panel software<\/td>neutral \/hostpanel, reveals nothing<\/td><\/tr>
New domains<\/td>branding re-applied each time<\/td>inherited automatically<\/td><\/tr>
Webmail entry<\/td>may bounce to a vendor URL<\/td>follows the branded URL<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

If you run client hosting and want the login page to carry your brand instead of a vendor’s, SPanel’s branding is included on every ScalaHosting managed VPS, with no separate white-label tier to buy.<\/p>\n\n\n\n

It’s the default, not an assembly project<\/strong><\/h2>\n\n\n\n

The win is that it costs nothing to maintain. Set it once from the Admin Interface’s Branding screen: enter your brand name, upload your logo, and set the Login URL to the neutral \/hostpanel path. SPanel writes the branded login into the web configuration for every domain already on the server, and every domain you add afterward inherits it. New accounts, addon domains, subdomains, and main-domain changes all generate their configuration with your brand already in place.<\/p>\n\n\n\n

That config also survives the upgrade cycle. SPanel’s updater reasserts the branded URL in the configuration it regenerates, webmail login and logout links included, so an update never resets you to the default \/spanel path. <\/p>\n\n\n\n

Demo flow<\/strong><\/h2>\n\n\n\n

The Admin Interface steps that produce the screenshots, in order.<\/p>\n\n\n\n

    \n
  1. Log in to the SPanel Admin Interface<\/strong> as the server administrator. Under Accounts Management<\/strong>, create an account for the client with the needed username and password. Submit<\/strong> the form.<\/li>\n<\/ol>\n\n\n\n
    \"Let<\/figure>\n\n\n\n
      \n
    1. In a fresh browser session, visit the client’s own domain at the branded path: client-domain.com\/hostpanel\/login<\/em>. The page shows their company name and logo.<\/li>\n<\/ol>\n\n\n\n
      \"Let<\/figure>\n\n\n\n
        \n
      1. Sign in as the client<\/strong> and land on the User Interface<\/strong> dashboard. Email, files, and databases all sit under the reseller’s brand, reached from the client’s own domain.<\/li>\n<\/ol>\n\n\n\n
        \"Let<\/figure>\n\n\n\n
          \n
        1. From the dashboard, open the webmail entry point. The link stays on the branded URL rather than bouncing to a vendor address.<\/li>\n<\/ol>\n\n\n\n
          \"Let<\/figure>\n\n\n\n

          Where the brand still needs your help<\/strong><\/h2>\n\n\n\n

          Honest scoping, because the login page is one touchpoint of several. The branded path is the neutral \/hostpanel. It reveals nothing about the panel software, but it is not a free-form custom string, and that neutrality is what lets every new domain inherit it automatically. <\/p>\n\n\n\n

          Two settings outside the login experience complete the picture: the server hostname<\/strong> (set one on your own domain, like server1.youragency.com, so mail and FTP settings carry your brand) and branded nameservers<\/strong> (ns1\/ns2 on your domain for client DNS). SPanel supports all three; together they leave no infrastructure vendor visible. <\/p>\n\n\n\n

          A few embedded tools, like the webmail client’s own interface, an application installer (like Sotaculous), or phpMyAdmin, keep their own product names, as they do in every hosting panel. <\/p>\n\n\n\n

          See it on a real server<\/strong><\/h2>\n\n\n\n

          If you run client hosting, the login URL is the first thing your clients see and the easiest brand leak to close. SPanel makes the client’s own domain the front door by default, free on every ScalaHosting managed VPS. ScalaHosting reports its platform powers over 700,000 sites across more than 120 countries<\/a>. Walk the agency-flavored version in our branded client tour, and if there’s a branding behavior you’d like to see next, the Cloud Democracy<\/a> Project is where users ask and vote for new features.<\/p>\n\n\n\n

          FAQ<\/strong><\/h2>\n\n\n\n

          Q:<\/strong> Where exactly do my clients log in after I enable branding?<\/strong> <\/p>\n\n\n\n

          A:<\/strong> At their own domain plus the branded path – for example client-site.com\/hostpanel\/login. Every hosted domain serves the branded login page, so no shared server address appears in any client instruction.<\/p>\n\n\n\n

          Q:<\/strong> Do I have to set this up for each client?<\/strong> <\/p>\n\n\n\n

          A:<\/strong> No. Enable branding once from the Admin Interface. New accounts, addon domains, and subdomains all generate their web configuration with the branded login already applied.<\/p>\n\n\n\n

          Q:<\/strong> Can clients of a legacy panel log in at their own domain like this?<\/strong> <\/p>\n\n\n\n

          A:<\/strong> Generally not for the main login page. On the most common legacy panel the sign-in page cannot be rebranded, and billing integrations often route the login button to the provider’s domain.<\/p>\n\n\n\n

          Q:<\/strong> Can I use a fully custom path like<\/strong> \/mypanel?<\/strong> <\/p>\n\n\n\n

          A:<\/strong> No. The Login URL setting offers two choices, the default \/spanel and the branded \/hostpanel, not a free-form custom string. The neutral \/hostpanel reveals nothing about the panel software, is inherited by every new domain, and survives panel updates, webmail links included.<\/p>\n\n\n\n

          Q:<\/strong> Does this cost extra?<\/strong> <\/p>\n\n\n\n

          A:<\/strong> No. Branding is included free on every ScalaHosting managed VPS, like every SPanel feature. There’s no white-label surcharge and no per-account fee.<\/p>\n\n\n\n

          Q:<\/strong> Is hiding the panel name a security feature?<\/strong> <\/p>\n\n\n\n

          A:<\/strong> Treat it as reduced fingerprinting, not security. The real security story is SShield and the hardening stack.<\/p>\n\n\n\n