Ubuntu VPS for Agencies: Host Client Sites on Infrastructure You Control

Every web agency pays for hosting. Most agencies pay someone else to host their client sites — on shared hosting plans, on managed WordPress hosts, on Cloudways or Flywheel or WP Engine. The margin on that arrangement is zero. In fact, it is often negative: you are paying retail for hosting, passing the cost through to the client, and absorbing the support burden when something goes wrong on infrastructure you do not control. There is a better model. Agencies that host client sites on their own VPS infrastructure turn hosting from a cost center into a profit center — recurring revenue, higher client retention, and complete control over the stack. This guide covers the architecture, the business model, and the technical implementation for agencies at every stage.

MassiveGRID Ubuntu VPS includes: Ubuntu 24.04 LTS pre-installed · Proxmox HA cluster with automatic failover · Ceph 3x replicated NVMe storage · Independent CPU/RAM/storage scaling · 12 Tbps DDoS protection · 4 global datacenter locations · 100% uptime SLA · 24/7 human support rated 9.5/10

Deploy a self-managed VPS — from $1.99/mo
Need dedicated resources? — from $19.80/mo
Want fully managed hosting? — we handle everything

The Agency Hosting Business Case

Hosting client sites yourself is not about saving a few dollars. It is a strategic business decision that affects three things agencies care most about:

Recurring Revenue

Project work is feast-or-famine. You finish a $15,000 website build, invoice the client, and then start looking for the next project. Hosting flips this. If you host 30 client sites at $75-150/month each, that is $2,250-4,500 in monthly recurring revenue — revenue that arrives whether or not you close a new project this month. Over a year, 30 hosting clients at $100/month generates $36,000 in recurring revenue. That covers a salary, an office, or a runway extension.

Client Retention

When a client's website, email, DNS, and hosting all run through your agency, switching to a competitor is painful. Not because you are holding them hostage — but because the cost of migrating everything is high enough that the client needs a very good reason to leave. Hosting creates operational stickiness that project work alone does not.

Control

When you host on shared platforms, you are at the mercy of that platform's decisions. Price increases, feature removals, performance degradation, support quality changes — you have no leverage. On your own VPS, you control the stack, the pricing, the performance, and the support experience. When a client calls about their slow site, you can actually fix it instead of filing a support ticket with a third party.

Architecture: One Server vs. Multi-Server

The first architectural decision is whether to put all client sites on one server or spread them across multiple servers. Both approaches work — the right choice depends on your client count and risk tolerance.

Single-Server Architecture (3-15 Clients)

One VPS runs all client sites with Nginx server blocks, separate databases, and individual PHP-FPM pools. This is the simplest and most cost-effective approach:

┌─────────────────────────────────────────┐
│              Ubuntu VPS                  │
│                                          │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
│  │ Client A │  │ Client B │  │ Client C │ │
│  │ Nginx    │  │ Nginx    │  │ Nginx    │ │
│  │ PHP-FPM  │  │ PHP-FPM  │  │ PHP-FPM  │ │
│  │ Database │  │ Database │  │ Database │ │
│  └─────────┘  └─────────┘  └─────────┘ │
│                                          │
│         MySQL/MariaDB Server             │
│         Redis (shared cache)             │
│         Nginx (reverse proxy)            │
└─────────────────────────────────────────┘

Advantages: simple management, low cost, easy backups. Disadvantage: a misconfigured or compromised site could theoretically affect others.

Multi-Server Architecture (15+ Clients)

Separate servers for different client tiers or groups:

┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│   VPS #1     │  │   VPS #2     │  │   VDS #1     │
│  5 standard  │  │  5 standard  │  │  3 premium   │
│  clients     │  │  clients     │  │  clients     │
│  $15/mo      │  │  $15/mo      │  │  $40/mo      │
└──────────────┘  └──────────────┘  └──────────────┘

