TOOLNAVIA / BUYING GUIDE

ScalaHosting Entry Cloud: Addon Domains or Separate Accounts?

The short answer

Entry Cloud's unlimited website count does not decide how clients should log in. Several addon domains can live inside one SPanel hosting account, while separate SPanel user accounts provide separate credentials and quota controls. Choose that structure around ownership and handoff; neither option creates a fresh server for every client.

At a glance

Best for
Small client portfolios with deliberate credential and account boundaries.
Price model
Verify current Entry Cloud term and renewal; account organization does not add compute.
Check first
Accounts share the same server pool; sub-users are not separate hosting accounts.

Choose the account boundary before adding domains

ScalaHosting's addon-domain guide describes an additional website with its own document root inside the same hosting account. A separate public domain can look independent to visitors while remaining part of one operator's control-panel account.

That can fit several sites owned and maintained by the same organization. It is a less comfortable default when unrelated clients each expect their own hosting login, resource budget and departure process. A new domain name is a routing and content decision; a hosting account is also a management decision.

The small-business page says Entry Cloud can host unlimited websites, while the reseller page advertises managing unlimited accounts. These are complementary administrative claims, not interchangeable descriptions of a single login. Confirm that the actual Entry Cloud order exposes the intended SPanel account-management functions.

![Choose the boundary,not the domain count](/static/article-images/scalahosting-entry-cloud-addon-domains-vs-separate-spanel-accounts-1-en.svg)

Use separate accounts for separate client responsibility

ScalaHosting documents creating a SPanel user account from the Admin Interface, assigning its main domain and its own login credentials. It also supports package or custom limits. That gives an agency a clearer unit for a client's hosting work than a folder under an unrelated client's account.

Its quota documentation covers storage, inodes, addon-domain counts, email accounts and databases. Record what the agency has promised each client and how those limits will be monitored. A configured limit is an operating control; it is not a separate physical server or a guarantee that every application inside the account performs well.

Creating another account does not automatically move existing files, databases, mail or credentials into it. If a client already lives as an addon domain, plan the actual transfer and acceptance separately. Confirm DNS, HTTPS, database access and mail routing before retiring the previous arrangement.

Use sub-users when one account is the right unit

SPanel also supports sub-users inside a hosting account. The owner chooses permitted User Interface tools, such as email, databases, domains, files or backup controls, and can later edit or revoke that login. This helps a collaborator work without sharing the main account credential.

It does not create another hosting account. In particular, a permission to use a tool is not automatically proof that the person can see only one addon domain or one directory. Verify the current tool's actual scope before giving it to a client who expects site-only access.

A mail operator inside an owner-run account may need only selected mail tools. An unrelated client expecting independent hosting administration is a different requirement. Keep those cases separate instead of granting broad file or restore controls merely because a person has a unique username.

![Client responsibility needs an explicit unit](/static/article-images/scalahosting-entry-cloud-addon-domains-vs-separate-spanel-accounts-2-en.svg)

Choose the boundary,not the domain count
Three SPanel structures serve different needs

Keep one aggregate resource budget

The current Entry Cloud base lists2CPU cores,2GB RAM and50GB NVMe. Those figures describe the server plan, not a new allocation for every website or user account. Account organization can improve responsibility and limit-setting while all workloads still draw from that shared aggregate pool.

For illustrative disk planning, five8GB account limits sum to40GB. The nominal difference from50GB is10GB before accounting for operating-system and service requirements, logs and the actual storage treatment of mail or backups. It is not a guarantee of10GB free. Inspect current usage and leave operational headroom.

Monitor aggregate pressure and the clients creating it. If memory,CPU or storage is the measured constraint, reorganizing logins does not add capacity. Conversely, a larger plan does not by itself correct a client who received access to someone else's hosting account. The [existing workload guide](/en/hosting/scalahosting-entry-cloud-2gb-vs-build1-term) covers the separate resource decision.

![One aggregate pool still serves the portfolio](/static/article-images/scalahosting-entry-cloud-addon-domains-vs-separate-spanel-accounts-3-en.svg)

Client responsibility needs an explicit unit
Choose by ownership and handoff

Compare the access model across providers

Hostinger's current guide distinguishes account sharing for all websites under a plan from single-website collaborators on Agency hosting, and limited FTP/MySQL access. A collaborator label does not mean the same scope on every product. Check the actual plan and task.

cPanel/WHM similarly distinguishes reseller-managed accounts from ordinary cPanel users; the provider controls reseller privileges and account limits. Its documentation is a useful account-model comparison, not evidence that ScalaHosting uses cPanel or grants identical controls.

Namecheap's resource guide separates reseller aggregate limits from the limits of one resold account. That helps frame the capacity question, but those LVE numbers are not Entry Cloud entitlements. Compare account structure, quotas and aggregate resources independently.

Rehearse client handoff and recovery scope

Before migrating a portfolio, have an authorized administrator use two disposable projects to verify each intended login. Confirm which domains,files,databases and mail controls each person can reach, and whether revoking one collaborator affects other users. A unique credential is useful only if its scope matches the promise.

Also confirm the actual backup/export and restore unit. A backup permission appearing in a sub-user grid does not prove every client can independently restore only their own addon domain. Rehearse a harmless export or recovery on a controlled copy and check that unrelated projects remain intact. These are proposed checks; Toolnavia did not operate SPanel or restore a site.

![Accept handoff and restore scope first](/static/article-images/scalahosting-entry-cloud-addon-domains-vs-separate-spanel-accounts-4-en.svg)

Choose addon domains when the sites share one owner and operating boundary. Choose separate SPanel accounts when clients need distinct credentials, quotas and handoff units. Choose a sub-user for selected work inside an account that should remain one unit. Then budget the exact current term,renewal and operator work before [reviewing Entry Cloud at ScalaHosting](https://www.scalahosting.com/#jbo732m8svf2o). The link opens the provider homepage; select the intended plan and term. Toolnavia may earn a commission from eligible purchases.

One aggregate pool still serves the portfolio
Current Entry Cloud base,not per account
Accept handoff and restore scope first
No SPanel account or migration operated