Masterpoint stands with Ukraine. Here’s how you can help Ukraine with just a few clicks. >
Cursor logo
Masterpoint logo
CASE STUDY SUCCESS STORY

75% Faster Plans, 2x Daily Applies: How Cursor Rebuilt Its Terraform Workflow with Masterpoint

~8 min → ~2 min
median plan time (production)
~194 → 500+
deployment PRs / week (+157%)
54 → 5
median resources affected (91% smaller blast radius)
100+
narrow, independent root modules

At Masterpoint, we focused on Terraform and IaC improvements so our client Cursor could focus on making their users extraordinarily productive.

At a Glance

Key Value Delivered

Dramatically faster plans

Plan time dropped significantly. Originally plan time had spikes of 10+ minutes; after our work, plan time was roughly 2 minutes.

Improved delivery speed

Engineers shipped 157% more PRs per week after the engagement, and have increased shipping cadence since.

More frequent, safer deploys

Weekly infrastructure PRs grew from 194 to 500+, and fewer plans were abandoned as the apply-to-plan ratio improved from 55% to 64%.

Safer, more contained changes

The median Terraform run now touches 5 resources instead of 54 — a 91% smaller blast radius, so engineers can reason about exactly what a change will affect before applying it.

The Challenge

The Problem: Infrastructure That Couldn’t Keep Up

By late 2025, Cursor’s Terraform setup had become one of the biggest friction points in the engineering org. The company behind the Cursor IDE experienced issues familiar to fast-growing startups: infrastructure code written quickly, then scaled by copy-pasta rather than through careful design.

Those early Terraform patterns were replicated at machine speed as engineers dogfooded Cursor. They were copied and instantiated hundreds of times without the architectural guardrails needed to keep the system manageable. The result was a classic terralith: critical infrastructure was managed as a single monolithic production workspace with over 7,000 resources in one state file.

And because that workspace was so large, it was too slow.

But the problem wasn’t just the lack of speed. It was a lack of engineering confidence in the IaC system. Issues included:

  • The AWS console was used to make changes during incidents and these fixes were never rolled into TF, and so were later inadvertently reverted.
  • Managing ECS deployments through Terraform caused constant drift in the production terralith, flooding PR diffs with hundreds of unrelated changes.

Over time, the team stopped trusting the system, let alone reading the diffs.

This confusion caused downtime, such as a network firewall change that caused a 10 minute outage.

The existing platform, Terraform Cloud, introduced some friction too:

  • Workspace management relied on manual ClickOps configuration for each new workspace.
  • The SSO experience was inconsistent.
  • TFC’s resource-under-management (RUM) pricing model made it daunting to scale.
The Engagement

What Masterpoint Did

Masterpoint came in for a systematic overhaul, working across the architecture, the platform, and the developer workflow.

February 2026 · migration done
Terraform Cloud + Terraformworkspaces migrate off in phases
Spacelift + OpenTofupilot stack first, then bulk migration

November 2025 - Audit and High Leverage Fixes #

The engagement opened with an audit of Cursor’s infrastructure:

  • cloud environments
  • IaC setup
  • CI/CD pipelines
  • networking
  • observability

Within a week, Masterpoint delivered an audit report, a best practices checklist, and a security scan. The findings included IAM duplication accounted for 70% of the production TF state and noisy plan diffs caused engineer fatigue.

The audit phase targeted the highest-leverage fixes first: IAM resource deduplication, workspace trigger and path filter corrections so plans only ran when relevant code changed, and initial provider alias splits to begin isolating staging and ML infrastructure from the main production workspace.

By November 25th, the IAM deduplication fixes had landed.

MetricBeforeAfterChange
Resource Count8,4804,59345.8% reduction (3,887 resources removed)

The number of production resources dropped from 8,480 to 4,593, a 46% reduction. Mean plan time fell from 8.1 minutes to 4.9 minutes, a 39% improvement. The P95 plan time improved even more.

