How NeuBird established measurable infrastructure recovery and faster provisioning with FluidCloud
NeuBird captures its AWS configuration twice a day and can rebuild any environment from it. The same capture stands up a new isolated customer environment in about an hour, against about seven days before.
NeuBird AI runs its AI operations platform on AWS and gives its largest enterprise customers dedicated, single-tenant deployments. Working with FluidCloud, it reads every account through a read-only cross-account role, captures the full configuration on a schedule, and generates deployment-ready Terraform that will either provision an environment or rebuild one.
At a glance
Provisioning time is attested by NeuBird's platform engineering team. Capture figures are taken from FluidCloud platform records for the NeuBird tenant, 23 April to 2 September 2026.
- 7 days → 1 hour
- To stand up an isolated customer environment from a capture, a 99.4% reduction. A rebuild follows the same path.
- 1,085
- Configuration recovery points across 132 consecutive days, where none existed before
- 794
- Configuration changes found in a single AWS Region between two consecutive captures
- Twice daily
- Every AWS account captured on a schedule, so a rebuild never starts from a blueprint more than about 12 hours old
Scaling dedicated environments for enterprise customers
NeuBird AI builds autonomous agents that work alongside human site reliability engineers to prevent, detect and resolve production incidents, delivering a 90% reduction in mean time to resolution for the enterprises it serves.
NeuBird has raised $64M, holds the AWS Generative AI Competency, and has resolved more than 1M production alerts for its customers. It was founded by Gou Rao and Vinod Jayaraman, who previously built and sold Portworx to Pure Storage for $370M.
Its largest enterprise customers need dedicated, single-tenant deployments to meet their own security and compliance obligations, so NeuBird's AWS estate is several isolated environments rather than one. Like most platform teams, NeuBird described them with a maintained Terraform library. As the number of environments grew, that library set the pace of onboarding, and it was also the artifact any rebuild would start from. NeuBird wanted both to come from the accounts themselves.
Capturing AWS configuration and generating deployable Terraform
FluidCloud connects to each of NeuBird's AWS accounts through a cross-account IAM role assumed with a per-tenant External ID. Discovery is read-only and agentless: the scans install nothing in NeuBird's accounts and modify no resources.
Capture runs twice daily against the AWS accounts and daily against the Azure account. Each capture is an immutable, individually addressable record of the estate, and deployable Terraform with a matching state file can be regenerated from any of them. FluidCloud compares each capture with the one before it and reports what was added, modified and removed. AWS CloudTrail records every read-only call, so NeuBird keeps an independent audit trail of what was accessed.
NeuBird chose this over the conventional alternatives. A warm standby estate carries continuous AWS cost for capacity used only during an incident. Snapshots and AWS Backup protect volumes, databases and objects, which NeuBird still retains, but not Amazon VPC topology, security groups, IAM roles, load balancer configuration or the order resources must come up in. AWS CloudFormation or the AWS CDK would have added a second infrastructure-as-code format alongside the Terraform NeuBird already ran, across an estate that also spans Azure. The cross-account role, scoped and revocable by NeuBird with no long-lived credential to distribute, is what kept the security review proportionate.
One capture that provisions and rebuilds
Because the artifact NeuBird provisions from is generated out of live AWS state, provisioning time and recovery position improved together rather than as separate projects.
Standing up an isolated enterprise customer environment now takes about an hour, against about seven days before. Engineers previously wrote or adapted Terraform for the target AWS account, configured CI/CD pipelines, provisioned secrets through AWS Secrets Manager for each deployment and validated the result against production. Provisioning from a capture taken out of the live account removes that reconciliation work. NeuBird's first account scan ran on 23 April 2026, and its first environment deployment completed the following day, under 21 hours later, including the initial account connection.
Across 132 consecutive days NeuBird has accumulated 1,085 configuration recovery points with no gap in the series, and every capture reports the drift since the last one. In one representative measurement that was 794 changes in a single AWS Region between two consecutive captures, which is the scale of change a hand-maintained library absorbs quietly. Because the reconstruction path is held as code, NeuBird runs no standby AWS estate between incidents.
Results
Four measures of what changed, taken from platform records and NeuBird's own timings.
| Metric | Before FluidCloud | With FluidCloud |
|---|---|---|
| Time to stand up an isolated customer environment | About 7 days, each environment a separate infrastructure project | About 1 hour, provisioned from the latest capture |
| Retained configuration recovery points | A manually refreshed Terraform library | 1,085 captures across 132 consecutive days, no gap in the series |
| Age of the blueprint a rebuild starts from | Set by the last manual refresh | Never more than about 12 hours old, from capture twice daily per AWS account |
| Configuration drift between recovery points | Surfaced when a template was applied | Quantified per resource on every capture, as added, removed or modified |
Provisioning times are attested by NeuBird's platform engineering team. Capture and drift figures are taken from FluidCloud platform records for the NeuBird tenant, covering 23 April 2026 to 2 September 2026.
What is next
Stateful workload migration is under evaluation, and remote Terraform state integration is on the FluidCloud roadmap.
Volume and Kubernetes workload migration
Reconstruction covers the infrastructure layer. For a platform running on Amazon EKS, stateful workload movement is a documented step in NeuBird's recovery procedure, and widening capture to cover it is on the evaluation path.
Remote Terraform state integration
Drift is reported by comparing successive captures. The integration would let FluidCloud reconcile captures against a team's existing Terraform state backend, so one source stays authoritative during a recovery.
See how FluidCloud captures AWS configuration for recovery
See FluidCloud capture a live AWS account, identify the configuration changes since the previous capture, and generate deployable Terraform for reconstruction or provisioning.