Putting several websites on one VPS can be practical, especially when they belong to one business. The arrangement needs more care when different customers share the machine. Plan ownership and capacity before adding the next site.
Map each request correctly
Every domain needs the intended DNS records, web configuration, document root and certificate. An alias points to an existing website rather than providing another independent application. A subdomain may carry its own workload.
Do not copy configuration without checking ownership and runtime compatibility. Verify PHP and database access at the destination. Seeing a default landing page proves very little about the real application.
Plan capacity and maintenance together
Quiet websites may become busy together during a campaign or backup. Set resource policy and PHP concurrency with headroom for shared services. More domains do not create more reserved CPU or RAM.
Stagger maintenance where appropriate and measure the result. Check disk space and inode use as well as memory. Customer mail and retained archives grow independently of website traffic.
Keep each site recoverable
Know which backup contains its files and database and test recovery elsewhere. Recheck certificates, scheduled jobs and mail after a move. Keep the source available while DNS caches and mail routing settle.
EzePanel connects domains, DNS, SSL, PHP, databases and files within ownership boundaries. Its license account allowance and package website allowance are separate. Plan both against actual server capacity before selling additional hosting.
Separate owners before adding domains
Separate customers should have separate hosting accounts. Related sites may share an account, but they also share its access and resource budget. Adding another domain is not creating an independent tenant boundary.
Record document roots and database logins. Avoid sharing database passwords across customers. Scope deployment access to the intended account and review backup coverage when adding a site.
Move a website without accidentally moving mail
Create the destination account and hosting-side domain before publishing DNS changes. Verify root, PHP runtime and database connection. Review MX records separately: a website move does not necessarily move mail routing or mailbox history.
Test the destination privately before cutover. Retain source data until website, forms and required mail checks pass. DNS caches and sessions complicate moves, so document which system should be authoritative at each step.
Revisit capacity after onboarding
A static site and an uncached PHP shop are not equivalent capacity units. Include cron, administration and backup workloads. Stagger expensive work where useful and measure actual pressure after onboarding.
Compare EzePanel’s licensed account ceiling with the tenant package allowances. More permitted accounts do not reserve CPU for each one. Adjust application behavior or server capacity using evidence rather than increasing counts alone.
A practical ownership plan for multiple Ubuntu websites
Consider a hypothetical operator with its own company site and three unrelated customer sites. The company can decide how to group its related domains, while each customer needs an appropriate independent ownership boundary. Do not share one customer login merely to reduce the apparent account count.
Create packages before accounts, then review the effective policy for each customer. In EzePanel, domain and PHP changes should follow the intended account and domain selection. Check the second account cannot see the first account’s database or files, and include recovery headroom in capacity planning.
Where to go next
Sources & further reading
Official documentation for the topics in this guide. Check current vendor requirements before a purchase or server change.