MetricBefore (Nov 20–24)After (Nov 25–Dec 8)Improvement
Mean488.8s (8.1 min)296.6s (4.9 min)39.3% faster
P50 (Median)423s (7.1 min)272s (4.5 min)35.7% faster
P95749s (12.5 min)414s (6.9 min)44.7% faster
Sample Size38 runs184 runsn/a

This was accomplished without touching the workspace structure, but the systems could still be improved.

December 2025 - Spacelift Migration Begins #

With the first phase complete, Masterpoint turned to the platform.

As mentioned above, TFC’s ClickOps workspace management, SSO troubles, and resource-under-management pricing were all inhibiting Cursor’s velocity and growth.

Masterpoint recommended a move to Spacelift to address these issues.

The team kicked off the Spacelift migration in mid-December, starting with the groundwork:

  • naming and tagging standards
  • AWS multi-account IAM role architecture
  • Okta SSO configuration

Rather than migrating everything at once, a low-risk pilot Spacelift stack (the equivalent of a TFC workspace) was used to validate the approach. The end-to-end fully automated pilot project was completed within days.

Masterpoint also began evaluating a full migration from the Terraform runtime to OpenTofu.

January to February 2026 - Bulk Migration #

With a plan covering a migration of dozens of TFC workspaces across four phases, the team worked systematically. By late January, the bulk of workspaces had been migrated to Spacelift stacks with no operational downtime for the Cursor engineering organization.

By February, the migration was done. All workspaces had been moved from TFC to Spacelift and the runtime was converted from Terraform to OpenTofu. Migrating to OpenTofu freed Cursor from licensing constraints and unlocked capabilities unavailable or paywalled in Terraform, such as state encryption, OpenTelemetry support, and provider iteration.

As part of the final migration work, the production workspace was reduced by splitting out various provider-aliased resources into dedicated stacks, continuing the decomposition work that had started with IAM deduplication in November.

February to May 2026 - AI Agent Guardrails And Additional Improvements #

After the migration was completed, Masterpoint continued to improved system usability and speed by:

  • restructuring Route53 DNS API requests into optimized, dedicated TF modules to address AWS’s strict 5 requests/second limit
  • continuing to break up large state files into narrower root modules, allowing for faster plans (further reducing critical infrastructure plans from roughly 5 minutes to under 2 minutes) and decreased blast radius
  • implementing child module versioning with OCI registries to enable staged rollouts and safer change control of critical TF resources
  • resolving the ECS drift issue by using the “Task Definition Template Pattern”
  • implementing OpenTofu’s OTel tracing to set up the Cursor team for longterm visibility into their IaC throughput

Because Cursor’s engineering team uses Cursor to write Terraform, Masterpoint embedded architectural knowledge directly into the codebase as AI agent skills and rules.

This AI context encodes the decisions that AI models cannot anticipate on their own:

  • when to create a new root module vs. extend an existing one

  • how to scope blast radius in a root module

  • how to break up a high blast radius monolithic root module

  • data source patterns and optimizations

  • how to use OCI-sourced child modules

  • security practices, such as TF module SHA pinning

  • debugging performance bottlenecks, through methods such as logging and OpenTelemetry traces

Every IaC optimization Masterpoint delivered was paired with instructions to prevent anti-patterns from being reintroduced.

The Results

What Cursor’s Infrastructure as Code Manages #

The Cursor infrastructure today includes:

  • hundreds of ECS services with tens of thousands of live running tasks

  • thousands of EC2 instances

  • dozens of Redis clusters

  • a few dozen databases

  • in the triple digits of ALB and NLB load balancers

In all 40k+ Terraform resources are managed using the new platform. All of this exists in 100+ narrow, independent root modules, with OpenTofu, on Spacelift, using Okta SSO, stored in S3-backed state, and paired with AI agent rules to keep the architecture clean as the codebase grows.

