External Publication
Visit Post

FluidCloud’s Large Infrastructure Model targets the multicloud networking gap

Network World [Unofficial] March 12, 2026
Source

Migrating entire workloads from one cloud to another is not a trivial matter.

Terraform, the de facto standard for Infrastructure-as-Code (IaC) technology, was designed to make infrastructure portable across cloud providers. The reality is more nuanced and often painful. Each cloud provider uses its own resource dialects, migrations stretch into months of manual rewrites, and AI tools that claim to generate production-ready IaC still fail on networking, IAM, and service dependencies.

FluidCloud, a Pleasanton, Calif.-based startup that emerged from stealth in July 2025 with $8.1 million in seed funding, is launching what it calls a Large Infrastructure Model (LIM). LIM is a purpose-built AI engine for generating, translating, and validating Terraform across multicloud environments. The company argues that scanning a cloud environment and generating IaC is not the same as actually being able to move that infrastructure to another provider.

“Most of the companies that are out there in the market, when they scan cloud environments and generate an IaC, they call it resilience,” Sharad Kumar, co-founder and CEO of FluidCloud, told Network World. “The real resilience is if you have the power to move that somewhere else. You can move that into another region. You can move that into another cloud provider. Then I can call it true resilience.”

LIM is not a fine-tuned LLM

The idea of using a Large Language Model (LLM) and then fine-tuning it for a specific use case is not a new idea; that’s how all kinds of industries are now getting advanced AI with applicable domain knowledge to work.

The architecture behind LIM differs from how most AI infrastructure tools are built. Harshit Omar, co-founder and CTO, said the system is not built on a base model like Llama or a standard fine-tuned LLM.

“It’s a mixture of multiple models,” Omar told Network World. “The conversion and the core capability are not an LLM; it’s our own conditional model.”

A standard LLM sits at the front end to parse user intent. The Terraform generation and cloud-to-cloud conversion work runs on custom foundation models trained on infrastructure patterns. The training data is entirely synthetic. FluidCloud generated its own Terraform configurations and used its own conversion technology to build the training corpus.

“We have generated a lot of Terraform, and we use our own technology to generate more and more Terraform,” Omar said. “That’s what is powering the LIM.”

FluidCloud benchmarked LIM using BLEU score, a standard metric for evaluating generated output accuracy against reference results. Omar said the model currently scores 0.58. A score of 0.60 represents human-level performance on Terraform generation tasks.

What LIM adds to the platform

Before LIM, FluidCloud’s platform required a direct cloud scan as input and covered roughly 25 to 30 resource types. Coverage has since expanded to 150-plus resources across cloud providers.

The input model has also changed. Previously, the platform required a controlled scan to produce output. LIM accepts existing GitHub repositories containing Terraform code. It handles multiple Terraform syntax styles, including module-based, workspace-based, and variable configurations. It also supports custom mapping overrides.

LIM adds a compatibility scoring layer that runs before a migration begins. Given an existing infrastructure, it estimates what percentage of workloads will fail on a target platform. LIM also introduces outage prediction. The engine analyzes cloud provider release cycles, public network latency data between regions, and scheduled OS upgrade windows. The company is planning a public community page to publish upcoming outage predictions so enterprises can subscribe for advance notice.

The platform includes 1,800 compliance policies out of the box. Those policies cover major hyperscalers, as well as neocloud providers such as Vultr, OVH, and Hetzner.

Network stack translation and optimization

Cross-cloud networking is one of the harder translation problems in multi-cloud migrations. VPC configurations, private tunnels, security groups, and firewall rules are all expressed differently across providers, and moving them manually is where migrations typically stall.

LIM replicates the full network stack when translating infrastructure between clouds. “We replicate the whole network stack as well in the other cloud, so you really don’t lose anything,” Omar said. “All the cloud providers provide the same functionality. It’s just different ways of computing it.”

LIM is trained on cross-provider DevOps and infrastructure patterns, so it handles the translation without requiring the engineering team to learn each cloud’s networking dialect from scratch.

Beyond migration, LIM also functions as an optimization layer. Omar explained that every infrastructure change a DevOps engineer makes falls into one of three categories: cost, security, or performance. LIM models those variables and weights them based on the intent it detects.

“If you give different weightage to each of them, it produces a new infrastructure,” Omar said. “LIM understands DevOps intent. What it is trying to look for, if it is reducing cost, if it is improving the performance, and then balances out the configuration.”

On outage prediction, Omar said upstream fiber providers are a minimal factor in cloud outages. The bigger driver is release cycle pressure. “The majority of the times it’s either some bad release or something on the release cycle,” he said. “With pressure on each of those cloud providers to provide newer and newer services, and also with AI and vibe coding, the quality controls, the outages are becoming more and more.”

Omar said the next development priorities include an agent builder for creating custom infrastructure workflows via MCP, and portable SDKs that abstract cloud provider APIs. With those SDKs, switching a cloud deployment would require changing an environment variable rather than rewriting API calls.

“There are a lot of agentic workflows which we are coming up with, which are almost going to give superpowers to the users,” Kumar said.

Discussion in the ATmosphere

Loading comments...