Case Study: Why Ably Switched from Terraform Cloud to Scalr

About Ably

Ably provides the capabilities to deliver live experiences without go-live delays, runaway costs, and unhappy users. Ably's Serverless WebSocket platform reliably handles high-scale realtime data distribution to web and mobile apps at the edge, so engineering teams can focus on core product innovation without having to provision and maintain complex realtime infrastructure.

Developers at companies like HubSpot, Toyota, and Webflow use Ably's APIs and global edge network to power things like business-critical live chat, food order delivery tracking, and document collaboration for more than 300 million people each month.

The Challenge: Please Wait in the Queue

As Ably grew, so did their infrastructure footprint, and that meant more and more Terraform workspaces and Terraform operations. They started noticing that runs were getting stuck in a queue. When they dug into their TFC plan, it only included one runner. That was fine when they first started using Terraform, but it was time for an upgrade.

HashiCorp doesn't put detailed pricing on their website, so Ably set up a call with their sales team to find out more. The quotes that came back led them to evaluate other providers.

Ably's queue problem is the failure mode of concurrency-based pricing, which some competitors use. You buy a fixed number of parallel run slots, and there's no number that's right. Too few and engineers queue during releases or incidents. Too many and you're paying for idle capacity. Usage-based, per-run pricing only charges for runs that actually executed, so there's no slot count to mis-provision in the first place. (How to evaluate IaC platform pricing models covers the trade-offs in depth.)

Ably's Terraform Requirements

The criteria below map closely to the factors in our guide on alternatives to Terraform Cloud. When evaluating different Terraform service offerings, the key areas Ably looked at were:

1. Migration effort: will we need to drastically change our current code base and ways of working?
2. State management: is state storage part of the service?
3. SLA: Terraform is critical to our workflow, so we need a reliable service with an SLA to back it.
4. Support terms: if something goes wrong, how quickly can we expect a response?
5. Cost, including future growth: if we grow by 10x, will the pricing still be competitive?
6. Disaster recovery: are we going to be dead in the water if the provider suffers an outage?

Why Scalr

Ably found that Scalr is the only other Terraform service provider to support the remote and cloud Terraform backend configurations. That mattered both for the developer experience and operationally. Without those features, they'd have had to spend a lot of time rolling out their own state management system, and setting up access control so engineers could still run a terraform plan locally but not have permission to run terraform apply.

Being able to run a terraform plan against a production workspace without committing code keeps the feedback loop short, which is a big deal for the developer experience.

Scalr also ticked all the other boxes:

• 99.9% uptime SLA
• 2-hour ticket response time
• Transparent pricing with an easy-to-use calculator on their pricing page
• Custom hooks: the ability to run scripts at specific events in the Terraform workflow, such as post-apply for automatic DR state export and Terraform CDK support

The Migration

There were two stages to Ably's switch from TFC to Scalr:

1. Build-up: Creating all the prerequisite resources, such as Scalr environments and workspaces, and AWS IAM roles.
2. State Migration: Migrating the state for all workspaces from TFC to Scalr.

The goal throughout this process was to minimize any disruption to engineers and allow them to use TFC until the last second.

Build-up

Scalr supports AWS IAM role delegation, which meant Ably could use temporary credentials and could remove the AWS IAM user they had to use for TFC.

They used the Scalr Terraform Provider to make Scalr manage itself after an initial bootstrap step. All TFC workspaces were already managed in Terraform code, so creating the Scalr equivalents was easy: branch off main, add the Scalr Terraform provider, change tfe_workspace to scalr_workspace, and update a few variable names.

State Migration

Using both Scalr's and TFC's APIs, Ably created a bash script to migrate state across all workspaces:

1. Parsed the workspace name from code
2. Found the corresponding workspace_id in both TFC and Scalr
3. Downloaded the existing state from TFC and Scalr
4. Compared the serial and lineage as safety checks
5. Uploaded the state to Scalr if the TFC serial was larger or the state didn't exist in Scalr

Because the script checks the state serial, they could run it on demand to transfer the latest state files. That let them run a plan on each Scalr workspace to verify permissions, variables, and that Terraform didn't show any differences compared to TFC.

Going Live

On the go-live day, Ably locked all TFC workspaces, ran the state migration script once more, and executed plans on all Scalr workspaces one last time. After they passed, they merged the pre-prepared PRs and asked engineers to update any feature branches they were working on.

Total downtime: approximately 20 minutes. It all went without a hitch.

Results

Ably has been running on Scalr for over 3 months. Beyond the pricing, they point to the working relationship with the Scalr team, who take product suggestions and answer questions directly. Several features Ably asked for have since shipped, including Git submodule support and pre-init custom hooks.

Key Takeaways

Metric	Detail
Migration Downtime	~20 minutes
Migration Approach	Phased: build-up via Terraform provider, state via API bash script
Primary Driver	Run concurrency (queue bottleneck) and cost
Key Requirement	remote/cloud backend support for local terraform plan
Result	No disruption to engineers, responsive support, feature requests shipped