For a web studio or marketing agency, a VDS server allows for the collection of client websites in one managed environment. Here, you can host working projects, test copies, databases, and internal team tools without creating a separate infrastructure for each small order. However, a shared server does not mean shared passwords, directories, and resources without limits. Otherwise, a failed update of one plugin, an infected file, or a heavy product import will affect not just one site, but the entire group.
Most often, the problem arises not from insufficient VPS power. Websites are launched from one system user, connect to databases through a shared account, and fall into one large backup archive. Initially, this scheme seems convenient. Over time, it becomes clear that a separate project cannot be safely stopped, restored, or transferred to another developer without touching the rest of the infrastructure.
How to separate client projects within one VPS
Each site should be perceived from the start as a separate object. It should have its own files, database, logs, settings, and resource usage limits. Then it can be updated, moved, or restored independently of neighboring projects.
The basic hosting scheme should be standardized and applied to all new clients:
-
create a separate system user, directory, and PHP pool for each site;
-
use a separate database and account without access to others' tables;
-
set limits on memory, CPU time, number of processes, and disk space;
-
separate working and testing environments;
-
maintain separate error and request logs for each project;
-
do not store passwords and access keys in open files or shared team tables.
A separate system user is needed not only for order in directories. If several sites are launched with the same rights, a malicious script on one of them can read or modify files of neighboring projects. Recommendations for WordPress security also advise limiting file system rights and not allowing processes to write where it is not needed.
It is equally dangerous to connect all sites to databases through one user with broad rights. Compromising one configuration file in this case opens access to the data of other clients. For each CMS, a separate account should be created and allowed to work only with the corresponding database.
Also read: Infrastructure as Code on VPS: how to simplify infrastructure management
Limit resources for individual sites
One store during a nightly import can take up all available memory or launch so many processes that the other sites start responding slowly. The store itself may remain accessible, so the cause of the problem is not always found immediately.
Limits should not be too strict. Their task is not to slow down the project, but to prevent one process from uncontrollably using the entire server. After launching a new site, it is advisable to monitor the load for a few weeks and then set limits with a reasonable margin.
Grant access only to the necessary project
A shared root password known to all developers and contractors deprives the agency of control. It is impossible to determine who made changes, quickly revoke access from one person, or limit their work to a specific site.
To manage access, it is advisable to establish several rules:
-
issue personal SSH keys instead of one password for the entire team;
-
do not provide root access if the specialist has sufficient rights to a separate directory;
-
maintain a list of active accesses with the date of issuance and responsible person;
-
delete accounts and keys after the work is completed;
-
check quarterly who still has access to the server and control panels;
-
use two-factor authentication for accounts with extended rights.
An external SEO specialist usually needs CMS, analytics, and search consoles, but not the file environment of the entire VPS. A content manager does not need access to the database, and a developer of one site should not see the directories of other clients. This corresponds to the principle of least privilege: the user receives only those rights without which they cannot perform their work.
Protect staging as securely as the production site
If staging is hosted in one account with other sites, its hack can open access not only to the test copy. An attacker can reach neighboring directories, find configuration files with passwords, or modify files of other projects.
Therefore, access to staging should be restricted by password, IP addresses, or a private network. Disallowing indexing in robots.txt from external visitors does not provide protection.
Also check integrations: the test version should not send real emails, process payments, create deals in CRM, or change product stock.
How to maintain infrastructure after launch
Well separating sites at the start is not enough. The number of clients grows, new modules appear in projects, contractors and update schedules change. Without regular monitoring, even a neatly organized VPS gradually turns into digital jungles, where no one knows which processes are running and who has access.
Set up separate backups for each site
One backup of the entire VPS is convenient for restoring the server after a complete failure, but poorly suited for the daily work of the agency. If one project breaks due to a failed update, you cannot roll back together with it another fifteen functioning sites.
The working backup scheme should take into account:
-
separate copies of files and databases for each client;
-
the frequency of copying according to the pace of information updates;
-
keeping at least one copy outside the main VPS;
-
encryption of archives with personal data;
-
automatic monitoring of task completion and file sizes;
-
periodic test restoration in a clean environment.
The frequency of backups is determined not by the size of the site, but by the amount of information that can be lost. A corporate resource where news is published a few times a month may suffice with a daily copy. For a store with constant orders, one backup a day already means the risk of losing a significant part of operations.
Track which site creates peak load
One resource-intensive site can slow down all projects on the server. The cause is often product imports, backups, cron jobs, bot traffic, or plugin errors.
Set up alerts for CPU and memory spikes, disk filling, 5xx errors, and response time increases. When you find the source of the load, stop the problematic process and check logs, plugins, cron, and database queries.
If the load is caused by an error, it needs to be fixed. If the site really requires more resources, limit its consumption or move it to a separate virtual server so it does not affect other clients.
Maintain a technical card for each project
When an agency services many sites, important information should not remain only in the head of one developer. For each project, it is advisable to record the PHP version, database location, connected external services, backup schedule, responsible specialists, and emergency recovery procedures.
It is also useful to note which processes create the most load. If it is known that a store imports a catalog daily at 03:00, the team will not have to investigate a short spike in CPU usage each time. And if the load appears at another time, it can already be considered an anomaly.
Also read: Virtual servers in development: how to make life easier for programmers
The technical card should be updated after changing server configuration, connecting a new integration, or transferring the project to another team. This simplifies maintenance and reduces recovery time after an error.
When to move a client site to a separate server
Increasing the configuration of the entire VPS due to one heavy site is not always cost-effective. The agency starts paying for additional resources for the entire group, although they are mainly consumed by one client. In such a situation, it makes more sense to separate the project.
Downtime for the project has a high cost
A small business card site and an online store through which most of the company's sales pass should not have the same hosting model just because both run on WordPress. For a critical service, separate backups, a dedicated resource pool, and the ability to perform maintenance independently of other clients are important.
For a large store, portal, or system with significant data volumes, the next step may be renting a dedicated server. However, the decision should not be tied to the number of domains. Dozens of simple sites sometimes require fewer resources than one catalog with complex filters, search, stock synchronization, and constant file processing.
The project regularly consumes a significant portion of resources
If one store uses half of the VPS memory on a regular day, during a sale, advertising campaign, or mass import, there will be no resources left. It is better to plan the move before the peak period, leaving time for testing, database synchronization, and DNS updates.
Before migration, check if the load can be reduced through caching, query optimization, queues, or changing the schedule of background tasks. A separate server will not fix slow code, although it will give it more resources.
The site requires a special software environment
One client may require a different version of system libraries, its own web server, non-standard modules, or a separate update schedule. Adapting a shared VPS for it is risky: changing the configuration can disrupt the operation of other sites.
A separate environment is also appropriate when the client wants administrative access. Granting it to a server where third-party projects are hosted is not possible even with good relations and signed agreements.
One VPS can remain a convenient hub for client sites for years. Stability depends not on maximum power reserves, but on the rules by which the agency creates projects, grants access, configures backups, and responds to load increases. When these processes are documented and executed consistently, one client's problem does not turn into a shared disaster.