This approach lets you tier your hosting: standard clients on shared VPS, premium clients on dedicated resources, high-value clients on managed infrastructure.

Client Isolation Strategies

Even on a shared server, each client site should be isolated from others. This prevents security issues from spreading, makes resource accounting possible, and ensures one misbehaving site does not take down the rest.

Separate System Users

Create a dedicated Linux user for each client:

# Create client user with home directory
sudo useradd -m -s /bin/bash client-acme
sudo mkdir -p /home/client-acme/public_html
sudo chown -R client-acme:client-acme /home/client-acme

Set proper permissions so clients cannot read each other's files:

# Restrict home directory access
sudo chmod 750 /home/client-acme

# Add www-data to client group (so Nginx/PHP can read files)
sudo usermod -aG client-acme www-data

Separate PHP-FPM Pools

Each client gets their own PHP-FPM pool, running as their own user. This is critical for both security and resource management (see our PHP optimization guide for tuning each pool):

sudo nano /etc/php/8.3/fpm/pool.d/client-acme.conf

[client-acme]
user = client-acme
group = client-acme

listen = /run/php/php8.3-fpm-client-acme.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Resource limits per client
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4
pm.max_requests = 500

; Prevent one client from consuming all memory
php_admin_value[memory_limit] = 256M
php_admin_value[max_execution_time] = 30
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M

; Client-specific error log
php_admin_value[error_log] = /home/client-acme/logs/php-error.log
php_admin_flag[log_errors] = on

; Restrict filesystem access to client directory
php_admin_value[open_basedir] = /home/client-acme/:/tmp/:/usr/share/php/
php_admin_value[doc_root] = /home/client-acme/public_html

; Disable dangerous functions
php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen

The key security settings are open_basedir (restricts PHP to the client's directory) and disable_functions (prevents shell command execution). These ensure a compromised WordPress plugin in Client A's site cannot read Client B's database credentials.

Separate Nginx Server Blocks

Each client gets their own Nginx server block pointing to their PHP-FPM pool (see our Nginx reverse proxy guide):

sudo nano /etc/nginx/sites-available/client-acme

server {
    listen 443 ssl http2;
    server_name acmecorp.com www.acmecorp.com;

    root /home/client-acme/public_html;
    index index.php index.html;

    ssl_certificate /etc/letsencrypt/live/acmecorp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/acmecorp.com/privkey.pem;

    # Access log per client
    access_log /home/client-acme/logs/access.log;
    error_log /home/client-acme/logs/error.log;

    # Security headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Static file caching
    location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf|eot)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

    # WordPress-specific rules
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # PHP handling — uses client-specific FPM pool
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.3-fpm-client-acme.sock;
        fastcgi_intercept_errors on;
    }

    # Block access to sensitive files
    location ~ /\.(ht|git|env) {
        deny all;
    }

    location = /wp-config.php {
        deny all;
    }
}

sudo ln -s /etc/nginx/sites-available/client-acme /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Separate Databases

Each client gets their own MySQL/MariaDB database and user (see our database tuning guide):

# Create database and user for client
sudo mysql -e "CREATE DATABASE client_acme CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
sudo mysql -e "CREATE USER 'acme_user'@'localhost' IDENTIFIED BY '$(openssl rand -base64 24)';"
sudo mysql -e "GRANT ALL PRIVILEGES ON client_acme.* TO 'acme_user'@'localhost';"
sudo mysql -e "FLUSH PRIVILEGES;"

Never give clients access to each other's databases or use a shared database user across clients.

Freelancer Stage: VPS for 3-5 Clients

If you are a freelancer or small agency managing a handful of client sites, a single Cloud VPS with 4 vCPU and 8GB RAM hosts 3-5 client WordPress sites comfortably. Here is the math:

At this stage, your infrastructure cost is $8-20/month. If you charge each client $50-75/month for hosting, that is $250-375 in revenue against $8-20 in costs. Your margin is 92-97%.

Client Setup Script

