Product Updates

Introducing Enterprise Scalr 7.7.0

Scalr 7.7.0 is here and it’s better than ever! This is our biggest release of 2017, and we’re excited to tell you about it. We’ve improved dozens of features across the board, including the general availability of our new feature, the Cloud Service Gateway, so without further ado, here’s the highlights.

Service Catalog

The Service Catalog is our tool for creating and launching application blueprints – making straight forward app deployment easy for your teams. Before the Service Catalog, IT would have a hard time delivering self-service to non-infrastructure professionals. Service Catalog solves that problem with a straight forward solution for users – pick an app, customize, and get the application you need.

Here’s what we’ve improved:

My Applications –  We’ve redesigned and simplified the look and feel of the My Applications page. Now it’s easy to see what applications are live, what the status is (provisioning, running, terminating, etc.), and a quick overview of what’s happening with the server.

You can see the Project it’s attached to, hourly cost, the lifetime cost of the application, and the lifetime of the server (i.e. if it’s temporary for testing or development). You can also see how many cloud services, containers, and servers are attached.

Custom Icons for Service Catalog Offerings – When we first launched the Service Catalog, we kept it simple with the level of customization. Now you can add custom icons and images to make it easier for your end users to recognize the applications they’re deploying.

Rebranding – We’re renaming the page “Service catalog -> Farm templates” to “Service catalog -> Management”. Why? As the Scalr product continues to grow deeper support for cloud services, this will be a page to manage all types of service catalog offerings. In the near future we’ll release support for:

  • Cloud Services – which will allow users to request RDS database or ELB or any other ‘first class’ cloud services. These first class cloud services are the ones that everyone frequently uses in each cloud like compute, storage, networking, security, and databases. An example of a ‘second class’ cloud service would be services unique to each cloud provider.

  • Container Applications – which will be represented by a docker compose file and will be deployed on a Scalr managed container cluster or cloud cluster (Google Container Service or Amazon EC2 Container Service).


Support for Datastore Clusters – A majority of our customers use Datastore Clusters in Production, so we’re excited to announce that it is natively available in Scalr. When you create a datastore cluster, you can use vSphere Storage DRS to manage storage resources.

Integration with vCenter/vSphere Alarms/Alerts – We wanted to create a page where users can see alarms/alerts triggered by vCenter for their infrastructure. Now it’s here.


The Cloud Service Gateway enables you to give developers native API access to cloud services, with the benefit of using an abstracted API. Instead of waiting for a CMP to roll out updates to cloud services, the Cloud Service Gateway enables you to give developers immediate access to cloud services as soon as they are released.

We have support for the following Azure Services in Cloud Service Gateway. 

Any questions? We’ll talk more about the Cloud Service Gateway below.

Google Cloud Platform

Support for Labels and Network tags – The GCE analogue of tags and security groups is now supported natively in Scalr.

Additional Features and Improvements

Resource Quotas – A new feature to help companies control usage. This will be a new tab on the Environments view, called Quotas:


As a refresher, here’s the difference between ACL (Access Control Lists), Policies and Quotas:

ACLs – What I can use?

Policies – How I can use this?

Quotas – How much of this can I have?

Users can link “Resource quotas” to enabled clouds for a specific environment and this will “enforce” quotas. Initially we’re going to support 4 types of quotas and will expand based on customer needs. In the next release will be a quota for Storage.

Below is how you manage those quotas.

Ansible Integration – Ansible, like Chef, is great for configuration management. We know that many of you are using Ansible or considering it for managing infrastructure, so we’re building out a native Ansible integration This integration is currently in Phase 1, which focuses on Inventory management.

Phase 1 includes:

  1. Ansible Tower (AT) server management
  2. Linking AT machine credentials – Enabling you to execute Job templates in future.

  3. Policies to manage AT servers, Groups, Inventories, and more.

  4. Farm Role configuration to be able to register servers in your Ansible Tower inventory

Orchestration management refactoring: Behind the scenes, we’re completely rewriting the orchestration engine. Most of these changes won’t be seen by you, the user, but it will improve the speed of how the infrastructure of Scalr works, helping you get your applications faster. The UI will also feel snappier and smoother. In addition to rewriting, in future releases we’re planning to “merge” Webhooks and Orchestration to have a single place to manage your orchestration & integrations.

Simplified Target management: We’ve developed a simplified, flexible approach to target management. This will work similar to how conditions work in the Policy engine. This will allow users to add targets like: All Windows servers or ONLY Ubuntu servers, and so on.

Instead of a confusing “No execution” target – we’re adding ON/OFF switch to easily turn on or off orchestration rules.

Expanded* policies to support RDS and S3 services.

Cloud Service Gateway

The Cloud Service Gateway was first announced in Public Preview in Enterprise Scalr 7.6.0. After countless hours of refactoring, it is now generally available. The Cloud Service Gateway (CSG) acts as an API proxy between your applications and cloud provider services, providing complete compatibility with tools, documentation and more. Developers just point to the endpoint hosted in your Scalr infrastructure and everything works the same, but you’ll get visibility into, and control of, cloud service consumption. In other words, you can give developers native API access to cloud services (anything from Amazon Lambda to Google BigQuery) inside each cloud provider with the benefit of using an abstracted API to maintain control. This has the added benefit of giving them immediate access to all cloud services as soon as they are released, as opposed on waiting for the CMP to add support.