Scaling Beyond One App Node
Clustering spreads your app across more than one server: a load balancer in front, a database that survives a lost node, and one filesystem every server shares. You need it when downtime is a real cost, or traffic has outgrown a single box.
Pick from 5 balancers: NGINX, HAProxy, Varnish, Apache, or LiteSpeed ADC. Health checks drop failing nodes and SSL terminates at the balancer.
Replicate MySQL, MariaDB, PostgreSQL, Percona, Redis, OpenSearch, or Couchbase. ProxySQL or Pgpool-II routes traffic; failover is automatic and 14 daily backups are kept.
A storage node mounts on every app node, so uploads, sessions, media, and builds share one surface. Choose NFSv4 or replicated GlusterFS.
Deploy from the dashboard in a few clicks. The platform wires up replication, health checks, mounts, and SSL for you.
When Clustering Matters
If your app currently runs on a single server, the question isn’t whether clustering is impressive. It’s whether anything on this list is true for you yet.
You probably want clustering if…
- One server going down would take you offline. A second app node behind a load balancer keeps the site reachable when the first one reboots, fails, or gets pulled for maintenance.
- Traffic has outgrown a single box. Spreading requests across multiple app nodes is cheaper and more predictable than buying a bigger and bigger single server.
- The database can’t be a single point of failure. A clustered database stays up when one node restarts or fails, with failover usually under 5 seconds.
- Multiple app servers need the same files. Uploads, sessions, media, and build artifacts have to be visible from every node, not stuck on the one that wrote them.
- None of the above is true yet. Single-node App Hosting is fine. Come back when one of these starts to bite, or talk to an engineer if you’re not sure.
Load Balancing Across Healthy Nodes
A load balancer lets you run more than one copy of your app at the same time without your users picking which copy to hit. It sits in front of the app nodes and routes each request to a healthy one. Active health checks run before every connection assignment and drop failing nodes from the pool.
TLS terminates at the balancer. Backends receive plain HTTP on the private network, so app nodes stay focused on application work rather than certificate management.
Choose your balancer stack
NGINX, HAProxy, Varnish, Apache, or LiteSpeed ADC. Pick the one your stack already expects.
Health checks on by default
Failing nodes leave the pool automatically, before the next connection is assigned.
Basic cluster
A single load balancer fronts the app nodes. Add a second load balancer for redundancy when uptime requirements demand it.
Database Clusters That Survive Node Loss
With a database cluster
Add a database cluster: replicated nodes with automatic failover behind the app tier.
A clustered database keeps your app’s data available when one database node restarts, fails, or gets pulled for maintenance. SQL and NoSQL engines are supported, in replicated, multi-primary, and synchronous topologies. Failover typically completes in under 5 seconds. Every cluster includes 14 daily backups, SSL/TLS in transit, and quorum-safe coordination.
Sequential restart with delay
Restart cluster nodes one at a time so the database stays available.
Place multi-primary nodes in separate regions for DR and lower-latency reads. Region pairing requires engineering review at provisioning.
Add nodes from the dashboard; they join the cluster, configure replication, and register with the load balancer automatically.
Deploy replacements, sync replication state, and rejoin failed nodes across Primary-Secondary, multi-primary, Galera, and XtraDB.
Platform-issued certificates with ProxySQL-encrypted backend replication. No certificate management required.
Trusted by businesses that rely on real support
Questions About Clustering
Do I need all three clustering primitives or can I add them one at a time?
Add them one at a time. Each primitive solves a distinct constraint (traffic, data, files). Provisioning all three before the workload needs them adds operational cost without operational benefit. Front the app with a load balancer when traffic exceeds one node, run a database cluster when the database is the single point of failure, and add a shared volume when files must be shared across nodes.
Can I run a database cluster without a load balancer?
Yes. A database cluster is independent of the app tier. Read scale and high availability come from the cluster topology and proxy layer (ProxySQL or Pgpool-II); the load balancer only matters when the app tier itself is multi-node.
What happens to in-flight requests when a node fails?
The load balancer's health check pulls the failing node out of rotation; in-flight requests on that node fail and the client (or upstream retry policy) repeats. Database clusters with synchronous replication block the failed write; primary-replica resumes once the new primary is promoted. NFS and GlusterFS reconnect on the next read or write when a storage node recovers.
How is a load balancer added to my environment?
A load balancer is added automatically when you scale to more than one application server node. You can also add one manually through the topology wizard, even for a single server.
Which load balancer stack should I choose?
Start with NGINX for most workloads. Choose HAProxy for detailed monitoring or pure TCP balancing, Varnish for caching acceleration, Apache for deep module customization, or LiteSpeed ADC for enterprise HTTP/3 and WAF features.
Do load balancers support HTTP/3?
NGINX, Varnish, and LiteSpeed ADC support HTTP/3 (QUIC) with the feature enabled by default. A public IP is required to bypass the shared load balancer and use HTTP/3 directly.
How do load balancer health checks work?
Each stack implements health checks differently. NGINX checks TCP before routing each request. HAProxy runs TCP checks every 2 seconds. Failed nodes are removed from the pool without intervention; in-flight connections complete on healthy nodes.
What security features are built in at the balancer?
NGINX includes a pre-built ModSecurity WAF module with OWASP rules. LiteSpeed ADC has web application firewall protection and layer-7 anti-DDOS filtering. HAProxy provides DDOS mitigation through its event-driven architecture.
Can I load balance TCP traffic (not just HTTP)?
TCP load balancing covers databases, mail servers, and custom protocols. Configure frontend and backend port mappings and attach a public IP to the load balancer node.
How does session persistence work?
LiteSpeed ADC uses stateful mode (session affinity) by default, routing requests from one source to the same backend. Other stacks offer configurable persistence options. For best results at scale, use external session storage (Redis or Memcached) and keep backends stateless.
Can I scale load balancers independently from application servers?
Load balancer nodes scale horizontally and vertically independent of your application server layer. Adjust cloudlet limits and node count through the topology wizard to match your traffic patterns.
Which database engines support clustering?
Supported SQL engines are MySQL, MariaDB, PostgreSQL, and Percona Server. Supported NoSQL engines are Redis (distributed cluster), OpenSearch (auto-clustering), and Couchbase (auto-scalable cluster).
What replication modes are available for MySQL and MariaDB?
Primary-Secondary replication supports read scaling and failover. Primary-Primary supports write availability. Galera/XtraDB provides synchronous multi-master clustering with quorum write semantics.
Are database cluster backups included?
Yes. Every database cluster gets 14 daily backups with cluster-aware, quorum-safe coordination. An optional Backup/Restore add-on lets you set custom schedules and store backups on remote storage for longer retention.
How does auto-clustering work for databases?
Enable auto-clustering in the topology wizard to provision a preconfigured cluster (Galera for MySQL/MariaDB, replication for PostgreSQL, and native clustering for Redis and OpenSearch). The platform handles initial setup, configuration distribution, and staggered restarts during upgrades.
Can I clone a database cluster for staging tests?
Yes. Clone environments for release rehearsal and migration tests before touching production. Validate replication mode, failover behavior, and connection settings in the clone first.
What is a Data Storage Container?
A Data Storage Container is a dedicated node for persistent file storage that other containers mount over the network. It lets multiple environments share media, configs, logs, and backups as if the files were local.
How is NFS different from GlusterFS Native?
NFS is a straightforward protocol optimized for speed and low overhead. GlusterFS Native (FUSE) adds automatic replication across bricks for failover and data safety, but uses more CPU and disk. Choose NFS for performance-focused topologies and GlusterFS when reliability and backup matter most.
How does auto-clustering work for shared storage?
Enabling auto-clustering creates a replicated GlusterFS volume across three or more storage nodes. If one storage node fails, the mount client on your application containers switches to a healthy replica automatically on the next read or write, without manual intervention.
Can I share storage data across different environments?
Any node on the same account can mount directories from a Shared Storage Container, even if the nodes are in different environments. Use it to share media, configs, or backups across staging and production.
Can I use GlusterFS with SQL databases?
GlusterFS does not support structured data, so it should not be used as the primary storage for SQL databases. Database engines must run on local block storage, not the shared mount. Storing database backup files on a GlusterFS share for offsite copies or replication is fine.
How does storage integrate with Docker containers?
Custom Docker containers support volume-based storage integration. You can create local volumes to persist data across redeployments, or mount remote directories from a Shared Storage Container with NFS or GlusterFS.
No matching questions found.
Test your stack on metered hosting
- Meters real usage: baseline plus actual use, not a fixed tier
- Turnkey clustering: traffic reroutes once clustering is enabled
- From Git push to live: in minutes, not hours
- Engineers on call: real support around the clock
Start a real trial environment
Deploy your app, test the ceiling, and estimate cost before you commit.