Can You Run More Than One App Instance? A Readiness Checklist

What horizontal scaling changes—and what it does not solve

Horizontal scaling means running more than one application instance to serve the same application. It can be a way to add capacity or support an availability goal, but adding instances does not by itself establish that the application can safely operate that way.

Treat compatibility as the first question and server capacity as a separate one. The application’s deployment guidance, shared-state design, background work, and upgrade process all matter. If you have not confirmed these points, more replicas may add operational complexity without addressing the constraint you actually have.

• Identify the reason for considering replicas: increased demand, a specific bottleneck, or an availability requirement.
• Check whether the application vendor explicitly documents multiple application instances as a supported deployment.
• Keep the current single-instance setup as the comparison point. A larger single instance may be simpler if the application is not documented or tested for replicas.

Check the application’s documented support for multiple instances

Look for deployment guidance that describes multiple application replicas serving one deployment, not merely multiple environments, projects, or installations. Similar wording can describe different arrangements. For example, Retool’s page titled “Multi-instance deployment” is described in the supplied material as covering multiple environments within a single instance; that description alone does not establish replica support.

Prefer official documentation for the exact application and deployment model you use. Record any stated requirements, limitations, and supported topology. If the documentation is silent or ambiguous, ask the vendor or maintainers before treating replicas as supported.

Temporal’s self-hosted production-readiness checklist is an example of application-specific guidance that covers scaling, metrics, load testing, and workflow versioning. It is not a universal checklist for other applications, but it illustrates why the application’s own production guidance is a better starting point than assumptions based on infrastructure alone.

• Does the documentation explicitly describe multiple application instances serving the same deployment?
• Are there prerequisites, such as a particular shared service or deployment mode?
• Does the guidance distinguish application instances from worker processes or separate environments?
• Is the guidance for the application version and installation method you actually run?

Trace state shared across replicas

Make an inventory of state the application reads or writes during an ordinary user workflow. For each item, use the official deployment guidance to determine whether instances are expected to share it, keep it local, or access it through a separate service. Do not assume that a database shared by replicas is the only shared-state question.

Check sessions, uploaded files, caches, and database connections individually. The supplied evidence does not establish universal requirements for these components; the application’s documentation and your own tests must answer what applies to your deployment.

A useful test is to begin a workflow through one instance and continue it through another, if your test setup can direct requests that way. Verify that the result matches the application’s documented behavior, including access to files and any session-dependent steps.

• Sessions: determine whether a user can continue a session when successive requests reach different instances.
• Uploaded files: confirm where files are stored and whether every instance that needs them can access them.
• Caches: establish whether they are local or shared and whether the application documents any consistency expectations.
• Database connections: check documented connection settings and consider the combined configuration across all instances.
• Configuration and secrets: confirm that replicas use compatible settings without exposing credentials in test notes or logs.

Coordinate background workers and scheduled tasks

Find out which processes handle queued work, recurring tasks, and other work that may run outside a user request. The key question is whether the application expects those processes to run once, on every instance, or in a separately managed role.

Do not infer scheduling behavior from the fact that an application starts successfully on multiple instances. In a test environment, use a harmless, identifiable task and check whether it ran the expected number of times, whether work was missed, and what happens if an instance stops while work is pending.

Document the application’s supported way to coordinate workers and scheduled work before increasing instance count. If the official guidance does not explain this, treat the behavior as unresolved rather than relying on an assumption.

• List every scheduled task and background process enabled in the deployment.
• Check the vendor’s instructions for which instance or process should run each task.
• Test for duplicate execution, missed execution, and recovery after an instance restart.
• Keep a record of expected and observed results, using test data rather than production work.

Review traffic routing, health checks, and long-lived connections

A multi-instance deployment needs a defined way to direct incoming traffic and remove an instance from service when appropriate. Confirm that the routing and health-check behavior matches the application’s documented needs; the supplied sources do not verify a particular routing configuration for any application.