Automate client onboarding with a script:

sudo nano /usr/local/bin/add-client.sh

#!/bin/bash
set -e

CLIENT_NAME=$1
DOMAIN=$2

if [ -z "$CLIENT_NAME" ] || [ -z "$DOMAIN" ]; then
    echo "Usage: add-client.sh client-name domain.com"
    exit 1
fi

DB_PASS=$(openssl rand -base64 24)
DB_USER="${CLIENT_NAME//-/_}_user"
DB_NAME="${CLIENT_NAME//-/_}_db"

echo "=== Creating client: $CLIENT_NAME ==="

# 1. Create system user
echo "Creating system user..."
sudo useradd -m -s /bin/bash "$CLIENT_NAME"
sudo mkdir -p "/home/$CLIENT_NAME/public_html"
sudo mkdir -p "/home/$CLIENT_NAME/logs"
sudo chown -R "$CLIENT_NAME:$CLIENT_NAME" "/home/$CLIENT_NAME"
sudo chmod 750 "/home/$CLIENT_NAME"
sudo usermod -aG "$CLIENT_NAME" www-data

# 2. Create database
echo "Creating database..."
sudo mysql -e "CREATE DATABASE $DB_NAME CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
sudo mysql -e "CREATE USER '$DB_USER'@'localhost' IDENTIFIED BY '$DB_PASS';"
sudo mysql -e "GRANT ALL PRIVILEGES ON $DB_NAME.* TO '$DB_USER'@'localhost';"
sudo mysql -e "FLUSH PRIVILEGES;"

# 3. Create PHP-FPM pool
echo "Creating PHP-FPM pool..."
cat > "/etc/php/8.3/fpm/pool.d/$CLIENT_NAME.conf" << FPMEOF
[$CLIENT_NAME]
user = $CLIENT_NAME
group = $CLIENT_NAME
listen = /run/php/php8.3-fpm-$CLIENT_NAME.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4
pm.max_requests = 500
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
php_admin_value[max_execution_time] = 30
php_admin_value[error_log] = /home/$CLIENT_NAME/logs/php-error.log
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /home/$CLIENT_NAME/:/tmp/:/usr/share/php/
php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen
FPMEOF

# 4. Create Nginx server block
echo "Creating Nginx config..."
cat > "/etc/nginx/sites-available/$CLIENT_NAME" << NGXEOF
server {
    listen 80;
    server_name $DOMAIN www.$DOMAIN;
    root /home/$CLIENT_NAME/public_html;
    index index.php index.html;
    access_log /home/$CLIENT_NAME/logs/access.log;
    error_log /home/$CLIENT_NAME/logs/error.log;

    location / {
        try_files \$uri \$uri/ /index.php?\$args;
    }

    location ~ \.php\$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME \$document_root\$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.3-fpm-$CLIENT_NAME.sock;
        fastcgi_intercept_errors on;
    }

    location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2)$ {
        expires 30d;
        access_log off;
    }

    location ~ /\.(ht|git|env) { deny all; }
}
NGXEOF

sudo ln -sf "/etc/nginx/sites-available/$CLIENT_NAME" "/etc/nginx/sites-enabled/"

# 5. Reload services
sudo systemctl reload php8.3-fpm
sudo nginx -t && sudo systemctl reload nginx

echo ""
echo "=== Client $CLIENT_NAME created ==="
echo "Domain: $DOMAIN"
echo "Web root: /home/$CLIENT_NAME/public_html"
echo "Database: $DB_NAME"
echo "DB User: $DB_USER"
echo "DB Pass: $DB_PASS"
echo ""
echo "Next steps:"
echo "1. Point DNS for $DOMAIN to this server"
echo "2. Install WordPress or upload site files"
echo "3. Run: sudo certbot --nginx -d $DOMAIN -d www.$DOMAIN"

sudo chmod +x /usr/local/bin/add-client.sh

Now adding a new client is a single command:

