Auto-Deploy for Multiple Containers

Git & SVN Auto-Deploy for Multiple Containers

Horizontally scaled application layers provide additional capacity for high-traffic projects. When source-code updates are deployed, the application containers can be updated one by one to keep the service available throughout the process.

Standard automatic deployment can update all application-server containers at the same time. For higher availability, start a sequential VCS update manually, through the command-line interface, through the API, or through custom automation.

Sequential Update Application containers are redeployed one after another.
Reduced Downtime Other running nodes continue serving requests while one node is updated.
Automation Ready The same update can be triggered through the dashboard, CLI, API, or a custom script.
On this page

Multi-Node Auto-Deploy Behaviour

For a highly visited application, horizontal scaling is commonly used to run several application-server containers in the same layer.

When normal repository auto-deploy is enabled, all containers in that layer may be updated simultaneously. This is faster, but the application can become temporarily unavailable while every node is being refreshed.

High-availability approach: Use an explicit VCS update operation when the containers must be updated sequentially. The platform redeploys each node in turn while the remaining containers continue handling traffic.

Update through the Dashboard

1Locate the deployed project

Expand the application-server layer and find the required Git or SVN project.

2Start the update

Click Update from GIT/SVN. For a Maven-based Java project, use Build and Deploy.

The platform then applies the updated source code to the application-server containers one by one.

The exact button label depends on whether the project is deployed directly from Git or SVN or built through a Maven node.

Update through CLI

Use the VCS update method from the platform command-line interface:

~/jelastic/environment/vcs/update \
  --envName {env_name} \
  --context {app_context}
  • {env_name} — name of the environment containing the project.
  • {app_context} — deployment context or project name.
Some older platform versions use the --project parameter instead of --context. Use the form supported by your installed CLI version.

The same command can be used for a manual redeployment whenever updated repository sources need to be applied.

Update through API

The update can also be started directly through the platform VCS API. Use the appropriate update method from the Environment > VCS API section and provide the environment name and application context.

This approach is suitable when the update must be triggered from an external CI/CD system, administrative portal, scheduled service, or another automation workflow.

Automate Sequential Updates

Dashboard, CLI, and API update operations can be integrated into a custom automation script. Common trigger models include:

  • Run the update at a scheduled interval.
  • Start the update after source-code changes are detected.
  • Trigger the update from an external CI/CD pipeline.
  • Start the update after tests or approval checks succeed.
Queue management: Allow the current update to finish before starting another one. The required interval depends on the number of nodes and the project build and deployment duration.

In each case, the application-server containers are redeployed sequentially, helping maintain application availability while the source-code update is applied.

What’s next?

  • Deployment Manager
  • Java VCS Deployment
  • Zero-Downtime Deployment for PHP
  • Deploy .NET Project
  • Deployment Hooks