App Redundancy

Last Updated May 2015

Redundancy ensures that when things go wrong, you have something to fall back on. This doc explains how redundancy works on Pagoda Box and how you can make your apps redundant. After reading it, you should be familiar with:

  • How Pagoda Box facilitates redundant architectures
  • How to make your app redundant

What is Redundancy?

Simply put, redundancy is failover. If something goes wrong with an instance, there's another instance or instances to fall back to. It's a simple concept, but there are details & benefits of redundant services on Pagoda Box that should be pointed out.

Hot Failover

Redundant services consist of two or more instances. Though rare, it's possible for one instance to fail and/or stop responding. When this happens, Pagoda Box health-monitors detect the faulty instance and begin routing all requests to the other instance(s) as the faulty instance is repaired. This all happens behind the scenes with, in most cases, no noticeable impact to the end user.

Hardware Failover

When multi-instance services are created on Pagoda Box, each instance is provisioned on separate physical machines. If there's ever an issue with a host server, health monitors detect the unresponsive instance on the affected server and push all requests to instances on functioning servers.

Isn't Pagoda Box Redundant?

Yes, Pagoda Box's underlying infrastructure is redundant – meaning all underlying processes that allow Pagoda Box to function are redundant. However, this doesn't mean your app is redundant. App-level redundancy is managed by users.

App Redundancy is Handled Per Service

Each app consists of one or more services (PHP, MySQL, Redis, etc.). Each service, depending on the type, can be redundant. A service's "topology" determines whether or not the service is or can be redundant. More on topologies in the Service Topologies doc and below.

Making Services Redundant

There are multiple ways to make services redundant. When creating a service from the Boxfile or through the dashboard, you can define the service's topology. You can also add instances to code services as well as change the topology of data services service in your dashboard.

Creating a Redundant Service from Your Boxfile

When creating a service from the Boxfile, define the service's topology in the Boxfile config. Below is an example of services in the Boxfile with redundant topologies.

Redundant Services in the Boxfile YAML

    type: php
    topology: cluster

    type: mysql
    topology: redundant

    type: redis
    topology: redundant

Boxfile Topologies Only Apply on Service Create

When defining a service's topology in your Boxfile, it only gets applied when the service is created. For existing services, changes to the topology Boxfile config are ignored.

Creating a Redundant Service in Your Dashboard

When adding a data service in your dashboard, select the "Redundant" topology.

Enabling Redundancy on Service Create

Making Code Services Redundant

Code services (webs & workers) are created using the cluster topology, meaning they can have many instances working together as one. Any code service scaled to two or more instances is redundant.

To add instances to a code service, click on the service in your dashboard to expand its options. Under the "Configure" tab, you'll see the service's current number of instances. Click to expand the scaling options. Add instances by moving the slider to the right, then click "Save Changes".

Making a Code Service Redundant

Making an Existing Data Service Redundant

Most data services (databases, caches, storage, etc.) have both the "single" and "redundant" topologies available to them.

To make a manage the topology of a data service, click on the service in your dashboard to expand its options. Under the "Configure" tab, you'll see the current topology in the lower left. Click to expand the scaling options. Select the "Redundant" topology from the dropdown and click "Save Changes".

Updating a Data Service's Topology

Topologies & Redundancy

As mentioned above, redundancy is enabled through a service's topology. For a deep dive into topologies, read through the Service Topologies doc. Below are quick summaries of each topology and how they facilitate redundant architectures.


Single topologies are not redundant.


Two instances in either a Master/Master, Master/Slave, or Primary/Secondary setup.


One or more instances working together as one. Services with the cluster topology are only redundant when scaled to two or more instances.

If you have any questions, suggestions, or corrections, let us know.