sudo /usr/local/bin/add-client.sh client-acme acmecorp.com

Agency Stage: Dedicated VPS for 10+ Clients

When you are billing clients for hosting, performance is your reputation. A client calls about their slow site — you cannot say "another server tenant caused it." Dedicated resources eliminate this excuse entirely. At 10+ clients, you also need more headroom:

At this stage, consider splitting clients across two servers for redundancy — if one server has issues, only half your clients are affected.

Scaling Stage: Managed for 20+ Clients

You started your agency to build websites, not manage servers. Managed Dedicated Servers let you scale hosting revenue without scaling operational burden. At 20+ clients:

• Security patches and OS updates are handled for you
• Server monitoring catches issues before clients notice
• Backup verification ensures recovery actually works
• Performance optimization is ongoing, not a one-time setup
• You focus on client relationships and project delivery

The math still works: 20 clients at $100/month = $2,000/month revenue. Managed server cost: $100-200/month. Margin: 90%. But now you are not waking up at 3 AM because a client's site is down.

What to Charge Clients for Hosting

Pricing agency hosting is where most agencies either undercharge (leaving money on the table) or overcharge (losing clients to cheap alternatives). Here are three frameworks:

Framework 1: Flat Rate by Site Type

Framework 2: Cost-Plus Pricing

Calculate your actual cost per client and add a margin:

Per-client infrastructure cost = Server cost / Number of clients
Per-client support time = Hours/month × Your hourly rate
Per-client tools = Monitoring, backups, SSL / Number of clients

Total cost per client = Infrastructure + Support + Tools
Client price = Total cost × 3-5x markup

Example: $20 server hosting 10 clients = $2/client infrastructure. Add $15 for 15 minutes of support time at $60/hour. Add $1 for monitoring tools. Total cost: $18/client. At 4x markup: $72/month.

Framework 3: Value-Based Pricing

Price based on what the hosting is worth to the client, not what it costs you. An e-commerce site doing $50,000/month in sales can easily justify $250/month for reliable hosting with an SLA — because one hour of downtime costs them more than a year of hosting.

Pro tip: Bundle hosting with a maintenance agreement. Clients are more willing to pay $150/month for "website care plan (includes hosting, updates, security monitoring, and 1 hour of changes)" than $75/month for "hosting" plus $75/month for "maintenance" sold separately. Bundling increases perceived value and reduces price sensitivity.

SLA Considerations

What you promise clients should be backed by what your hosting provider promises you. Here is how to structure this:

Always promise slightly less than what your provider guarantees. If MassiveGRID offers 100% uptime, promise your clients 99.9%. This gives you a margin for application-level issues that are outside the hosting provider's scope.

Backup and Disaster Recovery for Client Sites

When you host client sites, backups are not optional — they are a legal and professional obligation. See our automated backup guide for the full setup. Here is an agency-specific approach:

Per-Client Backup Script

sudo nano /usr/local/bin/backup-clients.sh

#!/bin/bash
set -e

BACKUP_DIR="/home/backups"
RETENTION_DAYS=30
DATE=$(date +%Y-%m-%d)

# Get list of client directories
for CLIENT_DIR in /home/client-*/; do
    CLIENT=$(basename "$CLIENT_DIR")
    DB_NAME="${CLIENT//-/_}_db"

    echo "Backing up $CLIENT..."

    # Create backup directory
    mkdir -p "$BACKUP_DIR/$CLIENT"

    # Backup files
    tar czf "$BACKUP_DIR/$CLIENT/files-$DATE.tar.gz" \
        -C /home "$CLIENT/public_html" 2>/dev/null || true

    # Backup database
    mysqldump --single-transaction "$DB_NAME" | \
        gzip > "$BACKUP_DIR/$CLIENT/database-$DATE.sql.gz" 2>/dev/null || true

    # Remove old backups
    find "$BACKUP_DIR/$CLIENT" -name "*.tar.gz" -mtime +$RETENTION_DAYS -delete
    find "$BACKUP_DIR/$CLIENT" -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

    echo "  Done: files $(du -sh "$BACKUP_DIR/$CLIENT/files-$DATE.tar.gz" 2>/dev/null | cut -f1), db $(du -sh "$BACKUP_DIR/$CLIENT/database-$DATE.sql.gz" 2>/dev/null | cut -f1)"
