How NeuBird established measurable infrastructure recovery and faster provisioning with FluidCloud
NeuBird had no recurring capture of its infrastructure configuration, and so no recovery point objective for it. FluidCloud now captures its AWS accounts twice daily, establishing a recovery point of roughly 12 hours without a standby AWS estate.
NeuBird runs its AI operations platform on AWS, and gives its largest enterprise customers dedicated, single-tenant deployments. FluidCloud reads each account through a read-only cross-account role and captures its full configuration twice a day, generating deployment-ready Terraform. NeuBird can reconstruct the infrastructure from any retained capture.
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.
- ~12 hours
- Recovery point objective for infrastructure configuration, where none was defined before
- 1,085
- Configuration recovery points across 132 consecutive days with no gap in the series
- 794
- Configuration changes found in a single AWS Region between two consecutive captures
- 7 days → 1 hour
- To provision an isolated enterprise customer environment, a 99.4% reduction
Operating dedicated AWS environments for enterprise customers
NeuBird AI builds autonomous agents that work alongside human site reliability engineers to prevent, detect and resolve production incidents.
Its platform delivers 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.
NeuBird's largest enterprise customers cannot use a shared environment. Security policies, compliance mandates and contractual obligations require dedicated, single-tenant deployments, so the AWS estate is several isolated environments rather than one, each changing independently.
Why NeuBird could not reliably reconstruct its AWS environments
NeuBird held no current, machine-readable model of its AWS estate, and therefore no dependable way to reconstruct any part of it.
The compute layer was never the hard part. The difficulty was the accumulated configuration no document held accurately: VPC topology, subnets and routing, security group rules, IAM roles and their trust relationships, load balancer target groups, RDS parameter and subnet groups, and the references binding workloads to AWS Secrets Manager entries and Amazon ECR image tags. Those dependencies determine how an environment is reconstructed, and they were recorded in the AWS accounts and retained in engineers’ operational knowledge, but not in any single current model.
NeuBird maintained a parameterised Terraform library to describe all of it. The library could fall out of step with the deployed accounts, because changes to services, security groups and IAM policies moved the accounts and not the code. NeuBird did not measure those differences, so their size was unknown at any moment.
No defined recovery point objective
No recurring capture of environment state existed, so NeuBird had no recovery point for infrastructure configuration and nothing against which to define an objective.
Configuration drift was not measured
NeuBird identified drift when a template was applied and the result did not match production. FluidCloud has since recorded 794 changes in one AWS Region between two captures.
Seven days to provision each customer environment
A newly signed enterprise customer could not go live until its isolated environment had been provisioned, which put infrastructure delivery on the critical path to revenue.
Recovery artifacts could differ from production
The Terraform NeuBird would rebuild from could be out of date, and nothing validated it against the deployed environment until a rebuild was already underway.
Capturing AWS configuration and generating deployable Terraform
FluidCloud connects to NeuBird's AWS accounts through a cross-account IAM role assumed with a unique per-tenant External ID. Discovery is read-only and agentless: the scans install no agents in NeuBird's accounts and modify no NeuBird resources.
Capture runs twice daily against the AWS accounts and daily against the Azure account. Each capture is an immutable record of the estate at that moment, individually addressable and retained, and deployable Terraform with a matching state file can be regenerated from any of them. FluidCloud compares each capture against the one before it and reports what was added, modified and removed.
CloudTrail records account activity including FluidCloud's read-only API calls, so NeuBird holds an independent audit trail of what was accessed.
Choosing captured Terraform over a standby AWS estate
NeuBird evaluated warm standby, snapshot replication, alternative infrastructure-as-code formats and static access credentials. Each was set aside for a specific reason.
Warm standby in a second account or Region
It carries continuous AWS cost for capacity used only during an incident, and drifts from production unless continuously reconciled. FluidCloud retains deployable Terraform instead, so NeuBird maintains no standby AWS environment between incidents.
AMI and snapshot-based replication
Snapshots and AWS Backup protect volumes, databases and objects, and NeuBird retains them. They do not capture VPC topology, security groups, IAM roles, load balancer configuration or the order resources must come up in. NeuBird retains them for stored data, and FluidCloud captures infrastructure configuration.
CloudFormation or AWS CDK as the output
CloudFormation or AWS CDK would have added a second infrastructure-as-code format alongside the Terraform NeuBird already operated. Its estate also spans AWS and Azure.
IAM user access keys for connection
The cross-account role is created, scoped and revocable by NeuBird unilaterally, no long-lived credential is distributed or stored, and the per-tenant External ID prevents the confused deputy problem. NeuBird records this as the decision that kept its security review proportionate.
Reducing environment provisioning from seven days to one hour
The same captured configuration now supports both provisioning and infrastructure recovery.
Provisioning an isolated enterprise customer environment took about seven days. Engineers 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 before go-live. Using configuration captured from the live AWS account removes that reconciliation work, and the same environment now takes about an hour.
FluidCloud platform records support the figure. NeuBird's first account scan ran on 23 April 2026, and the first environment deployment completed the following day, under 21 hours later, including the initial account connection.
One captured configuration serves provisioning and recovery, and successive captures measure the drift between them. NeuBird improved provisioning time and recovery position together rather than as separate initiatives.
Results
Four measures of what changed, taken from platform records and NeuBird's own timings.
| Metric | Before FluidCloud | With FluidCloud |
|---|---|---|
| Recovery point objective for infrastructure configuration | None defined. No capture interval existed. | Approximately 12 hours, from capture twice daily per AWS account |
| Retained configuration recovery points | None. NeuBird maintained a manually refreshed Terraform library. | 1,085 captures across 132 consecutive days, no gap in the series |
| Configuration drift between recovery points | Unmeasured, and visible only when a template failed to apply | Quantified per resource on every capture, as added, removed or modified |
| Time to provision an isolated customer environment | About 7 days, each one a separate infrastructure project | About 1 hour, a reduction of approximately 99.4% |
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 remains manual, and that step is documented explicitly in NeuBird's recovery procedure.
Remote Terraform state integration
Drift is detected by comparing successive captures rather than by reconciling against a remote state backend. The integration would let FluidCloud reconcile captures against a team's existing Terraform state, 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.