CloudPloy

Multi-Region Hosting on CloudPloy

Running your application on a single server in one region means users on the other side of the world experience high latency. Multi-region hosting solves this by deploying your application to servers in multiple geographic locations - users connect to the server nearest to them. CloudPloy provisions servers on AWS, so you can deploy to any AWS region and manage traffic routing through Cloudflare or AWS Route 53.

How Multi-Region Works with CloudPloy

CloudPloy provisions and manages servers on AWS EC2 and Amazon Lightsail. To run a multi-region setup, you provision separate CloudPloy servers in the AWS regions your users are concentrated in, deploy your application to each, and route traffic using Cloudflare's geolocation-based routing or AWS Route 53 latency-based routing.

This architecture involves three components:

  • Application servers: Separate CloudPloy-managed servers in each target region running your application
  • Database replication: A primary database in one region with read replicas in others, or a separate write-capable instance per region with application-level conflict resolution
  • DNS routing: Cloudflare or Route 53 configured to route users to their nearest region based on geography or latency

AWS Regions Available

CloudPloy works with any AWS EC2 or Lightsail region. The most commonly used regions for web applications:

Region Location Best For
us-east-1 Virginia, USA North American users (East Coast)
us-west-2 Oregon, USA North American users (West Coast)
eu-west-1 Ireland European users
eu-central-1 Frankfurt, Germany Central European users, GDPR compliance
ap-southeast-1 Singapore Southeast Asian users
ap-northeast-1 Tokyo, Japan Japanese and East Asian users
ap-south-1 Mumbai, India South Asian users
ap-southeast-2 Sydney, Australia Australian and New Zealand users

Setting Up Multi-Region with Cloudflare

Cloudflare's load balancing and geo-routing features work well with CloudPloy servers. The basic setup:

  1. Provision a CloudPloy server in each target region through the dashboard
  2. Deploy your application to each server via your connected Git repository
  3. Add each server's IP address as an origin in Cloudflare Load Balancing
  4. Configure geo-steering to route requests based on user location
  5. Set up health checks so Cloudflare fails over if a regional server goes down

Cloudflare's free plan doesn't include Load Balancing - it requires the Cloudflare Load Balancing add-on ($5/month for up to 2 origins). For simpler setups, Cloudflare's free DNS lets you add multiple A records and rely on client-side routing, though this doesn't give you active health checks or geo-steering.

Database Strategy for Multi-Region

The database layer is the most complex part of a multi-region setup. Your options:

Single Primary Database (Simplest)

Run one primary MySQL instance in your main region. Application servers in other regions connect to it over the internet. This is the easiest approach but adds database latency for users in distant regions - all write operations go to the primary regardless of where the user is.

# DATABASE_URL pointing to primary region database
# Works for read-heavy applications with writes from a single region
DATABASE_URL=mysql://user:pass@primary-region-server-ip:3306/appdb

This works reasonably well for applications where writes are infrequent (e.g., a blog with many readers and few authors) but degrades for write-heavy applications.

MySQL Replication with Read Replicas

Set up MySQL replication with a primary in one region and read replicas in others. Write operations go to the primary; read operations can use the local replica. Laravel's database read/write configuration makes this straightforward:

// config/database.php
'mysql' => [
    'read' => [
        'host' => [env('DB_HOST_REPLICA')], // Local replica IP
    ],
    'write' => [
        'host' => [env('DB_HOST_PRIMARY')], // Primary region IP
    ],
    'driver'    => 'mysql',
    'database'  => env('DB_DATABASE'),
    'username'  => env('DB_USERNAME'),
    'password'  => env('DB_PASSWORD'),
    'charset'   => 'utf8mb4',
    'collation' => 'utf8mb4_unicode_ci',
]

Replication lag is typically under one second for low-write workloads but can be higher during heavy write periods. Applications that read immediately after writing may see stale data from the replica - this is a known trade-off of replication-based architectures.

Separate Databases Per Region

Run independent database instances per region. This eliminates cross-region database latency entirely but requires your application to handle data synchronization at the application level. This is complex to implement correctly and only makes sense for applications where users' data is inherently regional (e.g., a platform where users in the EU only interact with EU data).

Session and Cache Coordination

When users can be routed to any region, server-side sessions and local caches need coordination:

Sticky Sessions

Configure your load balancer to route each user to the same server for the duration of their session. Cloudflare Load Balancing supports session affinity via cookies. This avoids cross-region session lookups but means a user connected to a failed region loses their session until the load balancer routes them elsewhere.

Centralized Session Storage

Store sessions in a Redis instance accessible from all regions. Laravel and Symfony both support Redis session drivers. The trade-off is that session reads add a cross-region round trip if the Redis instance is in a different region.

# Laravel session configuration
SESSION_DRIVER=redis
REDIS_URL=redis://primary-region-redis-ip:6379

Redis Replication

Run Redis replicas per region using the same replication approach as MySQL. Session writes go to the primary; reads can use the local replica. This adds operational complexity but keeps session reads fast.

WordPress Multi-Region Considerations

WordPress multi-region is significantly more complex than stateless applications because WordPress writes frequently (every page view updates post view counts and session data by default) and the media library stores files on the local filesystem.

File Storage

WordPress uploads stored on the local server filesystem are only available on that server. For multi-region deployments, use an S3-compatible storage solution with an S3 offload plugin (WP Offload Media or similar). This moves media files to a central S3 bucket accessible from all regions:

define('AS3CF_SETTINGS', serialize([
    'provider' => 'aws',
    'access-key-id' => getenv('AWS_ACCESS_KEY_ID'),
    'secret-access-key' => getenv('AWS_SECRET_ACCESS_KEY'),
    'bucket' => getenv('AWS_S3_BUCKET'),
    'region' => getenv('AWS_S3_REGION'),
    'copy-to-s3' => true,
    'serve-from-s3' => true,
]));

Database Writes

WordPress writes to the database on nearly every page load without caching. Enable full-page caching (WP Super Cache, W3 Total Cache, or Redis Object Cache) to reduce write frequency before attempting multi-region replication.

Monitoring Multi-Region Deployments

Running applications across multiple regions requires monitoring each region independently. CloudPloy's server dashboard shows the health and performance of each server individually. For cross-region latency monitoring, external tools like Pingdom, UptimeRobot, or Better Uptime can check your application from multiple geographic locations and alert you when a specific region degrades.

When to Use Multi-Region

Multi-region adds significant operational complexity. Consider it when:

  • Your users are spread across multiple continents and latency measurably affects conversion or retention
  • You have regulatory requirements to store data within specific geographic boundaries (GDPR data residency)
  • Your availability requirements mean a single-region outage is unacceptable

For most applications, a single well-configured server with Cloudflare's CDN in front handles global traffic efficiently. Cloudflare caches static assets at edge locations worldwide, reducing the need to serve those from your origin server. Consider multi-region only after you've exhausted single-region performance optimizations.

Getting Started

  1. Identify where your users are located using your analytics platform
  2. Determine whether database reads or writes are the bottleneck - this guides your database strategy
  3. Provision a CloudPloy server in your secondary region from the dashboard
  4. Deploy your application to the new server via your connected repository
  5. Configure your load balancer or DNS for traffic routing
  6. Set up database replication or centralized session storage
  7. Test failover by temporarily taking one region offline