done

echo "All client backups complete."

sudo chmod +x /usr/local/bin/backup-clients.sh

Schedule daily at 3 AM (see our cron guide):

sudo crontab -e

0 3 * * * /usr/local/bin/backup-clients.sh >> /var/log/client-backups.log 2>&1

Critical: Backups on the same server as the data they protect are not real backups. Use rclone or rsync to copy backups to an off-server location — a second VPS, S3-compatible storage, or a local NAS. If the server's disk fails, you want backups stored elsewhere.

Client Restore Script

When a client calls because they broke their site (and they will), restoration should take minutes, not hours:

sudo nano /usr/local/bin/restore-client.sh

#!/bin/bash
set -e

CLIENT=$1
DATE=$2
BACKUP_DIR="/home/backups"

if [ -z "$CLIENT" ] || [ -z "$DATE" ]; then
    echo "Usage: restore-client.sh client-name 2026-02-28"
    echo ""
    echo "Available backups:"
    ls -la "$BACKUP_DIR/$CLIENT/" 2>/dev/null || echo "No backups found for $CLIENT"
    exit 1
fi

DB_NAME="${CLIENT//-/_}_db"

echo "=== Restoring $CLIENT from $DATE ==="

# Confirm
read -p "This will overwrite current files and database. Continue? (y/N): " CONFIRM
if [ "$CONFIRM" != "y" ]; then
    echo "Aborted."
    exit 0
fi

# Restore files
echo "Restoring files..."
tar xzf "$BACKUP_DIR/$CLIENT/files-$DATE.tar.gz" -C /home/
chown -R "$CLIENT:$CLIENT" "/home/$CLIENT/public_html"

# Restore database
echo "Restoring database..."
gunzip < "$BACKUP_DIR/$CLIENT/database-$DATE.sql.gz" | mysql "$DB_NAME"

# Restart PHP-FPM for this client
sudo systemctl reload php8.3-fpm

echo "=== Restore complete ==="

sudo chmod +x /usr/local/bin/restore-client.sh

Client Onboarding Workflow

When a new client signs up for hosting, the onboarding process follows a standard sequence. Document this as a checklist for your team:

Step 1: DNS and Domain Transfer

Have the client update their domain's nameservers or A record to point to your server:

# A record pointing to your server
acmecorp.com.    A    203.0.113.50
www.acmecorp.com.    A    203.0.113.50

Or if using a CNAME for the www subdomain:

www.acmecorp.com.    CNAME    acmecorp.com.

Check propagation:

dig acmecorp.com A +short
dig www.acmecorp.com A +short

Step 2: Create the Client Environment

Use the setup script from earlier:

sudo /usr/local/bin/add-client.sh client-acme acmecorp.com

Step 3: Install SSL

