The Sandbox Deployment Process

  • 19 April 2021
  • 0 replies

When a new sandbox is launched (through the UI, CI plugin or API) Torque starts a complex orchestration process in order to deploy your sandbox. During orchestration Torque pulls all the following components to deploy your sandbox:

  • A blueprint.   In general, the blueprint (and the referenced applications) defines where and how the sandbox will be launched, using which cloud account, what the required cloud infrastructure is, what applications to deploy and in what order, etc.

    Torque pulls the blueprint from your source control repository and converts it into a cloud template file (such as AWS CloudFormation or Azure ARM template). It sends the template to the cloud provider that in turn uses the template to create the infrastructure for your sandbox environment.

  • Artifacts (if requested by the blueprint). These are build artifacts that the application's configuration scripts may require. The artifacts define what will be deployed (in most cases the artifacts are binaries that the application's Initialization script uses).  
  • Additional Inputs (if declared by the blueprint). This is information that the end-user may be required to provide, e.g., database username to be created, needed application port, etc.

The infrastructure of each sandbox includes three additional Torque components, which are deployed on dedicated virtual machines in the environment:

  • Bastion allows you to connect to your infrastructure instances directly from Torque’s sandbox and enables the troubleshooting feature. For details, see The Bastion Feature - Fundamentals.
  • Sidecar is responsible for checking the infrastructure’s readiness, managing the application requirements and dependencies, and providing environment orchestration processes with secured access to cloud services.
  • QualiY allows in-browser connections to the virtual machines on which the applications are installed. This is provided for troubleshooting purposes as the application's deployment logs reside on the virtual machine itself. For details, see Troubleshooting and Debugging Library.

To see what cloud infrastructure is created for the sandbox, access your sandbox’s cloud stack (called “sandbox-<sandbox-d>”.

The Sandbox Deployment Steps


  1. Creating infrastructure- according to the blueprint on which your sandbox is based, your cloud provider creates your infrastructure, including networking elements, compute instances, security definitions, etc.
  2. For each application on the same compute instance:
    1. Preparing artifacts- Torque pulls the artifacts making them available for your application’s scripts.
    2. Deploying applications- Every application, on each compute instance that is ready, is individually deployed. Applications are deployed in parallel to each other. For detailed information on the steps to the application's deployment, see Steps to Deploying Applications.
    3. Verifying environment- Torque runs health checks in parallel to starting all applications. The health checks wait for the infrastructure to stabilize and the application deployment to be verified. For details, see Application Scripts.

Parts of the deployment steps can take place in parallel and are not necessarily dependent on each other. Your sandbox is ready when the health check of all the applications successfully completes and the networking infrastructure is ready (IPs, DNS and others). The sandbox remains active until its end time is reached or until you manually end it. As long as the sandbox is active, your environment is available for you to perform any development or testing activity.

Steps to Deploying Applications

Application deployment in Torque is an efficient process during which all application instances are deployed separately and in parallel to each other. The deployment of an application takes dependencies between applications and the availability of the cloud infrastructure into account. Once the infrastructure of a specific application instance (an application on a specific compute instance) is ready, the application deployment starts and goes through all or some of the following steps:


  1. Pulling artifacts (optional)- In case there are artifacts, the artifacts are pulled into the artifacts folder of the specific compute instance.
  2. Waiting for dependencies (optional)- In case there are dependencies between applications, the deployment waits until it is allowed to continue. For more information about application dependencies, see The Blueprint YAML File.
  3. Running Initialization (optional)- In case there is an Initialization script, the script starts to run and deploys the application.
  4. Running ‘Start’ script (optional)- In case the application needs to be started, the start script runs.
  5. Running health check- In parallel to starting the application, the health check starts and waits for both the deployment to be verified and the infrastructure to stabilize.

In most cases, your application will go through all the above-mentioned steps. When a step is not needed, it is skipped.

NOTE: In simple scenarios, when the Image already includes the deployed application, most of the steps will be skipped and the only steps that remain are ‘waiting for dependencies’ and ‘Running health check’. This ensures that you can control the order of deployments and verify that the application is working as expected.

When all the instances of an application are deployed and verified, the application is considered ready and the sandbox will continue its deployment until the deployments of all the applications are done.

This topic has been closed for comments