Horizontal Scaling

Horizontal Scaling

Horizontal scaling allows you to increase or decrease the number of application instances within an environment layer. It helps distribute workload, improve availability and adapt the environment capacity to changing demand.

On this page

Overview

Unlike vertical scaling, which changes the resources available to an individual container, horizontal scaling changes the number of containers in a layer. You can scale a layer manually through the environment topology or configure automatic scaling rules based on application load.

Scale outAdd application instances to increase capacity and distribute incoming requests.
Scale inRemove unnecessary instances when demand decreases.
Layer-based operationScaling is applied to a selected node group such as application servers, load balancers or VPS instances.
Manual or automaticChange the node count directly or configure load-based scaling triggers.
✓

Tip

Before scaling an application layer, confirm that the application supports multiple instances and that shared files, sessions and database connections are configured appropriately.

Manually Scale a Layer

Use the environment topology wizard to add or remove nodes from a selected layer.

1

Open the environment topology

From the dashboard, locate the required environment and select Change Environment Topology or the equivalent topology-editing action.

Environment topology with horizontal scaling controls
Open the topology wizard and select the layer that needs additional or fewer nodes.
2

Set the required node count

Use the + and − controls, enter the required number directly, or adjust the scaling slider. The topology displays the updated number of instances before the change is applied.

3

Select the scaling mode

Choose either Stateless or Stateful scaling from the layer settings. The selected mode determines how newly added nodes are created.

4

Apply the topology changes

Review the estimated resource usage and confirm the operation. The platform creates or removes the required containers and updates the environment topology.

i

Scale-in behaviour

When the number of nodes is reduced, the most recently added container is normally removed first unless a particular instance is selected explicitly.

Scaling Modes

The scaling mode can be selected during environment creation and changed later through the topology wizard.

StatelessCreates all new nodes simultaneously from the original base image. This method is generally faster but does not automatically copy runtime customizations from an existing node.
StatefulCreates nodes sequentially and copies the file system of the layer’s master container. This method preserves more custom configuration and application data stored inside the node.
Stateless and stateful horizontal scaling modes
Choose the scaling mode that matches the application’s configuration and data requirements.

During initial environment creation, multiple nodes can be provisioned simultaneously because the layer does not yet contain user customizations. For later scaling operations, the selected mode determines whether the master node’s file system is copied.

✓

Recommended approach

Use stateful scaling when application files, custom server settings or local configuration must be reproduced on every new node. Use stateless scaling for immutable or externally configured workloads.

Stateless Mode Considerations

New nodes created in stateless mode are generated from the base template. Consequently, some changes made after the original deployment are not transferred automatically.

Application deploymentsExisting deployment contexts or manually deployed projects may not be present on the new node.
Custom SSLCustom certificates and related server configuration may need to be installed separately.
Mount pointsCustom mounts are retained only when the appropriate persistent volume or shared-storage configuration is available.
Add-onsAdd-ons installed on an existing layer may not be installed automatically on newly created stateless nodes.
Custom filesFiles stored only in the local container file system must be copied manually or distributed through deployment automation.
!

Important

For stateless workloads, keep application code and configuration in a repeatable deployment source such as a repository, container image, automation package or shared storage. Do not depend on manual changes made only inside one running node.

Horizontal Scaling Specifics

The maximum number of same-type nodes allowed in a layer is defined by the hosting provider and account limits. The applicable limit can be reviewed in the account quotas or pricing information.

Provider-defined limitsThe maximum node count varies by platform installation, subscription and environment type.
Hardware distributionNew instances are normally provisioned on different hardware hosts to improve resilience and availability.
Layer namingA layer containing multiple instances is identified with an xN indicator, where N is the current node count.
Synchronous managementCommon actions such as configuration changes, restart, redeploy, log review and statistics access can be applied to the entire layer.
Individual accessEach container remains an isolated instance with a unique node ID and can be managed separately.
Multiple nodes in a horizontally scaled environment layer
A scaled layer displays the total number of active instances and can be expanded to show individual nodes.

Manage Scaled Nodes

After scaling, the layer can be managed either as a group or at the individual-node level.

1

Manage the complete layer

Use the action icons on the layer row to perform supported operations across all instances, such as restart, redeploy, configuration editing, log inspection or statistics review.

2

Expand the layer

Expand the node-group row to display every instance. The master node is normally identified by a dedicated icon, while each container has its own node ID.

3

Assign meaningful node aliases

Edit the default node label and enter a descriptive alias where required. This is useful for distinguishing roles such as primary, replica, worker, reporting or maintenance nodes.

Node aliases in a scaled environment layer
Use aliases to make individual instances easier to identify and operate.

Stack-Specific Behaviour

Some environment components have additional rules when they are scaled.

Application serversAdding multiple application-server instances may automatically add a load balancer to distribute requests.
High-availability application layersWhen a platform-managed high-availability option requires a single NGINX entry point, existing NGINX nodes may be reduced to one instance.
VPS instancesEach horizontally scaled VPS instance is normally assigned a separate public IP address.
Maven build nodeThe Maven build node is not designed for horizontal scaling.
✓

Operational recommendation

Test scaling in a non-production environment before applying it to a live workload. Verify application startup, health checks, shared sessions, file synchronization and load-balancer routing on newly created nodes.

Common Issues and Solutions

New nodes do not contain the applicationThe layer may be using stateless scaling. Redeploy the application to the complete layer, use a repeatable deployment process or switch to stateful scaling where appropriate.
Uploaded files are missingMove persistent user data to shared storage, a mounted volume or an external object-storage service.
Users lose their sessionsConfigure shared session storage, sticky sessions or application-level session replication.
The node limit cannot be increasedReview account quotas and hosting-provider limits. Additional capacity may require a quota change or plan upgrade.
Traffic reaches only one nodeConfirm that a load balancer is present, all application nodes are healthy and the routing configuration includes every active instance.
Scaling creates inconsistent configurationStandardize configuration through stateful scaling, environment variables, deployment automation or configuration-management tools.

Expected Result

After the scaling operation is completed, the selected environment layer contains the required number of active nodes. Requests can be distributed among the instances, and the layer can be managed collectively or each node can be accessed individually.

Important Notes

  • Choose the scaling mode before adding nodes and verify that it matches the application’s data and configuration model.
  • Store persistent data outside the local container file system whenever possible.
  • Review account quotas before planning a large scale-out operation.
  • Check application logs and monitoring data immediately after scaling.
  • During scale-in, confirm that the node selected for removal does not contain unique or unsynchronized data.

What’s next?