Numbers That Matter #

  • Median plan time (production)
    Before~8 min
    After~2 min
  • Deployment PRs / week
    Before~194
    After500+ (+157%)
  • Median resources affected
    Before54
    After5 (91% reduction in blast radius)

Plan time went from 10+ minutes to 2 minutes #

Dial gauge: a typical Terraform run dropped from 10+ minutes to a steady 2 minutes per run, 80% of the wait gone

The production workspace plan time dropped from over 10+ minutes, with spikes to 15 minutes, during the November baseline to around 2 minutes by mid 2026.

This is an improvement of roughly 75% from where the engagement started, and more than 80% from the pre-engagement peak.

Deployment frequency increased #

Stat card: 2.6x more PRs shipped, from 194 to 500+ changes shipped every week, a 157% jump in deployment frequency

Weekly merged PRs against infrastructure as code went from approximately 194 per week to over 500 a week, a 157% increase. They’ve only accelerated since then.

The productivity lift was significant #

This gain wasn’t from growing the engineering organization: a controlled same-cohort analysis of 34 engineers active both before and after the Masterpoint engagement found that PR throughput grew by 121%.

MetricPre-engagementEnd of EngagementChange
Cohort throughput63 PRs/wk140 PRs/wk+121%
Per-active-week cadence5.37 PRs/author/wk9.19 PRs/author/wk+71%

Infrastructure became democratized #

Bar chart of Terraform root module workspaces growing from 21 in October 2025 to 141 by May 2026, a 571% increase

Looking beyond the controlled same-cohort set of engineers, 89% of all engineers who work with infrastructure now ship Terraform PRs each month.

Previously, workspace creation required manual ClickOps and admin access. Today, engineers create and manage their own stacks. The number of separately managed modules went from 26 to 100+. Engineers are now creating their own product/domain scoped infrastructure instead of jumbling it in the primary monolithic workspace.

What Changed for the Team

Engineers know what an IaC Terraform change will touch #

Before the engagement, engineers couldn’t predict what a change would actually touch in a workspace. A database might live in a workspace named for networking infrastructure, so even finding where something was managed required tribal knowledge. Dependencies between workspaces were just as opaque: touching one piece of infrastructure could ripple into systems that had nothing to do with the change — or surface long-standing drift that did. Plans intended for one system would silently queue in unrelated workspaces, waiting for the next person to find them with no context on where they came from or whether they were safe to apply.

With smaller, focused stacks, plans are scoped to the change at hand. The median Terraform run now touches just 5 resources instead of 54 — a 91% smaller blast radius — so engineers know precisely what a plan will affect before they run it.

Before and after dot graph: a median Terraform run once touched 54 resources, now it averages just 5, a 91% reduction in blast radius

Architectural flexibility enables the business and product delivery #

Before the engagement, the terralith made architectural changes expensive and risky. Touching one piece of infrastructure meant disrupting unconnected components.

With narrow stacks owning a focused piece of infrastructure, the Cursor engineering team can more easily modify their architecture.

New services, providers, and cloud targets can be added as their own stacks, which is a foundation that directly enables expansion into multi-cloud infrastructure as Cursor continues to scale.

Cursor’s agents are set up for future success #

Since Cursor’s engineers rely on Cursor to write their own Terraform, Masterpoint embedded the new architecture into AI agent rules and skills that sit directly within the codebase.

These rules capture the patterns and decisions that LLMs can’t figure out on their own, setting the team up to consistently ship high-quality infrastructure code, now and as the system evolves.

If your team is hitting Terraform ceilings like:

  • infrastructure that's grown faster than the architecture supporting it
  • slow plans and noisy diffs
  • platform friction

Masterpoint can help. We've done this work at scale, for engineering organizations that can't afford to slow down. Get in touch →

Get a standardized, predictable, and efficient infrastructure management process

Skip the stress and let us organize the mess. Reach out today for a free assessment.

Schedule Your Free Assessment →