One Dashboard, 40 Client Sites: An Agency Workflow for WordPress on PaaS

Agencies do not have a WordPress hosting problem; they have forty of them, all slightly different, all billed to different people, all touched by developers who should not be able to break each other's work. The agency in this scenario, a twelve-person studio we will call Harbour & Field, moved its client estate from a reseller cPanel account to MassiveGRID PaaS, the platform built on Virtuozzo Application Platform (formerly Jelastic). This is the workflow they landed on, from a new client's first day to the monthly invoice.

One environment per client, not one server for all

On the old reseller account every client site shared one server's PHP pool, one MySQL instance and one set of resource limits. A plugin loop on a small client's site could slow a large client's store, and there was no clean way to bill for the difference. On MassiveGRID PaaS each client gets its own environment: an isolated set of containers with its own cloudlet limits, its own domain, its own statistics and its own line in the billing history.

Most clients start on the WordPress Standalone Kit, which installs LiteSpeed (or NGINX), MariaDB and Redis in one lightweight container with Let's Encrypt SSL, brute-force protection and the LiteSpeed web application firewall as tick boxes at install time. A small marketing site idles at one or two cloudlets, which at the published rate of $2.46 per cloudlet per month is a hosting cost Harbour & Field can pass through with a clear conscience. The three e-commerce clients run the Cluster Kit instead, and nothing about the workflow below changes for them.

The base image and the clone button

Every agency has a starter site: the house theme, the standard plugin set, the security hardening, the analytics snippet. Harbour & Field keeps that as a stopped environment called base-wp. A new client project starts with Clone Environment, which copies the whole thing, container, database and files, in a few minutes. The clone is renamed for the client, given its own domain and the LiteSpeed cache is cleared. Fifteen minutes after the contract is signed, the developer has a working site with the agency's standards already applied.

Cloning is also how staging works. Before a redesign, the developer clones the client's production environment, works on the clone, and when the client approves, either swaps the environment domains (a one-click operation for environments without public IPs) or deploys the theme to production from the same Git branch. The staging clone is then deleted or, for retained clients, stopped. A stopped environment costs disk only, so keeping a staging copy of every retainer client is affordable in a way that a second cPanel account never was.

Because clones share nothing with their source, a developer breaking the staging database has no path to production. For clients on isolated environment groups the platform's network isolation goes further and blocks internal connections between groups entirely, so a hard-coded database host in a cloned config cannot reach the production database by accident.

Groups, tags and who sees what

Forty environments in one list is unmanageable, so Harbour & Field uses environment groups. Each client has a group, nested under Retainer or Project, and each environment carries tags for its stage (prod, staging, dev) and stack (standalone, cluster). One click on a tag filters the dashboard; one click on the client group shows only that client's environments.

Access follows the same structure through account collaboration. The agency's primary account owns every environment and pays every bill. Developers are collaboration members with roles: a junior developer's role allows deploying code and viewing logs on the environments in their client groups, but not changing topology or deleting anything. The lead developer's role adds scaling and add-on management. Clients who want dashboard access get a read-only role on their own group and see statistics and billing usage for their environments and nothing else. When a developer leaves, removing them from the collaboration revokes every environment at once.

Deployment without SFTP

Each client site's theme lives in a Git repository. The environment's application server is connected to the repository through the Deployment Manager with automatic updates enabled, so a merge to the client's main branch is deployed within the check interval, and the PHP servers' zero-downtime mode swaps a symlink only when the new tree is complete. For clients who want push-to-deploy immediacy, the Git-Push-Deploy add-on registers a webhook with GitHub or GitLab and deploys on every push.

Plugin and core updates are handled inside WordPress as before, but the agency takes an environment-level backup first. The WordPress Backup/Restore add-on archives files and database to a single Backup Storage node shared by all forty sites, on a nightly schedule in the agency's timezone, and a restore is one click from the dashboard rather than a support ticket. Before a risky update the developer clicks Backup Now.

Cost control across the estate

Pay-per-use billing rewards housekeeping, and the agency built three habits around it.

• Dev and staging environments are stopped when nobody is working on them. The Start/Stop Scheduler add-on stops every environment tagged dev at 19:00 and starts them at 08:00 on weekdays. Stopped environments are charged for disk only.
• Scaling limits are set per client, not per server. A brochure site has a low dynamic cloudlet ceiling; the store clients have high ones. Load alerts email the agency when a site approaches its limit, which is usually the moment to have a conversation about a larger plan rather than a moment of downtime.
• Usage reports come from the platform. The statistics view shows each environment's RAM, CPU, disk and traffic history, and the billing history breaks down charges per environment. Because a group maps to a client, the monthly invoice is a filter, not a spreadsheet.

Volume discounts apply automatically as the account's consumption grows, and because cloudlet consumption is counted per environment rather than per node, a clustered client reaches higher discount tiers than the same resources spread across separate servers would.

What changed for the agency

The measurable change was support time. Plugin conflicts stopped affecting neighbouring clients, staging stopped being a shared server everyone was afraid to touch, and restores went from a ticket to a click. The less measurable change was that the agency could say yes to clients who wanted their site in Frankfurt for GDPR reasons, or in Singapore for an Asian launch, because a region is a dropdown at clone time and the workflow is identical in all four MassiveGRID locations.

Frequently Asked Questions

Can a client have their own PaaS account and still let the agency manage the site?

Yes. Collaboration works in both directions. A client can own the environment on their own account and pay for it directly, then invite the agency as a collaboration member with a role that allows deployment, scaling and add-on management. The agency sees the client's environment alongside its own in one dashboard.

How do I move an existing client site into the platform?

Install the WordPress Standalone Kit (or clone the base environment), then import the site with a migration plugin such as Duplicator or All-in-One WP Migration, or copy files over SFTP and import the database through the built-in database manager. Point the domain at the new environment last, and issue the Let's Encrypt certificate once DNS resolves.

Is one big environment with WordPress multisite cheaper than forty environments?

Sometimes, but it recreates the shared-fate problem the agency left cPanel to escape. Multisite suits many small sites owned by one client. For sites owned by different clients with different traffic and update cadences, separate environments give isolation, per-client billing and independent scaling, and the idle cost of a small stopped or lightly used environment is minimal.