Once DNS is pointing to your server (see our Let's Encrypt guide):

sudo certbot --nginx -d acmecorp.com -d www.acmecorp.com

Step 4: Migrate the Site

For WordPress sites, the most reliable method is a database export/import with search-replace (see our site migration guide):

# On the old server: export database
mysqldump old_database > export.sql

# Copy files
rsync -avz old-server:/var/www/acme/ /home/client-acme/public_html/

# Import database on new server
mysql client_acme_db < export.sql

# Search-replace old domain if it changed
wp search-replace 'old-domain.com' 'acmecorp.com' \
    --path=/home/client-acme/public_html/ \
    --allow-root

Step 5: Set Up Staging (Optional but Recommended)

For clients who request changes frequently, set up a staging subdomain:

# Create staging directory
sudo mkdir -p /home/client-acme/staging
sudo chown client-acme:client-acme /home/client-acme/staging

# Add staging Nginx block (similar to production, different root and domain)
# staging.acmecorp.com → /home/client-acme/staging

Monitoring Client Sites

You need to know when a client's site is down before the client does. Set up Uptime Kuma for free uptime monitoring (see our monitoring setup guide):

# Install Uptime Kuma (lightweight uptime monitor)
# Can run on the same VPS or a separate monitoring VPS
docker run -d \
    --name uptime-kuma \
    --restart=unless-stopped \
    -p 3001:3001 \
    -v uptime-kuma:/app/data \
    louislam/uptime-kuma:latest

Add each client site as a monitor. Configure notifications to go to your team (Slack, email, SMS). Check at 60-second intervals.

Resource Monitoring Per Client

Track which clients consume the most resources so you can right-size your hosting plans:

# Check PHP-FPM pool status per client
for sock in /run/php/php8.3-fpm-client-*.sock; do
    CLIENT=$(basename "$sock" | sed 's/php8.3-fpm-//' | sed 's/\.sock//')
    echo "=== $CLIENT ==="
    FCGI_STATUS=$(cgi-fcgi -bind -connect "$sock" 2>/dev/null || echo "Unable to query")
    echo "$FCGI_STATUS" | head -5
done

Check disk usage per client:

for dir in /home/client-*/; do
    CLIENT=$(basename "$dir")
    SIZE=$(du -sh "$dir" 2>/dev/null | cut -f1)
    echo "$SIZE    $CLIENT"
done | sort -rh

Check database size per client:

sudo mysql -e "
SELECT table_schema AS 'Database',
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)'
FROM information_schema.tables
WHERE table_schema LIKE 'client_%'
GROUP BY table_schema
ORDER BY SUM(data_length + index_length) DESC;"

When to Use a Management Panel vs. Raw VPS

Management panels like RunCloud, GridPane, SpinupWP, and Ploi add a web interface on top of your VPS for managing sites, databases, SSL, and deployments. Here is when each approach makes sense:

Use raw VPS if: you or your team is comfortable with Linux, you want maximum control, you host diverse applications (not just WordPress), or you want to avoid panel lock-in.

Use a management panel if: you primarily host WordPress sites, your team is not Linux-proficient, you value speed of setup over flexibility, or you need non-technical staff to manage sites.

Either way, the underlying VPS infrastructure is the same. Panels are a layer on top — you can always remove a panel and manage directly, or add a panel to an existing server.

Scaling Beyond the Single Server

As your agency grows, here are the inflection points where architecture changes make sense:

At every stage, your hosting revenue should exceed your infrastructure costs by 5-10x. If it does not, you are either undercharging clients or over-provisioning servers.

Ready to Host Clients Professionally?

The path from "paying someone else to host my clients" to "generating recurring revenue from hosting" starts with a single server. Here is how to get started based on where you are today:

Freelancers and small agencies (1-5 clients): A Cloud VPS with 4 vCPU and 8GB RAM is your starting point. Run the client setup script for each new site. Total investment: under $20/month. Potential revenue: $250-375/month.

Growing agencies (5-15 clients): Move to a Dedicated VPS for consistent performance. When you are billing clients for hosting, performance is your reputation. Dedicated resources mean you never have to blame "the hosting provider" for a slow site.

Established agencies (15+ clients): Managed Dedicated Servers let you scale hosting revenue without scaling operational burden. Your team focuses on client projects while the infrastructure team handles server management, security, and monitoring.

The agency hosting model is one of the most reliable ways to build recurring revenue in a web services business. The technical setup is a one-time investment — once you have your server configured, client onboarding scripts built, and monitoring in place, each new client adds revenue with minimal additional effort. Start with one server, prove the model with your first five clients, and scale from there.