Product Updates

We’re happy to announce that it is now possible to have Torque send sandbox event notifications to the Teams/Slack channel, or automation tool, of your choice. You can define multiple notifications for different communication tools, and for different channels in the same communication tool. For details, see Configuring Torque Notifications.

We’ve added a Launch Sandbox button to the blueprints, allowing you to conveniently launch your sandboxes directly from the Blueprints page. 

We’ve added support for dynamically populating inputs to Helm charts.  You can use this capability to add, to your application quick links, variable inputs that auto-populate during the sandbox’s deployment. For details, see the Inputs and Quicklinks sections in Creating a New Blueprint From a Helm Chart.

Providing you with visibility into the costs of your sandbox executions, Torque now displays the estimated and current costs for each blueprint and sandbox.The costs are displayed in the Blueprints page:When selecting a blueprint for the sandbox:When setting the sandbox’s duration:And in the sandbox’s details page:The costs are based on the blueprint’s past executions. This capability is not supported for EKS/AKS.

GitLab, a major code collaboration and version control, is now a first-class citizen in Torque. Teams can now associate YAML and Terraform module repositories residing on GitLab. Go to your space’s Settings > Repositories page, click Add a Repository, select the GitLab icon, specify the repo’s URL and click Connect. 

It is now possible to launch Helm charts from your development branch, to test changes you plan on making without affecting the published blueprint. You can do this by launching a sandbox from the Helm chart in your development branch, verifying the updates, and then merging the Helm chart from your dev branch to the main version of the chart. At this time, this is supported via Torque REST API. For details, see Launching a Helm Blueprint From a Branch.

Following customer requests, we’ve added the capability to define blueprints from Helm charts. Torque provides full support for Helm so you don’t need to modify your Helm charts in any way. Simply add the Helm chart to the space’s repository and set up the blueprint. Furthermore, integrating your Helm charts with Torque allows you to enjoy Torque’s full benefits, including governance policies, self-service, cost management, and more. For details, see Using Helm Blueprints in Torque.In addition to Helm blueprints, Torque also supports Terraform modules and Torque-compatible YAML files.

As Torque account admin, you can see how your users are using the tag values were overridden. For details, see The Tags Tab. 

To help your sandbox end-users indicate the blueprint’s design phase, we’ve added an out-of-the-box tag called Activity Type. It is attached to all new sandboxes and comes with a customizable default set of possible values. For details, see Customizing the activity_type Tag, 

To assist you in curbing cloud spend, your space admins can now define a maximum sandbox duration for specific blueprints. This setting is per blueprint, allowing you to set different policies for different blueprints. For details, see Managing the Blueprint's Max Duration Policy. 

Sandbox end-users can now choose to run specific sandboxes with no end time by selecting the Run Indefinitely checkbox on the sandbox’s launch screen. This applies to scenarios in which you want to deploy a sandbox that must be always online, or delivers a static cloud resource. For details, click here.

It is now possible to define (in the blueprint YAML) inputs that display a dropdown list of values when launching the sandbox, forcing the sandbox end-user to select from a controlled list of values. For details, click here.

It is now possible to define custom tags to be attached to cloud resources deployed within sandbox and production environments. This is useful for tracking and troubleshooting purposes, and for greater visibility into your cloud costs.The custom tags can be set on different levels, each applying its custom tags to the levels beneath:Account Space Blueprint SandboxFor details, see Using Custom Tags.

Torque’s CLI and GitHub Actions plugins are now linked from the Settings>Integrations page. 

It is now possible to use GitHub Actions to automate sandbox lifecycle management. We currently provide the following workflows, which can be added as new custom workflows or as additions to existing ones:torque-start-sb-action: Starts a sandbox torque-end-sb-action: Ends a sandbox torque-validate-bp-action: Validates the syntax of specific application/service/blueprint YAMLs.For details, Integrating Torque with GitHub Actions.

Torque blueprints now support the capability to define outputs. These outputs are generated as part of the environment and can be used for testing. Any output parameter specified under the outputs section of the blueprint can be provided by the user, API or CI plugin when creating a sandbox from this blueprint. This capability is supported both for blueprint YAMLs and Terraform modules.

You asked and we listened! Torque now supports the use of HCL values in Terraform modules. This capability applies to both Terraform service and blueprint modules. 

We’re happy to announce that we’ve added the option of onboarding Kubernetes compute services directly from Torque. As account admin, add the compute service in the Cloud Accounts administration page and then associate the compute service with the relevant space(s).

Following customer feedback, we’ve added the capability to define blueprints in Terraform modules. Simply define the Terraform repository in your Torque account and determine which Terraform modules you’d like to make available in your space(s). Torque provides full support for Terraform so you don’t need to modify your Terraform modules in any way. For details, see Using Terraform Blueprints in Torque.

It is now possible to use the same blueprint repository for both sandbox and production blueprints in the space. To distinguish between the two types of blueprints, we added a new production_type element that is defined in the blueprint YAML. For details, see Environment type indication. 

The Torque VS code extension facilitates the blueprint/application/service yaml development process by providing developers with autocomplete, instant error checks and schema validations.Auto-completion suggestions for inputs, parameters and variables:Schema validations and additional checks:Ability to open links directly from the yaml file:For details, see VS Code Exension for Torque.

We’re happy to roll out the new Sample space. It replaces the Sample Blueprints tab of the Blueprints Catalog and comes out of the box with Torque. For details, see Launch a Sample Sandbox.NOTE: Existing customers need to add the initial cloud accounts (named “AWS” and “Azure”) to the Sample space while for new accounts, this is done automatically when those cloud accounts are created. 

The new Parameter Store allows account admins to define parameters on the global level, which can be used in the YAMLs across different spaces. The parameters are specified as key-value pairs and support freetext string values as well as parameters residing in the AWS Parameter Store. 

We’re happy to announce that our new Torque Community is live. For the time being, it includes the Torque knowledge base and product updates, but will eventually serve as a centralized portal for all your knowledge needs, including knowledge base content, news bulletins, technical forums and idea box.

The new Torque CLI tool streamlines the YAML development process by validating changes in real-time and allowing the execution of test sandboxes directly from the development branch, without needing to first merge the changes to production.