Ask which endpoint or condition indicates that an instance is ready to serve application requests, and whether the application uses long-lived connections that require special handling. Test the behavior rather than assuming that a successful process start means users can complete their workflows.

Airbip automates routing and TLS certificates through Traefik and Let’s Encrypt for its managed application deployments. That infrastructure capability should not be read as a guarantee that every application supports multiple replicas or has a particular health-check or connection behavior.

• Confirm how traffic is assigned to instances and what happens when one becomes unavailable.
• Identify the application-supported readiness or health-check method, if documented.
• Test normal user workflows, including any connections that remain open for an extended period.
• Verify routing and TLS behavior for the domain and deployment model you plan to use.

Plan migrations and version changes

Before deploying multiple instances, determine how the application expects schema changes and application versions to be managed. The important compatibility questions are specific to the application: whether instances may temporarily run different versions, which migration sequence is supported, and what rollback means after a change.

Do not assume that a deployment method that updates one instance at a time is safe for every application. Use the application’s official upgrade instructions and, where possible, rehearse the planned sequence with a copy of representative data.

Temporal’s production-readiness checklist includes workflow versioning among its topics. That is relevant to Temporal’s guidance and is not evidence that another application uses the same versioning model.

• Write down the documented order for stopping, upgrading, migrating, and starting application components.
• Confirm whether mixed versions are supported during an upgrade, or whether all instances must change together.
• Test the documented rollback or recovery path before relying on it.
• Check that all replicas use compatible application versions and configuration after deployment.

Test representative workflows, failure, and recovery

A useful readiness test follows real workflows rather than checking only whether each instance starts. Choose actions that exercise login, file handling, background work, and any other stateful features your team depends on. Record what should happen before you run the test.

Include controlled failure and recovery cases in a non-production environment. For example, check what users experience if an instance becomes unavailable during a workflow, and whether work or sessions can continue as the application documentation says they should. Avoid testing failure modes against production data or live business processes.

Measure the outcomes you need for your decision, but do not treat a short test as proof of behavior under every load or failure. Temporal’s checklist explicitly includes metrics and load testing; its guidance is a useful prompt to look for equivalent application-specific recommendations.

• Run a workflow that begins on one instance and continues through the normal routing path.
• Test upload and retrieval of a file, if the application supports file workflows.
• Check scheduled and queued work for missed or duplicate execution.
• Simulate an instance restart or removal in a test environment and observe recovery.
• Compare results against documented expectations and note any behavior the vendor has not specified.

Choose replicas, a larger single instance, or another architecture

Choose multiple replicas when the application’s own guidance supports them and your tests confirm that shared state, background work, routing, and upgrades behave as required. If those conditions are not met, adding instances may create new failure modes rather than a reliable improvement.

A larger single instance can be the simpler option when the application is designed or documented around one application process and the immediate need is additional capacity. It may also be the sensible next step while you establish which component is limiting the deployment. This is a decision framework, not a guarantee that vertical scaling will solve a particular bottleneck.

If your requirements call for replicas but the application documentation does not support them, consider a deployment model the vendor documents or ask the maintainers for guidance. Managed hosting can simplify infrastructure operations, but it does not remove customer responsibility for application fit, data, access, and governance choices.

Airbip provides managed deployment for a public catalog of business, publishing, analytics, collaboration, and AI applications as Docker workloads on Airbip cloud servers. It includes configurable daily, weekly, and monthly backups, DNS checks, service lifecycle management, and automated routing and TLS. These capabilities may help with infrastructure operations, but they do not establish multi-instance support for a particular application. Review the live Airbip website for current plans and terms.

• Choose a single instance or vertical scaling when it meets the need and keeps the operating model simpler.
• Choose replicas only after confirming documented support and validating the workflows that matter.
• Choose another deployment architecture if the application’s supported model does not meet your availability or capacity requirements.
• Make the decision against explicit requirements and test results, not replica count alone.