Features
Point app, shop, docs or staging anywhere you like and get a genuine, fully isolated site behind it: its own stack, database, cache, backups and resource cage. Full DNS record control, automatic SSL including wildcards, and one-click staging subdomains.
On most hosts a subdomain is a directory with a rewrite rule in front of it. Here it is a first-class site record with its own blueprint version, its own placement on the fleet and its own isolation boundary. Whatever you can do to a primary domain, you can do to a subdomain.
Each subdomain site is built from a versioned blueprint and runs its own stack type and runtime: managed WordPress, WooCommerce, PHP, static HTML or Node. Your docs subdomain can be static HTML while the root runs WordPress, with no compromise between them.
A MariaDB database per site, LiteSpeed LSCache full-page caching and a per-site Redis or Memcached object cache. Nothing is shared with the parent site, so a heavy subdomain cannot evict the parent's cache or crowd its queries.
CloudLinux LVE caps CPU, RAM, IO, IOPS and entry processes per site, CageFS gives each site its own filesystem view, and MySQL Governor throttles per-site database load. A runaway subdomain is contained inside its own cage.
Daily backups held for 30 days with one-click restore, per site. You can roll a subdomain back to yesterday without touching the parent site or any of its siblings.
Subdomains are a DNS problem before they are a hosting problem, so the DNS layer is exposed properly rather than hidden behind a form with two fields.
Every registrable domain you host gets a DNS zone managed through our DNS driver seam. You get record CRUD across the record types you would expect, so adding app, shop, docs, mail or a wildcard host is a record edit, not a support ticket. Zone state is reconciled idempotently against the provider, which means a half-applied change or a retried edit converges on the state you asked for rather than leaving your zone in an ambiguous middle.
On Mainstream plans domains delegate to our branded PowerDNS nameservers, ns1 and ns2 at zinndigital.com, by default. That is a default, not a requirement. Registrar and DNS are deliberately decoupled: you can register a domain with us and keep DNS elsewhere, or keep the domain at your existing registrar and simply point a subdomain at us. We verify nameserver delegation and activation before we call a domain live, so you find out that a record is wrong from the platform rather than from a customer.
A subdomain that is slow or shows a certificate warning is worse than no subdomain at all, so the delivery path is the same one the primary domain gets.
Let's Encrypt certificates are issued and renewed automatically. Use a wildcard certificate to cover every subdomain at once, per-host certificates where you want them separated, or upload your own custom certificate.
Every site is served by LiteSpeed with HTTP/3 enabled, so a subdomain gets the same connection-level performance as the root domain rather than a second-class vhost.
LSCache full-page caching plus a per-site Redis object cache, with coordinated purge from the dashboard or from inside WordPress. Purging the parent does not blow away your subdomain's cache.
Deploy through our CDN and Cloudflare account pool or connect your own accounts and choose which account a given site deploys to. Delivery is a decision you make, not one we make for you.
The most common reason to want a subdomain is to have somewhere safe to break things. That path is built in and ungated on Mainstream plans.
Clone to staging creates an isolated copy of a live site on a staging subdomain, with its files and database intact, on the same stack and blueprint version as production. You work on the copy with the full toolset: jailed SSH and SFTP, wp-cli, the browser-based VS Code editor, phpMyAdmin or Adminer, per-site cron and environment variables.
When the change is proven, push to live performs a database-aware sync back to production. You choose files, database or both, and the search-replace is handled for you so the URLs in your content follow the site rather than pointing back at the staging host. Because provisioning, cloning and deployment all run as durable Temporal workflows with per-step retries and compensation, a failure part-way through unwinds the partial work rather than leaving you with a half-cloned site.
We would rather tell you this up front than sell you something that undermines what you are trying to do.
Subdomains are the right answer for structuring one brand: an app, a shop, a docs site, a customer portal, a per-client staging environment. They are the wrong answer for a private blog network. Every subdomain shares a single registrable domain, so anyone who resolves one of them knows exactly who owns the rest. Under a wildcard certificate they also share a certificate, and certificate issuance is published to public Certificate Transparency logs, so hosts under a shared domain are enumerable by anyone who cares to look. That is a property of the public web PKI and DNS, not of our platform, and no hosting configuration changes it.
So subdomains sit in our Mainstream and Agency lines, not the Footprint-Free one. If your requirement is that sites must not be linkable to one another, you need separate registrable domains on the footprint-free product line, where the CDN and DNS account pools, footprint management and static-HTML delivery exist precisely to break that pattern. Both live on the same engine and the same dashboard, so choosing correctly costs you nothing in convenience.
Agencies and resellers use subdomains at volume: a staging host per client, a preview host per project, a portal per account. The platform is built for that shape of work.
Organisations nest as a tree, reseller to client to sites, and every record is scoped and enforced at the database with row-level security. A client's subdomains belong to that client's organisation, not to a shared bucket you have to police by convention.
Group related sites so a portfolio moves together. Deploy, update and manage many sites in one action instead of repeating yourself once per subdomain.
Everything in the dashboard is in the public API, generated from the OpenAPI specification. Drive subdomain creation from an org-scoped API key, the CLI, Terraform, or an AI tool over our MCP server.
Privileged and administrative actions are audit-logged, and role-based access control governs who on your team can do what. You can see who created, changed or removed a host.
Yes. Because each subdomain runs as a full, separately isolated site with its own stack, database, cache and backups, it occupies a site slot on your plan in the same way a primary domain does. Plans are sold by the number of sites they cover, so adding a subdomain site is the same accounting as adding any other site.
They are covered automatically either way. You can issue a wildcard certificate that covers every host under the domain at once, or issue per-host certificates where you want them kept separate. Let's Encrypt certificates are free, issued and renewed automatically, and you can upload a custom certificate instead if you have one.
We would advise against it, and we will not sell it that way. Every subdomain shares one registrable domain, and under a wildcard certificate a shared certificate whose issuance appears in public Certificate Transparency logs, so the hosts are linkable to one another by anyone who looks. For work where sites must not be connectable, use separate registrable domains on our Footprint-Free line, which is engineered specifically for that with CDN and DNS account pools, managed footprints and static-HTML delivery.
The platform is built to contain it rather than let it spread. CloudLinux LVE caps each site's CPU, memory and IO inside its own cage, CageFS gives each site an isolated filesystem view so a breach is contained, and MySQL Governor throttles per-site database load so one site's heavy queries do not slow the server. Real-time malware scanning, a proactive web application firewall and per-site immutable backups back that up. Containment is the design goal; no host can promise that a compromise is impossible.
Yes. Registrar and DNS are deliberately decoupled. You can keep your domain at your current registrar and your zone at your current DNS provider and simply point a subdomain's record at us. We verify the delegation and activation before treating the site as live, so a mistyped record surfaces immediately rather than silently failing.
Only in how it is created. Clone to staging builds an isolated copy of a live site, files and database included, on a staging subdomain running the same stack and blueprint version as production. When you are happy, push-to-live syncs it back with a database-aware search-replace. Everything else, isolation, SSL, caching, backups and developer access, is identical to any other site.
You take them with you. There is no lock-in anywhere in the platform: you can retrieve auth codes, unlock domains and transfer them out, bring your own CDN and DNS accounts, and export your sites. Every external provider we use sits behind a swappable adapter, which is as true for you as it is for us.
Full isolation, wildcard SSL, real DNS control and one-click staging on every host you add. Start on a card-free 7-day trial and see how it fits before you commit.
Start free