Start with the operating requirements
Before comparing configurations, collect each project's application stack, database, uploads, scheduled tasks, integrations and expected changes. Identify who needs content access, deployment access and host administration. These are different jobs. A client editing a page may need only an application account; a contractor maintaining the operating system needs substantially broader authority.
Also record the acceptable maintenance window, who approves downtime, where recovery copies are held and who pays for operational work. Note any client requirement for a separate server or account as a decision constraint. A resource spreadsheet cannot settle an ownership or access requirement.
- Name the primary operator and a replacement for each project.
- List shared dependencies: DNS access, deployment credentials, database services and backup destinations.
- Mark unknown requirements for a client decision before committing to the arrangement.
Choose the access boundary before the server size
OWASP recommends granting only the permissions needed for a person's job and validating that the intended restrictions hold. Apply that principle to the hosting plan: use individual identities, project-specific application credentials and a documented deployment path. A directory named after a client is an organizational aid, not an access policy.
If using Docker, treat access to its daemon as a host-level responsibility. Docker's security documentation explains that a trusted daemon operator can mount and modify host files. Giving an external contractor unrestricted Docker control is therefore a poor match for a host containing an unrelated client's data.
Separate VPS instances allow separate operating-system administration and release decisions. They still require careful permissions within each project. Common agency credentials or a shared deployment account can reconnect the risks you intended to separate.
Work through two fictional client briefs
The clients below are fictional examples, not customer histories. The agency operates both projects today, but their access and timing requirements differ.
Placing these two projects together would make Morrow's contractor access and launch schedule part of Aster's operating risk. The separate-server decision follows those constraints; it does not claim that Morrow needs a particular number of CPUs or that Aster is risk-free.
Scroll horizontally for all table columns.
| Decision factor | Aster Furniture: brochure site | Morrow Workshops: registration site |
|---|---|---|
| Workload | Public pages and occasional content updates | Forms, a database and scheduled registration exports |
| Access | Client edits content; agency deploys | External developer needs host administration |
| Maintenance | An agreed evening window | No planned changes during a booking launch |
| Incident impact | A temporary page outage can be discussed | Lost or duplicated submissions require investigation |
| Exit requirement | Export content and move the application | Transfer an independently operated environment |
| Provisional decision | Consider sharing with compatible agency-run sites | Use a separate VPS and separate project credentials |
Compare the full cost of both arrangements
Build two budget versions using the current configurator: one shared configuration and one configuration per project. For each, list the hosting total for the selected period, recurring options, external services and agency maintenance time separately. Avoid copying an old price into the client brief. Record when the configuration was prepared and who approved the allocation.
For a shared host, agree how clients divide fixed costs and what happens when one leaves or requires an upgrade. Equal shares are simple but may be unsuitable when one project causes most storage growth or operational work. Separate servers make attribution clearer while adding separate patching, monitoring and recovery tasks.
Leave resource headroom for releases, backups and temporary work. Docker containers have no CPU or memory constraints by default; configure appropriate limits and assess the combined workload. A container list alone does not demonstrate a viable resource budget.
Make maintenance and recovery project-specific
On a shared host, an operating-system restart affects every resident project. Put host maintenance on a common calendar and identify who contacts each client. Keep application releases separate where practical, and avoid scheduling one project's data export during another's important launch.
Recovery notes should identify a project's database, files, configuration and required credentials without copying secrets into the notes. Plan restoration to a separate test destination. Restoring an entire shared host as the first response could replace healthy changes belonging to the other client.
With separate VPS instances, record the shared services that remain. A common DNS account, backup destination or operator can still affect both projects. Server separation is not evidence of independent physical infrastructure or guaranteed availability.
Validate the arrangement and set review triggers
Before accepting the arrangement, have a second operator check that a project identity can perform its assigned work and cannot read the other project's files, backups or secrets. Review database permissions and deployed credentials as well as application screens. Use harmless test data in an agreed environment; do not probe another client's production data.
Record the outcome as accepted, rejected or awaiting a named correction. If isolation cannot be demonstrated, narrow the access or move the project before granting broader permissions. A successful homepage response is not an access or recovery check.
- Keep a decision record with the chosen layout, approved cost allocation, owners and unresolved items.
- Review the choice when an outside administrator joins, a launch window changes, storage grows or a client prepares to leave.
- Use the responsibilities guide to turn the technical choice into an operating agreement.
Sources & review
Technical references were checked on September 12, 2026. Examples are planning exercises; referenced software documentation does not establish PrivateHostLab service capabilities.