# formae > formae is an Infrastructure As Code platform: it discovers what is really running, keeps code as the source of truth, and applies changes at any granularity with minimal blast radius. Built by Platform Engineering Labs. This file is every page of formae.ai in one document. The map with one line per page is at https://formae.ai/llms.txt. --- ## formae - Infrastructure on autopilot Source: https://formae.ai --- title: "formae - Infrastructure on autopilot | Platform Engineering Labs" description: "Infrastructure on autopilot: full control, no effort. Start from nothing or bring in what you already run. formae from Platform Engineering Labs." url: "https://formae.ai" --- Our past selves needed this, so we built it for you # Infrastructure on autopilot Full control. No effort Start from nothing, or bring in what you already run. Either way you get your infrastructure automatically managed. Nothing to babysit, no time wasted in the loop, and you can step in any time. - Nothing to migrate - No legacy dependencies - Zero to running in minutes - Any cloud Is formae for me? [Pricing](https://formae.ai/pricing) hello, formae ### Featured in ![Forbes](https://formae.ai/media/formae/forbes-800c.webp?__frsh_c=pma73x0pm9h0) ![The New Stack](https://formae.ai/media/formae/thenewstack-1032c.webp?__frsh_c=pma73x0pm9h0) ![InfoQ](https://formae.ai/media/formae/infoq-148c.webp?__frsh_c=pma73x0pm9h0) ![SiliconANGLE](https://formae.ai/media/formae/siliconangle-1014c.webp?__frsh_c=pma73x0pm9h0) > "formae is a significant evolutionary leap forward in both DevOps and software development. It represents a shift in thinking as fundamental as source control, as practical as package management, and as vital as observability. formae's impact will extend beyond improving the lives of DevOps and engineering teams to creating lasting and reliable value for businesses and their customers." Harry Brumleve Founder of strategic technology firm Thoughtful Software ## Used to manage real infrastructure 400k+ Resources 3.1k+ Installations ## formae is for you, whoever runs your infrastructure Click your role and see which offering fits Startup CTO Software Engineer Solution Engineer DevOps Engineer Site Reliability Engineer Platform Engineer Enterprise CIO Enterprise Architect CISO ![A woman in her fifties with a silver bob, arms crossed, in a brass pressure suit, an aisle of server racks behind her](https://formae.ai/media/formae/icp-enterprise-cio-800.webp?__frsh_c=pma73x0pm9h0) Signer of the cheques Best fit [formae IaC](https://formae.ai/formae-iac) You sign for the estate, the audit and the migration, and you are asked for one number by people who will not read the detail. What you want - Risk on the record - Fewer tools - Cost you can defend What you don't want - Estates nobody can list - Headcount to make up for tooling - Migrations that stall Why formae - An inventory of what is really running, across clouds, without a discovery project - Most of what your teams do by hand is automated out of the box, with nothing to build - Adopt it on the estate you already have, with no big-bang migration to approve Where to go next - [What is formae](https://formae.ai/what-is-formae) - [Pricing](https://formae.ai/pricing) ![A smiling man in his sixties with close-cropped grey hair and a beard, in a brass pressure suit, a dim hall of equipment behind him](https://formae.ai/media/formae/icp-enterprise-architect-800.webp?__frsh_c=pma73x0pm9h0) Maker of the map Best fit [formae IaC](https://formae.ai/formae-iac) You decide how infrastructure is described across a company that has already decided nine different ways. What you want - One way to describe it - Standards people actually follow - Choices that survive a reorg What you don't want - A dialect per team - Wiki pages nobody reads - Exceptions that become the rule Why formae - One way to describe infrastructure instead of one per team and per vendor - The standard is executable: a forma is the document and the deployment - Roll it out against what already exists, team by team, without a mandate Where to go next - [What is formae](https://formae.ai/what-is-formae) - [How formae is built](https://docs.formae.ai/documentation/concepts/architecture) - [formae IaC](https://formae.ai/formae-iac) ![A young man in a beanie, arms crossed, in a brass pressure suit, a lit desk lamp behind him](https://formae.ai/media/formae/icp-startup-cto-800.webp?__frsh_c=pma73x0pm9h0) Wearer of every hat Best fit [formae Cloud](https://formae.ai/formae-cloud) You write the product code and ship it. Then you get woken up when it breaks, and you pay the cloud bill. And neither of those is the job you took. What you want - Ship fast - Everyone on the product - Nothing to babysit What you don't want - Own infrastructure - Hire DevOps to run it - Anyone stuck on plumbing Why formae - Your team stays on the product instead of looking after infrastructure - A new service is live the day you write it, not the week after - It stays in order as you grow, with nobody babysitting it Where to go next - [formae Cloud](https://formae.ai/formae-cloud) - [Pricing](https://formae.ai/pricing) - [Quick start](https://docs.formae.ai/documentation/get-started/quickstart-cloud) - [Go to Console](https://console.formae.ai/) ![A man with a short beard, in a brass pressure suit, a glass office wall behind him](https://formae.ai/media/formae/icp-solution-engineer-800.webp?__frsh_c=pma73x0pm9h0) Winner of the bake-off Best fit [formae Cloud](https://formae.ai/formae-cloud) You have to show the thing running on somebody else's infrastructure, this week, before anyone has agreed to buy it. What you want - A PoC in no time - On any infrastructure - Something that survives questions What you don't want - Owning where you demo - Access requests - Setups that take a week Why formae - Point it at an account and it tells you what is already there - Stand up a proof of concept from nothing, then tear it down on a timer - Nothing to install in the customer's estate to show them their own estate Where to go next - [formae Cloud](https://formae.ai/formae-cloud) - [Quick start](https://docs.formae.ai/documentation/get-started/quickstart-cloud) - [Go to Console](https://console.formae.ai/) ![A smiling woman with curly hair, in a brass pressure suit, a whiteboard behind her](https://formae.ai/media/formae/icp-software-engineer-800.webp?__frsh_c=pma73x0pm9h0) Shipper of the feature Best fit [formae Cloud](https://formae.ai/formae-cloud) You wrote the service. Getting it somewhere it can serve traffic should not be a second profession. What you want - Ship it yourself - Live the same day - Nothing new to learn What you don't want - Waiting on a ticket - Learning the platform - Dealing with infrastructure Why formae - Your agent sets up what the service needs while you are still writing it - Staging and production come out the same, every time - No infrastructure team in the loop to deploy your own service Where to go next - [formae Cloud](https://formae.ai/formae-cloud) - [Quick start](https://docs.formae.ai/documentation/get-started/quickstart-cloud) - [Go to Console](https://console.formae.ai/) ![A smiling woman with locs and glasses, arms crossed, in a brass pressure suit, a dim wall of dashboards behind her](https://formae.ai/media/formae/icp-platform-engineer-800.webp?__frsh_c=pma73x0pm9h0) Builder of the golden path Best fit [formae IaC](https://formae.ai/formae-iac) You build the thing other teams build on, and you are judged on whether they use it or go around it. What you want - Abstractions nobody looks behind - Room to change what is underneath - Adoption without a mandate What you don't want - Ticket queues - Copy-pasted modules - Shadow infrastructure Why formae - Teams ask for what they need and never see what it is made of - You change what is underneath without anyone rewriting anything - Policies travel with the stack, so a guardrail is not a review meeting Where to go next - [formae IaC](https://formae.ai/formae-iac) - [Why formae IaC](https://formae.ai/why-formae-iac) - [Self-service infrastructure](https://docs.formae.ai/documentation/guides/build-self-service-infrastructure) - [Quick start](https://docs.formae.ai/) ![A smiling man with a grey beard, in a brass pressure suit, in a dark room lit from one side](https://formae.ai/media/formae/icp-ciso-800.webp?__frsh_c=pma73x0pm9h0) Owner of the worst case Best fit [formae IaC](https://formae.ai/formae-iac) You are accountable for what is actually running, who can reach it, and what happens when the answer turns out to be wrong. What you want - Provable state - Least privilege - An audit that ends What you don't want - Resources nobody declared - Exceptions that became permanent - Evidence gathered by hand Why formae - Everything is found and described without anybody being asked to declare it - Order is applied continuously, not when somebody remembers to run something - The same rules run whoever is on shift, and every change is a versioned diff Where to go next - [What is formae](https://formae.ai/what-is-formae) - [formae IaC](https://formae.ai/formae-iac) - [Why formae IaC](https://formae.ai/why-formae-iac) - [Out-of-band changes](https://docs.formae.ai/documentation/guides/deal-with-out-of-band-changes) ![A smiling woman with short hair, arms crossed, in a brass pressure suit, faint graphs on the wall behind her](https://formae.ai/media/formae/icp-site-reliability-engineer-800.webp?__frsh_c=pma73x0pm9h0) Holder of the pager Best fit [formae IaC](https://formae.ai/formae-iac) You spend the error budget, and you are the one awake when a change lands badly at 2am. What you want - The smallest possible blast radius - Patch now, not after the pipeline - Knowing what changed What you don't want - Waiting on a deploy to fix prod - Fixes nobody wrote down - "Who touched prod?" Why formae - Minimal blast radius by design: change one thing without touching its neighbours - Patch mode for the incident, reconcile afterwards, and the drift is recorded - What you are reading is what is running, not what somebody committed Where to go next - [formae IaC](https://formae.ai/formae-iac) - [Why formae IaC](https://formae.ai/why-formae-iac) - [Incidents and recovery](https://docs.formae.ai/documentation/guides/incidents-and-recovery) - [Quick start](https://docs.formae.ai/) ![A smiling man with a mohawk, septum and ear piercings and tattooed neck, in a brass pressure suit, in the blue glow of a server aisle](https://formae.ai/media/formae/icp-devops-engineer-800.webp?__frsh_c=pma73x0pm9h0) Keeper of the pipeline Best fit [formae IaC](https://formae.ai/formae-iac) You own the road from a merged branch to something running in production, and everything that goes wrong on the way. What you want - Repeatable applies - Small, safe changes - No surprises on Friday What you don't want - Drift - Snowflake servers - Being the only one who knows Why formae - State comes from what is really running, not from a file that claims to know - Apply at any granularity, from one resource to the whole stack - Out-of-band changes are captured and versioned instead of overwritten Where to go next - [formae IaC](https://formae.ai/formae-iac) - [Why formae IaC](https://formae.ai/why-formae-iac) - [formae vs. Terraform](https://formae.ai/formae-vs-terraform) - [Quick start](https://docs.formae.ai/) I don't care who runs it You want it to work. You do not want to run it. We run it ourselves You own the platform and intend to keep owning it. My org runs it You own the budget, the standards and the risk. Not the keyboard. --- ## Build on formae IaC - an AI-native Infrastructure As Code platform Source: https://formae.ai/build-on-formae --- title: "Build on formae IaC - an AI-native Infrastructure As Code platform | Platform Engineering Labs" description: "Modern infrastructure environments include internal platforms, custom systems, APIs, appliances, and services that evolve continuously. No single…" url: "https://formae.ai/build-on-formae" --- # Build on formae IaC - an AI-native Infrastructure As Code platform Modern infrastructure environments include internal platforms, custom systems, APIs, appliances, and services that evolve continuously. No single Infrastructure As Code tool, including Terraform, can natively support all of them or keep pace as they change. For infrastructure builders, extensibility is not optional. It determines whether tooling adapts to real environments or forces teams into workarounds. formae is built as an Infrastructure As Code platform, designed to be extended directly by infrastructure builders - humans and AI - wherever their infrastructure requires it. ## Infrastructure tooling should be extensible by default Traditional Infrastructure As Code ecosystems such as Terraform include a very large number of providers and even generic mechanisms to wrap REST APIs. In theory, this makes it possible to support almost anything. In practice, building and maintaining IaC providers is slow and brittle. Terraform provider development, in particular, often involves heavy frameworks, complex lifecycle handling, implicit state assumptions, and long feedback loops. Even small changes can require significant effort and ongoing maintenance. As infrastructure environments grow more heterogeneous, this complexity becomes a real constraint. Teams depend on systems that change faster than Terraform providers and similar integrations can realistically accommodate. An extensible Infrastructure As Code platform must make plugin development practical, predictable, and repeatable. ## formae is a platform for infrastructure builders formae is a platform for infrastructure builders formae turns Infrastructure As Code into a platform that builders can extend deliberately and safely. Builders add support for new technologies by writing formae plugins that define how infrastructure is discovered, represented, and managed. These plugins integrate directly with formae’s internal model and participate in the same workflows as built-in capabilities. Plugins are explicit and versioned. They behave consistently across environments and avoid fragile wrappers or ad-hoc glue code that are common in traditional Terraform provider implementations. This shifts Infrastructure As Code from assembling and maintaining providers to intentionally extending a platform. ## Build IaC plugins without fighting provider complexity Extending Terraform and similar IaC tools often means adapting real systems to fit rigid provider models. Even generic REST API providers require forcing infrastructure into abstractions that are difficult to evolve and hard to reason about over time. formae takes a different approach. The platform exposes a stable, schema-safe surface specifically designed for plugin development. Builders focus on modeling real systems and their behavior, not on framework internals, lifecycle edge cases, or Terraform-style state synchronization mechanics. In this context, “extensions” simply refer to formae plugins - first-class components that integrate cleanly with the Infrastructure As Code platform. As a result, building and evolving infrastructure plugins becomes straightforward instead of turning into a long-term maintenance burden. ## Designed for builders and AI agents Infrastructure builders increasingly work with AI coding assistants to generate code, integrations, and tooling. For this to work reliably, an Infrastructure As Code platform must expose clear, explicit interfaces and enforce strong boundaries. formae is AI-native by design. Its plugin model is explicit, schema-driven, and predictable, making it suitable for AI-assisted development without sacrificing safety or correctness. This enables builders and AI agents to work together effectively, accelerating development while preserving consistent behavior across environments. ## How to start building on formae Builders can start building plugins for formae today. Documentation explains how to design, implement, and evolve plugins, and existing examples show how real systems are modeled. Development happens against a stable interface, making iteration safe and predictable. If your infrastructure depends on a system that formae does not support yet, the expectation is simple: you should be able to add that support yourself. On this page - Infrastructure tooling should be extensible by default - formae is a platform for infrastructure builders - Build IaC plugins without fighting provider complexity - Designed for builders and AI agents - How to start building on formae ## Frequently asked questions [Plugin development](https://docs.formae.ai/plugin-development) - **How do I build a plugin for formae?** You build a plugin by implementing formae’s plugin interface, which defines how infrastructure is discovered, represented, and managed. Plugins are developed against a stable, schema-safe surface and integrate directly with formae’s internal model. - **How is building a formae plugin different from building a Terraform provider?** Terraform provider development relies on heavy provider frameworks, implicit state handling, and lifecycle logic that is difficult to evolve. formae plugins are explicit, schema-driven components designed to model real systems directly, without relying on Terraform-style provider abstractions. - **Can I use formae to support internal systems or APIs that Terraform does not cover?** Yes. formae is designed specifically to support internal platforms, custom services, APIs, and technologies that are not available as Terraform providers or are difficult to model with them. - **Do formae plugins replace Terraform providers?** formae plugins are an alternative to Terraform providers. Instead of wrapping systems in Terraform’s provider model, plugins integrate directly into formae’s Infrastructure As Code platform and participate in its workflows. - **Can I build plugins incrementally?** Yes. Plugins can be developed and evolved incrementally. You can start with discovery and basic management and expand support over time without breaking existing behavior. - **What makes formae suitable for AI-assisted plugin development?** formae is AI-native: its plugin interfaces are explicit, schema-driven, and predictable. This allows AI coding agents to generate, modify, and extend plugins safely, without relying on implicit behavior or fragile conventions. - **How long does it take to build a formae plugin?** For many systems, a working plugin can be built in hours, not weeks, especially when using modern AI coding tools alongside formae’s documentation and existing plugins. --- ## Why formae IaC: Infrastructure As Code that matches reality Source: https://formae.ai/why-formae-iac --- title: "Why formae IaC: Infrastructure As Code that matches reality | Platform Engineering Labs" description: "formae IaC discovers what is running, versions every out of band change, and derives Infrastructure As Code from live state instead of a state file. Open source, self-hosted, no migration, and it reads your existing .tfvars." url: "https://formae.ai/why-formae-iac" --- # Why formae IaC: Infrastructure As Code that matches reality [formae IaC](https://formae.ai/formae-iac) is Infrastructure As Code that matches reality. It continuously discovers what is actually running, captures changes made outside the code, and treats live infrastructure as the source of truth instead of a state file. Code is derived from that state, for one resource or a whole account, whenever you want it. It is open source and self-hosted. You run the agent, you own everything it touches, and there is no limit on how much infrastructure you put under it. ## Infrastructure drift is designed out, not detected Infrastructure is created and changed through several tools at once: pipelines, consoles, scripts, other Infrastructure As Code, and whatever was necessary during the last incident. With independent paths changing the same resources, any declared configuration falls behind. Drift becomes the default. State-based tools notice this only at a point in time, during a plan or an apply. Between runs, infrastructure diverges silently, and the first sign is a diff nobody expected. formae IaC captures every change as it happens, whoever made it and whichever tool made it, versions it, and absorbs it into its internal state. That state is always current. Drift does not accumulate, because there is nothing for it to accumulate against. ## Infrastructure As Code generated from what exists formae IaC does not try to keep hand-written files in step with a system that changes without asking them. It keeps a continuously updated model of the live estate and extracts Infrastructure As Code from it on demand: the whole estate, one environment, one service, one resource. The code that comes out describes what is running, not a planned future state and not last quarter's snapshot. ## No state file to keep in step Tools that depend on an external state file inherit an entire class of problems: stale state, failed imports, plans that cannot be trusted, and a repair step somebody has to own. formae IaC has no state file to keep honest. Its internal state is updated from the live estate regardless of how changes arrive, and Infrastructure As Code is a projection of that state rather than the thing being projected onto. ## GitOps stays, and granular apply arrives Many teams keep their Infrastructure As Code in their own Git repository, and that repository is where review and approval happen. That workflow stays as it is. What it gains is code that describes the estate as it is right now, extracted from live state and reviewed like any other change. What a change can be: - a patch, for one incremental change - a selective apply, to specific resources or components - a refresh of the code in the repository, taken from live state Classic GitOps and fine-grained apply are not alternatives here. Neither one assumes every change must flow through a single path. ## Built for day 2 Most Infrastructure As Code is shaped around the first apply. Real systems spend a day being provisioned and a decade being operated. formae IaC treats day 2 as the default. Change one property or a whole environment. Patch during an incident, then update the code from what the patch actually did rather than from memory. Put a lifetime on an environment so it removes itself when it is no longer needed. Put auto-reconcile on a stack and anything changed by hand goes back on its own, and goes back again the next time, because it is a policy on the stack and not something somebody has to remember to run. The internal state follows all of it, whichever tool the change came through. ## Extensible to anything with an API Infrastructure is more than what a provider catalogue covers. It is internal platforms, custom services, appliances and hardware, most of it reachable through some kind of API and none of it on anybody's provider list. formae IaC is built to be extended quickly, including systems that expose RESTful APIs, control interfaces or management endpoints. Once added, they live in the same internal state and take part in the same workflows as everything else, so Infrastructure As Code stops ending where the provider list ends. Extending it means writing a plugin, and [Build on formae](https://formae.ai/build-on-formae) is how that is done. ## Adopt it without a migration Adopting Infrastructure As Code on infrastructure that already exists is traditionally a project of its own: import the resources, migrate the state, refactor what is there, and freeze changes while it happens. formae IaC asks for none of it. Enable it on an existing environment and it discovers what is running, then hands you Infrastructure As Code straight out of the current state. You can put part of the estate under formae and nothing else, for as long as that is what helps. Your existing Terraform keeps its value literally: formae IaC reads your `.tfvars` files directly. The values in them are the part with years of production thinking in them, and they carry over as they are. What does not carry over is the mechanics underneath, and providers, modules and a state file were never the thing worth protecting. No forced migration. No mandatory refactoring. No freeze on changes. ## A practical Terraform alternative Teams looking at Terraform alternatives usually want the same four things: infrastructure drift handled rather than reported, day 2 workflows that are safe at small granularity, less dependence on a fragile state file, and Infrastructure As Code that works with infrastructure that already exists. formae IaC answers all four the same way, by treating live infrastructure as the source of truth and deriving the code from an always current internal state. Moving off Terraform happens incrementally, with your `.tfvars` read as they are, without a change freeze and without rewriting what already works. Capability by capability, that comparison is [formae vs Terraform](https://formae.ai/formae-vs-terraform), and the same argument against Pulumi is [formae vs Pulumi](https://formae.ai/formae-vs-pulumi). ## Where to start Put one environment under it and see what it finds. The [quick start](https://docs.formae.ai/) is all of day one. It stays free, with unlimited resources, however far you take it, and [pricing](https://formae.ai/pricing) says what that covers. If running it yourself was never the appeal, [formae Cloud](https://formae.ai/formae-cloud) is the hosted offering: nothing to install, nothing to keep up to date, and we operate it. On this page - Infrastructure drift is designed out, not detected - Infrastructure As Code generated from what exists - No state file to keep in step - GitOps stays, and granular apply arrives - Built for day 2 - Extensible to anything with an API - Adopt it without a migration - A practical Terraform alternative - Where to start ## Frequently asked questions [Quick start](https://docs.formae.ai/) - **Do I need to migrate from Terraform to use formae IaC?** No. formae IaC does not require migrating Terraform state or refactoring existing infrastructure, and it reads your existing `.tfvars` directly, so the configuration values carry over as they are. Adoption is incremental, and it can cover part of an estate for as long as that is useful. - **Is formae IaC compatible with GitOps workflows?** Yes. Your repository stays where review and approval happen, and what it holds is code refreshed from live infrastructure rather than code that slowly stops describing it. Changes can also be applied directly, at any granularity from one resource to a whole stack. - **How does formae IaC handle out of band changes?** Every change is captured as it happens, whichever tool or hand made it, automatically versioned, and absorbed into the internal state. There is no separate drift detection run. Put auto-reconcile on a stack and hand-made changes go back on their own. - **Can I generate Infrastructure As Code from existing infrastructure?** Yes. formae IaC discovers what is running and extracts current Infrastructure As Code from it, for a single resource or a whole account. - **What does formae IaC cost?** It is open source and self-hosted, with unlimited resources, and there is no per resource or per seat charge, so doubling the estate changes nothing about what you pay. [Pricing](https://formae.ai/pricing) covers the hosted option, for anyone who would rather not run it themselves. --- ## formae vs. Terraform Source: https://formae.ai/formae-vs-terraform --- title: "formae vs. Terraform | Platform Engineering Labs" description: "formae is a Terraform alternative built for day 2 and beyond. Terraform works well for day 1 provisioning; formae continuously discovers what is actually…" url: "https://formae.ai/formae-vs-terraform" --- # formae vs. Terraform formae is a Terraform alternative built for day 2 and beyond. Terraform works well for day 1 provisioning; formae continuously discovers what is actually running, keeps your code as the source of truth instead of a state file, and applies changes at any granularity with minimal blast radius. It can fully replace Terraform, or run alongside it. Terraform is one of the most widely used infrastructure as code tools. It works well for day 1 provisioning, where infrastructure is created from scratch and changes are planned through a declared codebase. Since Terraform’s arrival, however, the way infrastructure is built and operated has changed. Modern environments evolve continuously on day 2 and beyond, with changes coming from multiple tools, automation, APIs and clickops. Keeping declared configuration aligned with reality has become increasingly difficult over time. ## Terraform state vs. formae state Terraform maintains a state that is intended to represent infrastructure, but both the state and the Terraform code can diverge from reality as infrastructure changes over time. Changes made through other tools, automation, APIs and clickops are not reflected unless they are manually reconciled, and the code and the state can become disconnected from what actually exists. formae uses a different state model. It continuously discovers live infrastructure and versions it into an internal state that always reflects reality, regardless of how changes were made. State does not drift because it is updated through continuous observation rather than manual synchronization. ## Terraform workflows vs. formae workflows Terraform workflows apply infrastructure changes holistically and fit well with GitOps-style workflows, where updates are rolled out by applying the configuration. formae supports the same GitOps workflows, but does not require every change to be applied all at once. Teams can apply targeted changes with minimal blast radius while still working through code, which lets formae adapt to different workflows and use cases without forcing every change through a single, holistic rollout. ## Terraform drift handling vs. formae drift handling Terraform treats infrastructure drift as an undesired anomaly and requires manual reconciliation when it happens. formae treats drift as a normal outcome of infrastructure changes and continuously absorbs it into its internal state. ## Terraform extensibility vs. formae extensibility Terraform is extended through providers, which are powerful but often complex to build and maintain. Adding support for new systems typically requires deep knowledge of Terraform internals and significant ongoing effort. formae is designed to be extended directly by infrastructure builders. New systems can be added through plugins with a schema-safe interface, without relying on fragile wrappers or vendor roadmaps. This makes extensibility practical for individual engineers and AI agents. The capability-by-capability comparison is below, covering detailed differences and edge cases beyond the high-level points above. ## Terraform cloud options vs. formae cloud options Hosted Terraform runs the plans, and what it runs is a configuration you write and keep in a repository. Hosting the runs does not change that: the code is still yours to author and to keep current. formae Cloud requires no code from you. There is nothing to write and no repository to keep in step, because formae describes what is already running and changes it in place. It is operated by us and reaches your account through a role you grant and can revoke. ## Terraform AI integration vs. formae AI integration The Terraform MCP server can drive runs and not only read them, once those operations are turned on. What the agent drives is the machinery that was already there: a workspace, a run and an approval. With formae the agent calls the product's own operations. It discovers what is running, changes one property or a whole environment, applies it, and the change is versioned as it happens. On this page - Terraform state vs. formae state - Terraform workflows vs. formae workflows - Terraform drift handling vs. formae drift handling - Terraform extensibility vs. formae extensibility - Terraform cloud options vs. formae cloud options - Terraform AI integration vs. formae AI integration - Capability comparison - Frequently asked questions ## Capability comparison Capability Terraform formae **Infrastructure code is the source of truth** Terraform no - after initial rollout, state file is the source of truth - state requires manual refresh through the user - additional tools and offerings are needed to automate to some extent formae yes - user works exclusively through code in and out - always up-to-date Why this matters There is a reason why it is called *Infrastructure as code*. You should be able to see your current infrastructure as code at any time, always up-to-date, without having to manually update it. **Day 1 operation** Terraform yes built for holistic code management and rollouts formae yes built for Day 1 and Day 2+ operations Why this matters On Day 1, everything is simple, but a properly structured approach with IaC is needed - ClickOps doesn't work on Day 1 at scale, for example. Repeatability of initial rollout into different environments always plays an important role. **Day 2+ operation** Terraform no - built for holistic code management and rollouts - additional tools and offerings are needed to relax and support more Day 2+ workflows and use cases formae yes built for Day 1 and Day 2+ operations Why this matters Starting on Day 2, the reality is complicated, and the so-called "drift" is inevitable. Small changes are common, and also different tools will almost certainly be in use to manage infrastructure. Even ClickOps is a legitimate tool in some cases - there is no reason to avoid powerful tools such as Cloud Web Consoles just to satisfy a rigid process that is implemented for Day 1 operations. Cloud providers make updates without updating or even knowing about your infrastructure code. All sorts of autoscaling rules and technologies constantly change the topology. Security tools and teams make urgent and planned changes often bypassing infrastructure code as well. Different teams follow different processes and implement different workflows for maximum speed. It is necessary to stay in control of drift and automate your response to it, not only be able to detect it. **Support for every engineer's use cases** Terraform no - designed to serve exclusively the highly skilled 1% of engineers - struggles with highly collaborative use cases of platform teams - doesn't suit developers because of lack of abstraction of low-level infrastructure detail formae yes supports all use cases and workflows of operations and platform teams Why this matters Empowering every engineer to work with the tool enables faster change at lower cost. Infrastructure experts can focus on low-level detail such as networks, while less experienced engineers can still make targeted/small changes without going too deep. Developers - who barely operate systems - can consume or request infrastructure without knowing any low-level detail. All these roles have their own nuances, too, depending on the team setup, skills and situations. For example, being an expert and having to fix an urgent problem at 2a.m. is a different use case than preparing a new team environment, and requires different focus, blast radius control and sometimes even tools. **Simple configuration language** Terraform no - HCL is complex - its support for conditionals and loops is very uncomfortable - JSON can be alternatively used, but it doesn't provide any elements of programming without extra tools formae yes - uses Pkl, which is a simple configuration language with minimalistic, but comfortable elements of programming - open to further schemas Why this matters The language of the infrastructure code needs to be simple. Of course, "simple" is highly subjective. But for example, Ops teams usually don’t do full-blown software development, which most ecosystems such as TypeScript, Java or Python require. Scripting is as far as people go in Ops. So far, YAML is the widely used common denominator that every engineer accepts, but it requires extra tools for templating, conditionals, functions and other means borrowed from programming. And these are needed for flexibility and DRY (don't repeat yourself). **Schema safety** Terraform yes, but - schema is implemented per provider - lots of semantics are hiding inside the providers formae yes strong, uniform schema Why this matters Schema safety is essential to avoid human error. Understanding the schema without having to navigate through each provider's source code makes configuration of resources simple and allows team-specific derivatives. On the other hand, using such low-level languages such as YAML currently comes at the cost of not having any schema safety at all, with a high risk of human error - sometimes catastrophic. **Schema-based resource and dependency declaration** Terraform yes, but - resource definition through the provider schema - dependencies are static and cannot be changed at runtime formae yes - simple resource declaration through classes and inheritance - hints on resource types that are used to automatically identify and resolve dependencies - provides a so-called *res*, which is a simple yet powerful referencing construct Why this matters When all data-specific, mechanical aspects, as well as dependencies of the resource are defined through schema, target infrastructure is easy to maintain and adjust, and it allows you to keep the infrastructure code clear and the providers / plugins lean and simple to maintain. Too often, relationship and dependency logic is hiding inside already complicated provider code, which unnecessarily complicates the resource lifecycle management and the usage of the tool. **Low provider complexity** Terraform no - providers are highly complex because of the necessity to implement all state transitions and update loops inside the provider - providers massively deviate in quality and reliability formae yes - plugins are simple and uniform - every technology plugin implements CRUD+ - workflow, state transitions, retries etc. are implemented through the agent, so the plugin just works with data without managing state Why this matters Low provider (or plugin) complexity means easy update cycle, reliability and ability for anyone in the community to quickly implement their own plugins and provide bugfixes to existing ones. In the classic IaC, providers are often full-blown programs with workflow and lifecycle logic which can usually only be adjusted by its creators. There are also big differences in provider quality that are difficult to deal with. Lightweight plugins also relax that issue. **Active agent** Terraform no - pure client-side IaC runtime - backend is just a storage definition - inability to pick up unfinished work without complicated, manual intervention through the user - low automation potential - additional tools and offerings are needed to partly address the missing bits formae yes - active agent - takes care of state management and automation - picks up unfinished work after failures Why this matters Engineers shouldn’t need extra tools to compensate for the inability of their IaC tool to support automation. Classic IaC tools attempt to work exclusively on the local machine, following the minimalistic philosophy of the original UNIX tools. This hinders the ability to work in teams or multiple teams, and puts the user in the middle of the process as yet another tool. True automation is only possible by handing off work to an active agent, removing toil for users. **Asynchronous change execution** Terraform no - every plugin is responsible for its own state transitions and workflows - asynchronous implementation is entirely up to the provider developer formae yes - executes every stack and resource change asynchronously - the agent makes sure every resource change is going through a set of finite state machines that eventually finish Why this matters Applying infrastructure changes asynchronously makes them reliable and repeatable. Some infrastructure modifications in some technologies can take a long period of time and follow a complicated workflow. This doesn't mean that a full-blown workflow engine is the solution though - it only means that infrastructure changes need to run asynchronously, without the initiating user process having to wait for the result. And that unfinished work can be picked up after crashes without the risk of state corruption. **Automatic state management** Terraform no - manual refresh of state through the user at unpredictable points of time - state is handled as storage, not as an intelligent component - additional tools and offerings are needed to relax the insufficiencies to some extent formae yes - automatically manages state - stored in an RDBMS for strong durability and consistency Why this matters State management is a highly manual process in the classic IaC, and constantly requires human attention and intervention. Even if some tools manage the state data in cloud offerings, the point in time when the state is updated is still up to the engineer, making them part of the tool. Engineers should not have to tell their IaC tool when to persist or update its state. Having to manually maintain state introduces an additional layer of complexity and possible human and technical error. **Minimal locking** Terraform no - locks the state globally - additional tools and offerings are necessary to relax the problem to some extent formae yes locks per resource Why this matters Global locking is how classic IaC tools make sure their state doesn't get corrupted by parallel mutations, but only a single resource can be locked in the majority of cases. Global locking is causing slowdowns and waterfall-like team workflows, while minimal locking makes sure teams and engineers can move independently and fast. **Arbitrary change granularity** Terraform yes, but - can target single resources, but still will circle through the whole state - additional tools and offerings are needed to break down code changes into smaller chunks - these tools and offerings don't make it any more simple to debug and solve problems formae yes single property, single resource, full stack and even whole cloud estate granularity of changes Why this matters Being able to apply changes in any granularity allows you to massively reduce risks, limit the blast radius of those changes and maintain focus, resulting in much less human error. Holistic Day-1-style rollouts on Day 2 create cognitive overload and more toil in cases where small changes are made, for example urgent fixes. Changing a single property of a single resource shouldn't feel like touching the whole infrastructure code. **Patching** Terraform no - doesn't provide patching - even when creating a new project, the user is forced to provide existing values to the resources, otherwise these will be lost - additional tools and offerings relax the problem to some extent - these tools and offerings don't make it any more simple to debug and solve problems formae yes - allows you to patch even single properties on single resources - no need to see or provide irrelevant fields or resources at patch time Why this matters Being able to incrementally apply changes to single resources without dealing with irrelevant details is crucial for safety and speed. Blast radius control is a big and central topic in IaC. The less detail is needed to make an infrastructure change, the more confident you can be. Also, incremental changes are very common in many environments starting on Day 2. There are many situations where a patch is the simplest, quickest solution, and the IaC tool needs to support these. **Automatic drift detection** Terraform no - doesn't automatically detect drift - manual steps are needed to detect drift - additional tools and offerings are needed to relax the problem to some extent formae yes - detects every change and automatically absorbs it - turns every change into versioned code Why this matters The term "drift" has been massively bloated in the classic IaC world. Since classic IaC tools are not able to automatically catch up on changes happening outside or their own idea of state, these changes have been declared as something very bad. Some tools even go so far that they automatically reconcile from their own state, undoing changes that happened outside of the tool. The reality in any reasonably complex environment is much more nuanced though. Multiple tools will be used, and changes of all kinds happen through all kinds of actors. Enforcing a single process and a single tool is often impossible, and also not reasonable. Drift as such should not be a concern - state and real infrastructure need to be always in perfect sync, with changes coming from both ends. **Automatic drift correction** Terraform no - doesn't automatically correct drift - partly complex, manual steps are needed to correct drift in any direction formae yes automatically corrects drift both ways - *to* infrastructure and *from* infrastructure Why this matters Once drift has been automatically detected, it is crucial to also automatically correct it. It doesn't mean to restore infrastructure from the state one way - this would be only one of the possible strategies, and it shouldn't be applied uniformly. A more reality-friendly strategy is to accept changes coming from both ends. After all, when a change already happened in the target infrastructure, the state needs to be first updated, so there is no drift. After that, the user is free to decide if they want to undo the change. Or the change can be undone automatically according to some policy, but even after it has been registered and versioned. **Automatic resource discovery** Terraform no - doesn't automatically discover new resources - complex, manual steps are needed to identify and import yet unknown resources formae yes - automatically discovers new resources - automatically tracks and versions changes even on unmanaged resources Why this matters Automatic discovery of new resources makes use cases possible that are unthinkable or difficult to implement with the classic IaC tools. For example, you are able to analyse existing infrastructure immediately, even when there is no infrastructure code available. Also, patches on existing resources can be made quickly when these are discovered and turned into code - completely without the need to look at the rest of the infrastructure. On the other hand, classic IaC tools would send you through a manual process of importing existing resources that is prone to error. Automatic resource discovery also allows you to have a full inventory of existing resources for further processing entirely without manual work. **Automatic change synchronization** Terraform no - doesn't automatically synchronize changes that happened outside of the tool - manual refresh is necessary to synchronize state with the infrastructure formae yes captures and versions every change that happens outside of the tool Why this matters Changes happen all the time outside of the IaC tool in a reasonably complex environment. It is a good idea to capture them automatically, not manually. Classic IaC tools require the user to update their state explicitly and manually, which inevitably leads to drift. On the other hand, state that is automatically up-to-date with the infrastructure makes changes predictable and reliable, and allows you to make explicit decisions to keep or to undo changes that happened outside of the tool. **Automatic change versioning** Terraform no - doesn't version changes - additional tools and offerings provide versioning to some extent formae yes automatically versions all changes, no matter where they came from - be it from other tools, or even through ClickOps Why this matters When every change is automatically versioned, no matter where it came from, infrastructure is fully auditable. Also, versioning of changes allows you to review and to restore previous states at any time. Git is usually used for this in GitOps, but it comes at the price of code in Git being decoupled from state and from infrastructure. If the IaC tool takes care of change versioning, it is also one tool less to deal with in situations where change history needs to be analysed or used. **Automatic change codification** Terraform no - doesn't automatically codify changes - complex steps are needed to derive code from state formae yes - every change is automatically codified - the user extracts resources or stacks exclusively as code Why this matters Users should communicate with the IaC tool exclusively through code. This requires every change to be codified automatically, no matter where it came from, so that the user can retrieve any current or past resource state as code. Classic IaC tools on the other hands Classic IaC tools, on the other hand, make users absorb their highly technical, low-level state format such as JSON and go through a complicated, manual procedure to turn it into actual infrastructure code. **Automatic policy enforcement** Terraform no - lacks active backend to provide natively - requires extra tools and offerings formae yes - offers TTL, auto-reconcile out of the box - easy to extend with further policies Why this matters Automatic policy enforcement brings piece of mind and guardrails that prevent overspend, drift and toil. **Easily extensible** Terraform no - requires deep provider framework expertise - schema, state, and lifecycle logic must be implemented by hand - strong understanding of HCL and Terraform SDK needed formae yes - simple, uniform Plugin SDK with minimal boilerplate - extensibility accessible to many engineers - easily combined with AI code assistance Why this matters Extensibility should not be gated behind specialist expertise. When adding integrations is hard, it becomes a bottleneck: teams wait on scarce provider engineers and somebody else's roadmaps, product teams can’t self-serve, and platform evolution slows. Making extensions easy and safe unlocks broader contribution, faster iteration, and reduces dependency on scarce experts. **Fast and safe plugin development** Terraform no - cycles are slow due to complex lifecycle code - subtle bugs (state/diff) require expert debugging - adding resources safely often feels like a long, risky project formae yes - many plugins can be built in under an hour with AI help - safety enforced by uniform schema and lifecycle conventions - agent does all the heavy lifting, making plugins simple - no manual state machine or diff implementation required Why this matters Speed only matters if you can trust the result. Integrations that take weeks to build or are risky to validate get deferred, copied manually, or shipped with latent correctness issues. Rapid, safe plugin development means teams can add and evolve integrations continuously - without increasing operational risk or creating long-term maintenance debt. **Hosted with no code to author or repository to maintain** Terraform no the configuration those runs consume is yours to write and to keep current formae yes no code from you: nothing to write, and no repository to keep in step Why this matters A repository of infrastructure code is a second system to keep alive. Somebody writes it, somebody reviews it, and somebody keeps it in step with infrastructure that changes without asking it, which is work that never ends and never ships anything. Hosting the runs or the state elsewhere moves none of it. Not needing the repository at all is what removes it. **AI integration through the product's own operations** Terraform yes, but - the operations are off until somebody turns them on - once on, the agent drives a workspace run, and the change goes through plan and approval formae yes the agent calls the product's operations: discover, apply, patch, set a lifetime or auto-reconcile Why this matters An agent is only as useful as the surface it is handed. Given a codebase and a run pipeline, its work arrives as a code change that somebody still has to read, approve and release. Given the operations themselves, asking for a change and the change happening are one step, and the record of it is a version rather than a commit. ## Frequently asked questions [Pricing](https://formae.ai/pricing) - **Is formae a Terraform alternative?** Yes. formae can be used anywhere Terraform is used and can fully replace Terraform for managing infrastructure as code. It can also run alongside Terraform when teams choose to adopt it incrementally. - **Do I need to migrate my Terraform code or state to use formae?** No. formae does not require importing Terraform state or rewriting existing code. It can discover existing infrastructure directly. - **Can formae work with Terraform-managed infrastructure?** Yes. formae can discover and track infrastructure that is managed by Terraform, without relying on Terraform configuration or state files. - **Does formae support GitOps workflows?** Yes. formae supports GitOps-style workflows where changes are applied through code. It also supports more granular workflows when full rollouts are not desired. - **How does formae handle out-of-band changes and drift?** formae continuously discovers all infrastructure changes, including out-of-band changes, and absorbs them into its internal state. Drift does not accumulate. - **Can formae be adopted incrementally?** Yes. formae can be enabled in read-only mode and introduced gradually, without disrupting existing workflows. --- ## What is formae: live infrastructure as the source of truth Source: https://formae.ai/what-is-formae --- title: "What is formae: live infrastructure as the source of truth | Platform Engineering Labs" description: "Infrastructure has more than one author, so formae treats what is actually running as the source of truth and derives everything else from it. Work through code, or just describe what you need. Self-hosted and free, or fully managed." url: "https://formae.ai/what-is-formae" --- # What is formae formae is automatic and continuous infrastructure management. It discovers what is actually running without being asked, keeps that picture current as things change, and versions every change whoever made it. How you work with that model is a separate question, and there is more than one answer. Continuous is the load-bearing word. Nothing here is a run you have to trigger: discovery and versioning happen as the estate changes, and putting a hand-made change back is a policy on a stack rather than a command somebody has to remember. Some teams want to work through code, reviewed and merged like everything else they own. Others would rather describe what they need and have it done, by an agent driving formae directly, with nothing to install and no repository to keep. formae does both, and the choice is not permanent. Why it works that way starts from an observation rather than a technique: infrastructure has more than one author. It is created and changed by pipelines, by consoles, by scripts, by other tools, and by whoever was awake when something broke. Every tool built on a state file assumes a single author, and spends the rest of its life being surprised. formae assumes the opposite. What is actually running is the source of truth, and everything else is derived from it: the code, the answer to a question, the change an agent makes on your behalf. Nothing can disagree with the estate, because nothing else is the record. ## Infrastructure has more than one author A state file records what one tool believed at the moment it last ran. Everything that happened since, by any other hand, is invisible to it until somebody runs a plan and reads a diff they did not expect. formae watches the estate instead. It discovers what is running, captures every change whoever made it, and versions it as it happens. Drift stops being a condition to be detected on a schedule and becomes what it always was: a change, with an author and a time, that either belongs or does not. ## Code is one way in, not the record Nobody maintains a database schema by hand-editing a dump of it. The schema is what the database is; the file is something you ask for when you need one. Infrastructure As Code has been written the other way round, and the cost is a permanent maintenance tax: a repository somebody has to keep in step with a system that changes without asking. formae keeps a current model of the estate and can hand you code out of it, for one resource or a whole account, whenever you want it. Or never, if code is not how you want to work. Either way the model is the same one, and the code describes what is running rather than what somebody intended last quarter. If you do write code, what you write is applied precisely. What nobody has to do any more is keep a manuscript honest. [Why formae IaC](https://formae.ai/why-formae-iac) makes that case in full. ## Agents are the other way in An agent managing infrastructure is only as good as what it has been pointed at. A repository describes the past. A console will let it do almost anything and remember almost none of it. formae gives an agent what it gives a person: the live model. Any MCP-capable assistant can drive it directly, through interfaces that are explicit and schema-driven rather than a screen to scrape or a command to guess at, so a change is valid or refused before anything moves. Whatever the agent does is captured and versioned like any other author's work, which is the point of assuming more than one author in the first place. That is what AI-native means here, and it is not a chat window laid over the top. The same operations, the same boundaries and the same blast radius, whether the hand on them is yours or your agent's. ## Day 2 is where infrastructure lives Provisioning is a day. Operating is a decade, and it is the part that is mostly missing from tools designed around the first apply. formae treats day 2 as the default. Change one property or a whole environment. Patch during an incident, then update the code from what the patch actually did. Put a lifetime on an environment so it removes itself on Friday. Put auto-reconcile on a stack and anything changed by hand goes back on its own, as a policy rather than as something somebody has to remember to run. None of these are exceptional operations; they are the ordinary week. ## Adoption should cost nothing Adopting a new way to run infrastructure that already exists is traditionally a project: import resources, migrate state, refactor, and freeze changes while you do it. formae asks for none of that. Point it at an account and it discovers what is there. Your existing Terraform and Helm keep their value, your team's knowledge keeps its value, and what is running gets described in minutes. You can use formae for part of the estate and nothing else, for as long as that is what helps. No migration. No mandate. No freeze. ## Two ways to work with it The real choice is how you want to work. Where it runs follows from that. [formae Cloud](https://formae.ai/formae-cloud) is the conversational one. You describe what you need and your coding agent does it, against the same live model: nothing to install, no repository to keep, and no code to write unless you ask for some. It reaches your own cloud account through a role you grant. It suits teams who are moving fast and changing shape, and who would rather not own the machinery at all. [formae IaC](https://formae.ai/formae-iac) is the one you run yourself. Open source and self-hosted, you own everything it touches, and it is not priced per resource or per seat, so doubling the estate changes nothing about what you pay. It suits teams who already work through code, and want that to go on being true. [formae Enterprise](https://formae.ai/pricing) is the plan above both, for estates that need a custom installation, enterprise-grade policies and security, a non-public hub and support with hours attached. formae Cloud is not a cut-down formae IaC, and formae IaC is not a trial run for formae Cloud. They are two ways of working, not two rungs. The [pricing](https://formae.ai/pricing) page sets out where they differ. ## Whoever runs your infrastructure formae does not assume a single owner, a single workflow, or that the same person writes the code and carries the pager. It assumes the opposite, which is why the internal model is updated from the live estate rather than from anybody's branch. In practice there are three answers, which is how the front page asks it. I don't care who runs it: you want it to work, and you do not want to run it. We run it ourselves: you own the platform and intend to keep owning it. My org runs it: you own the budget, the standards and the risk, and not the keyboard. formae is built for all three, and what differs is which edition you point at the problem. On this page - Infrastructure has more than one author - Code is one way in, not the record - Agents are the other way in - Day 2 is where infrastructure lives - Adoption should cost nothing - Two ways to work with it - Whoever runs your infrastructure ## Frequently asked questions [Pricing](https://formae.ai/pricing) - **Can an AI agent run formae?** Yes, and that is the point rather than an add-on. formae exposes an MCP server, so any MCP-capable assistant or agent can drive it directly, through interfaces that are explicit and schema-driven. An agent gets the same live model, the same boundaries and the same precision a person gets, and everything it does is captured and versioned like any other author's work. - **Is formae an Infrastructure As Code tool?** It can be. It works the other way round from most of them: instead of keeping a file in step with a system, formae keeps a current model of the live system and hands you Infrastructure As Code out of it whenever you want it. It is also usable with no code at all, by describing what you need to your coding agent. - **Do I have to choose an edition before I start?** No. Run it yourself with formae IaC, or have it run for you with formae Cloud. Starting on one does not shut the other door: moving across later undoes nothing you have already done. - **Does formae replace Terraform?** It can, and it does not require you to. formae runs alongside what you already have, discovers the estate whoever built it, and never asks for a migration or a change freeze first. [formae vs. Terraform](https://formae.ai/formae-vs-terraform) and [formae vs. Pulumi](https://formae.ai/formae-vs-pulumi) go through the differences one by one. - **What does formae cost?** formae IaC is open source and self-hosted, with unlimited resources and no per resource or per seat charge. formae Cloud is billed monthly per installation and managed by us. formae Enterprise is priced for what you need. [Pricing](https://formae.ai/pricing) has the numbers and the terms. - **Who is formae for?** Whoever runs the infrastructure, which is rarely one person. These are the nine, grouped by the answer they would give: - **I don't care who runs it**: [startup CTO](https://formae.ai/#startup-cto), [software engineer](https://formae.ai/#software-engineer), [solution engineer](https://formae.ai/#solution-engineer) - **We run it ourselves**: [DevOps engineer](https://formae.ai/#devops-engineer), [SRE](https://formae.ai/#site-reliability-engineer), [platform engineer](https://formae.ai/#platform-engineer) - **My org runs it**: [CIO](https://formae.ai/#enterprise-cio), [enterprise architect](https://formae.ai/#enterprise-architect), [CISO](https://formae.ai/#ciso) Each one opens the card that says what that reader gets out of it. --- ## formae vs. Pulumi Source: https://formae.ai/formae-vs-pulumi --- title: "formae vs. Pulumi | Platform Engineering Labs" description: "formae is a Pulumi alternative built for day 2 and beyond. Pulumi defines infrastructure in application programming languages; formae defines it in Pkl, a…" url: "https://formae.ai/formae-vs-pulumi" --- # formae vs. Pulumi formae is a Pulumi alternative built for day 2 and beyond. Pulumi defines infrastructure in application programming languages; formae defines it in Pkl, a configuration language with schemas and constraints, then continuously discovers what is actually running and keeps that code as the source of truth rather than a state file. It can fully replace Pulumi, or run alongside it. Pulumi is an infrastructure as code tool primarily adopted by application development teams that prefer defining infrastructure using general-purpose programming languages. It is commonly used in code-first environments where infrastructure is managed through application programming languages. It works well for day 1 provisioning, where infrastructure is created from scratch and managed through a declared codebase. Since Pulumi’s arrival, however, the way infrastructure is built and operated has continued to evolve. Modern environments change continuously on day 2 and beyond, with updates coming from multiple tools, automation, APIs, and clickops. Keeping declared configuration aligned with reality becomes increasingly difficult over time. ## Pulumi state vs. formae state Pulumi maintains a state that represents infrastructure based on the declared program. As infrastructure changes over time, both the state and the Pulumi code can diverge from what actually exists. Changes made through other tools, automation, APIs, or clickops are not reflected unless they are manually reconciled, and the program, the state, and the live environment can become disconnected. formae uses a different state model. It continuously discovers live infrastructure and versions it into an internal state that always reflects reality, regardless of how changes were made. State does not drift because it is updated through continuous observation rather than manual synchronization. ## Pulumi workflows vs. formae workflows Pulumi workflows apply infrastructure changes holistically and fit well with GitOps-style workflows, where updates are rolled out by executing the declared program. formae supports the same GitOps workflows, but does not require every change to be applied all at once. Teams can apply targeted changes with minimal blast radius while still working through code, which lets formae adapt to different workflows and use cases without forcing every change through a single, holistic rollout. ## Pulumi drift handling vs. formae drift handling Pulumi treats infrastructure drift as an undesired anomaly and requires manual reconciliation when it happens. formae treats drift as a normal outcome of infrastructure changes and continuously absorbs it into its internal state. ## Pulumi extensibility vs. formae extensibility Pulumi is extended through providers and language SDKs, which are powerful but often complex to build and maintain. Adding support for new systems typically requires deep knowledge of Pulumi’s provider model and ongoing maintenance as APIs evolve. formae is designed to be extended directly by infrastructure builders. New systems can be added through plugins with a schema-safe interface, without relying on fragile wrappers or vendor roadmaps. This makes extensibility practical for individual engineers and AI agents. The capability-by-capability comparison is below, covering detailed differences and edge cases beyond the high-level points above. ## Pulumi cloud options vs. formae cloud options Pulumi Cloud is on by default and what it manages is the state. The program is yours to write and to run, kept in your repository, and it is the only way to change anything. formae Cloud requires no code from you. There is nothing to write and no repository to keep in step, because formae describes what is already running and changes it in place. It is operated by us and reaches your account through a role you grant and can revoke. ## Pulumi AI integration vs. formae AI integration Neo does more than suggest. It writes and refactors code, previews it and can deploy, with approvals set per task mode and a read-only mode if you want one. What it operates is your program and the state behind it: a change is an edit, and then a deployment of that edit. With formae the agent calls the product's own operations. There is no program to edit on the way to a change, and every change is versioned as it happens. On this page - Pulumi state vs. formae state - Pulumi workflows vs. formae workflows - Pulumi drift handling vs. formae drift handling - Pulumi extensibility vs. formae extensibility - Pulumi cloud options vs. formae cloud options - Pulumi AI integration vs. formae AI integration - Capability comparison - Frequently asked questions ## Capability comparison Capability Pulumi formae **Infrastructure code is the source of truth** Pulumi no - after initial rollout, state is the source of truth - state requires manual refresh through the user - additional tools and offerings are needed to automate to some extent formae yes - user works exclusively through code in and out - always up-to-date Why this matters There is a reason why it is called *Infrastructure as code*. You should be able to see your current infrastructure as code at any time, always up-to-date, without having to manually update it. **Day 1 operation** Pulumi yes built for holistic code management and rollouts formae yes built for Day 1 and Day 2+ operations Why this matters On Day 1, everything is simple, but a properly structured approach with IaC is needed - ClickOps doesn't work on Day 1 at scale, for example. Repeatability of initial rollout into different environments always plays an important role. **Day 2+ operation** Pulumi no - built for holistic code management and rollouts - additional tools and offerings are needed to relax and support more Day 2+ workflows and use cases formae yes built for Day 1 and Day 2+ operations Why this matters Starting on Day 2, the reality is complicated, and the so-called "drift" is inevitable. Small changes are common, and also different tools will almost certainly be in use to manage infrastructure. Even ClickOps is a legitimate tool in some cases - there is no reason to avoid powerful tools such as Cloud Web Consoles just to satisfy a rigid process that is implemented for Day 1 operations. Cloud providers make updates without updating or even knowing about your infrastructure code. All sorts of autoscaling rules and technologies constantly change the topology. Security tools and teams make urgent and planned changes often bypassing infrastructure code as well. Different teams follow different processes and implement different workflows for maximum speed. It is necessary to stay in control of drift and automate your response to it, not only be able to detect it. **Support for every engineer's use cases** Pulumi no - designed to serve exclusively programmers / developers - doesn't properly serve use cases and team settings that aren't entirely "shift-left" - misses the majority of infrastructure practitioners for whom full-blown software engineering is not an option formae yes supports all use cases and workflows of operations and platform teams Why this matters Empowering every engineer to work with the tool enables faster change at lower cost. Infrastructure experts can focus on low-level detail such as networks, while less experienced engineers can still make targeted/small changes without going too deep. Developers - who barely operate systems - can consume or request infrastructure without knowing any low-level detail. All these roles have their own nuances, too, depending on the team setup, skills and situations. For example, being an expert and having to fix an urgent problem at 2a.m. is a different use case than preparing a new team environment, and requires different focus, blast radius control and sometimes even tools. **Simple configuration language** Pulumi no - full blown programming languages and their ecosystems are too complex for infrastructure practitioners - YAML alternative is simple, but lacks loops and conditionals without extra tools formae yes - uses Pkl, which is a simple configuration language with minimalistic, but comfortable elements of programming - open to further schemas Why this matters The language of the infrastructure code needs to be simple. Of course, "simple" is highly subjective. But for example, Ops teams usually don’t do full-blown software development, which most ecosystems such as TypeScript, Java or Python require. Scripting is as far as people go in Ops. So far, YAML is the widely used common denominator that every engineer accepts, but it requires extra tools for templating, conditionals, functions and other means borrowed from programming. And these are needed for flexibility and DRY (don't repeat yourself). **Schema safety** Pulumi yes strong support through programming languages formae yes strong, uniform schema Why this matters Schema safety is essential to avoid human error. Understanding the schema without having to navigate through each provider's source code makes configuration of resources simple and allows team-specific derivatives. On the other hand, using such low-level languages such as YAML currently comes at the cost of not having any schema safety at all, with a high risk of human error - sometimes catastrophic. **Schema-based resource and dependency declaration** Pulumi yes strong support through programming languages formae yes - simple resource declaration through classes and inheritance - hints on resource types that are used to automatically identify and resolve dependencies - provides a so-called *res*, which is a simple yet powerful referencing construct Why this matters When all data-specific, mechanical aspects, as well as dependencies of the resource are defined through schema, target infrastructure is easy to maintain and adjust, and it allows you to keep the infrastructure code clear and the providers / plugins lean and simple to maintain. Too often, relationship and dependency logic is hiding inside already complicated provider code, which unnecessarily complicates the resource lifecycle management and the usage of the tool. **Low provider complexity** Pulumi yes, but - native providers are simple and written in Go - reuse of Terraform providers massively increases complexity formae yes - plugins are simple and uniform - every technology plugin implements CRUD+ - workflow, state transitions, retries etc. are implemented through the agent, so the plugin just works with data without managing state Why this matters Low provider (or plugin) complexity means easy update cycle, reliability and ability for anyone in the community to quickly implement their own plugins and provide bugfixes to existing ones. In the classic IaC, providers are often full-blown programs with workflow and lifecycle logic which can usually only be adjusted by its creators. There are also big differences in provider quality that are difficult to deal with. Lightweight plugins also relax that issue. **Active agent** Pulumi no - pure client-side IaC runtime - backend is just a storage definition - even the managed cloud backend is just an extended storage - inability to pick up unfinished work without complicated, manual intervention through the user - low automation potential - additional tools and offerings are needed to partly address the missing bits formae yes - active agent - takes care of state management and automation - picks up unfinished work after failures Why this matters Engineers shouldn’t need extra tools to compensate for the inability of their IaC tool to support automation. Classic IaC tools attempt to work exclusively on the local machine, following the minimalistic philosophy of the original UNIX tools. This hinders the ability to work in teams or multiple teams, and puts the user in the middle of the process as yet another tool. True automation is only possible by handing off work to an active agent, removing toil for users. **Asynchronous change execution** Pulumi yes, but - client-side execution - when changes don't finish, there is no easy way to pick up unfinished work formae yes - executes every stack and resource change asynchronously - the agent makes sure every resource change is going through a set of finite state machines that eventually finish Why this matters Applying infrastructure changes asynchronously makes them reliable and repeatable. Some infrastructure modifications in some technologies can take a long period of time and follow a complicated workflow. This doesn't mean that a full-blown workflow engine is the solution though - it only means that infrastructure changes need to run asynchronously, without the initiating user process having to wait for the result. And that unfinished work can be picked up after crashes without the risk of state corruption. **Automatic state management** Pulumi no - manual refresh of state through the user at unpredictable points of time - state is handled as storage, not as an intelligent component - additional tools and offerings are needed to relax the insufficiencies to some extent formae yes - automatically manages state - stored in an RDBMS for strong durability and consistency Why this matters State management is a highly manual process in the classic IaC, and constantly requires human attention and intervention. Even if some tools manage the state data in cloud offerings, the point in time when the state is updated is still up to the engineer, making them part of the tool. Engineers should not have to tell their IaC tool when to persist or update its state. Having to manually maintain state introduces an additional layer of complexity and possible human and technical error. **Minimal locking** Pulumi yes, but - locks the state per stack - additional tools and offerings are necessary to relax the problem to some extent formae yes locks per resource Why this matters Global locking is how classic IaC tools make sure their state doesn't get corrupted by parallel mutations, but only a single resource can be locked in the majority of cases. Global locking is causing slowdowns and waterfall-like team workflows, while minimal locking makes sure teams and engineers can move independently and fast. **Arbitrary change granularity** Pulumi yes, but - can target single resources, but still will circle through the whole state - additional tools and offerings are needed to break down code changes into smaller chunks - these tools and offerings don't make it any more simple to debug and solve problems formae yes single property, single resource, full stack and even whole cloud estate granularity of changes Why this matters Being able to apply changes in any granularity allows you to massively reduce risks, limit the blast radius of those changes and maintain focus, resulting in much less human error. Holistic Day-1-style rollouts on Day 2 create cognitive overload and more toil in cases where small changes are made, for example urgent fixes. Changing a single property of a single resource shouldn't feel like touching the whole infrastructure code. **Patching** Pulumi no - doesn't provide patching - even when creating a new project, the user is forced to provide existing values to the resources, otherwise these will be lost - additional tools and offerings relax the problem to some extent - these tools and offerings don't make it any more simple to debug and solve problems formae yes - allows you to patch even single properties on single resources - no need to see or provide irrelevant fields or resources at patch time Why this matters Being able to incrementally apply changes to single resources without dealing with irrelevant details is crucial for safety and speed. Blast radius control is a big and central topic in IaC. The less detail is needed to make an infrastructure change, the more confident you can be. Also, incremental changes are very common in many environments starting on Day 2. There are many situations where a patch is the simplest, quickest solution, and the IaC tool needs to support these. **Automatic drift detection** Pulumi no - doesn't automatically detect drift - manual steps are needed to detect drift - additional tools and offerings are needed to relax the problem to some extent formae yes - detects every change and automatically absorbs it - turns every change into versioned code Why this matters The term "drift" has been massively bloated in the classic IaC world. Since classic IaC tools are not able to automatically catch up on changes happening outside or their own idea of state, these changes have been declared as something very bad. Some tools even go so far that they automatically reconcile from their own state, undoing changes that happened outside of the tool. The reality in any reasonably complex environment is much more nuanced though. Multiple tools will be used, and changes of all kinds happen through all kinds of actors. Enforcing a single process and a single tool is often impossible, and also not reasonable. Drift as such should not be a concern - state and real infrastructure need to be always in perfect sync, with changes coming from both ends. **Automatic drift correction** Pulumi no - doesn't automatically correct drift - partly complex, manual steps are needed to correct drift in any direction formae yes automatically corrects drift both ways - *to* infrastructure and *from* infrastructure Why this matters Once drift has been automatically detected, it is crucial to also automatically correct it. It doesn't mean to restore infrastructure from the state one way - this would be only one of the possible strategies, and it shouldn't be applied uniformly. A more reality-friendly strategy is to accept changes coming from both ends. After all, when a change already happened in the target infrastructure, the state needs to be first updated, so there is no drift. After that, the user is free to decide if they want to undo the change. Or the change can be undone automatically according to some policy, but even after it has been registered and versioned. **Automatic resource discovery** Pulumi no - doesn't automatically discover new resources - complex, manual steps are needed to identify and import yet unknown resources formae yes - automatically discovers new resources - automatically tracks and versions changes even on unmanaged resources Why this matters Automatic discovery of new resources makes use cases possible that are unthinkable or difficult to implement with the classic IaC tools. For example, you are able to analyse existing infrastructure immediately, even when there is no infrastructure code available. Also, patches on existing resources can be made quickly when these are discovered and turned into code - completely without the need to look at the rest of the infrastructure. On the other hand, classic IaC tools would send you through a manual process of importing existing resources that is prone to error. Automatic resource discovery also allows you to have a full inventory of existing resources for further processing entirely without manual work. **Automatic change synchronization** Pulumi no - doesn't automatically synchronize changes that happened outside of the tool - manual refresh is necessary to synchronize state with the infrastructure formae yes captures and versions every change that happens outside of the tool Why this matters Changes happen all the time outside of the IaC tool in a reasonably complex environment. It is a good idea to capture them automatically, not manually. Classic IaC tools require the user to update their state explicitly and manually, which inevitably leads to drift. On the other hand, state that is automatically up-to-date with the infrastructure makes changes predictable and reliable, and allows you to make explicit decisions to keep or to undo changes that happened outside of the tool. **Automatic change versioning** Pulumi yes, but - sophisticated versioning - requires manual user step at unpredictable points in time formae yes automatically versions all changes, no matter where they came from - be it from other tools, or even through ClickOps Why this matters When every change is automatically versioned, no matter where it came from, infrastructure is fully auditable. Also, versioning of changes allows you to review and to restore previous states at any time. Git is usually used for this in GitOps, but it comes at the price of code in Git being decoupled from state and from infrastructure. If the IaC tool takes care of change versioning, it is also one tool less to deal with in situations where change history needs to be analysed or used. **Automatic change codification** Pulumi no - doesn't automatically codify changes - complex steps are needed to derive code from state formae yes - every change is automatically codified - the user extracts resources or stacks exclusively as code Why this matters Users should communicate with the IaC tool exclusively through code. This requires every change to be codified automatically, no matter where it came from, so that the user can retrieve any current or past resource state as code. Classic IaC tools on the other hands Classic IaC tools, on the other hand, make users absorb their highly technical, low-level state format such as JSON and go through a complicated, manual procedure to turn it into actual infrastructure code. **Automatic policy enforcement** Pulumi yes, but - lacks active backend to provide natively - offers only a few automatic ones, such as TTL - requires extra tools and offerings formae yes - offers TTL, auto-reconcile out of the box - easy to extend with further policies Why this matters Automatic policy enforcement brings piece of mind and guardrails that prevent overspend, drift and toil. **Easily extensible** Pulumi no - native provider development requires deep multi-language SDK knowledge - bridging Terraform providers adds translation complexity - understanding of provider/engine semantics often needed formae yes - simple, uniform Plugin SDK with minimal boilerplate - extensibility accessible to many engineers - easily combined with AI code assistance Why this matters Extensibility should not be gated behind specialist expertise. When adding integrations is hard, it becomes a bottleneck: teams wait on scarce provider engineers and somebody else's roadmaps, product teams can’t self-serve, and platform evolution slows. Making extensions easy and safe unlocks broader contribution, faster iteration, and reduces dependency on scarce experts. **Fast and safe plugin development** Pulumi no - correctness depends on provider internals and cross-language behavior - debugging native providers or bridged mappings is time-intensive - safe, production-grade extensibility is not quick formae yes - many plugins can be built in under an hour with AI help - safety enforced by uniform schema and lifecycle conventions - agent does all the heavy lifting, making plugins simple - no manual state machine or diff implementation required Why this matters Speed only matters if you can trust the result. Integrations that take weeks to build or are risky to validate get deferred, copied manually, or shipped with latent correctness issues. Rapid, safe plugin development means teams can add and evolve integrations continuously - without increasing operational risk or creating long-term maintenance debt. **Hosted with no code to author or repository to maintain** Pulumi no the program is yours to write and to run, and code you have written is the only way in formae yes no code from you: nothing to write, and no repository to keep in step Why this matters A repository of infrastructure code is a second system to keep alive. Somebody writes it, somebody reviews it, and somebody keeps it in step with infrastructure that changes without asking it, which is work that never ends and never ships anything. Hosting the runs or the state elsewhere moves none of it. Not needing the repository at all is what removes it. **AI integration through the product's own operations** Pulumi yes, but - Neo writes code, previews it and can deploy, with approvals set per task mode - what it operates is your program and the state behind it formae yes the agent calls the product's operations: discover, apply, patch, set a lifetime or auto-reconcile Why this matters An agent is only as useful as the surface it is handed. Given a codebase and a run pipeline, its work arrives as a code change that somebody still has to read, approve and release. Given the operations themselves, asking for a change and the change happening are one step, and the record of it is a version rather than a commit. ## Frequently asked questions [Pricing](https://formae.ai/pricing) - **Is formae a Pulumi alternative?** Yes. formae can be used anywhere Pulumi is used and can fully replace Pulumi for managing infrastructure as code. It can also run alongside Pulumi when teams choose to adopt it incrementally. - **Do I need to migrate my Pulumi code or state to use formae?** No. formae does not require importing Pulumi state or rewriting existing code. It can discover existing infrastructure directly. - **Can formae work with Pulumi-managed infrastructure?** Yes. formae can discover and track infrastructure that is managed by Pulumi, without relying on Pulumi programs or state files. - **Does formae support GitOps workflows?** Yes. formae supports GitOps-style workflows where changes are applied through code. It also supports more granular workflows when full rollouts are not desired. - **How does formae handle out-of-band changes and drift?** formae continuously discovers all infrastructure changes, including out-of-band changes, and absorbs them into its internal state. Drift does not accumulate. - **Can formae be adopted incrementally?** Yes. formae can be enabled in read-only mode and introduced gradually, without disrupting existing workflows. --- ## formae pricing: free and self-hosted, fully managed per installation, or custom Source: https://formae.ai/pricing --- title: "formae pricing: free and self-hosted, fully managed per installation, or custom | Platform Engineering Labs" description: "Unlimited resources in all plans. formae IaC is open source, self-hosted and free, formae Cloud is billed monthly per installation and managed by us, and formae Enterprise is priced for what you need." url: "https://formae.ai/pricing" --- # Pricing Unlimited resources in all plans ### formae IaC $0 / month Self-hosted [Get started with formae IaC](https://docs.formae.ai/) ### formae Cloud $25 / month per installation Limited time offer yours as long as you keep it Managed by us Starts with a 7 day free trial [Get started with formae Cloud](https://docs.formae.ai/documentation/get-started/quickstart-cloud) ### formae Enterprise Let's talk Custom installation [Get in touch](https://platform.engineering/contact) Compare plans ## What is in each plan | | formae IaC | formae Cloud | formae Enterprise | | --- | --- | --- | --- | | Unlimited resources | ✓ | ✓ | ✓ | | Installation | Self-hosted | Managed by us | Custom | | Policies | TTL and auto-reconcile | TTL and auto-reconcile | Enterprise-grade | | Security | Basic | OIDC | Enterprise-grade | | Support | Community | Same day | 24/7, LTS | | Plugin installation | ✓ | ✕ | ✓ | | OSS plugins | All | Major clouds and k8s | All | | Non-OSS plugins | ✕ | ✕ | ✓ | | Non-public hub | ✕ | ✕ | ✓ | ## Frequently asked questions [Get in touch](https://platform.engineering/contact) - **Is formae free?** formae IaC is: open source, self-hosted, free, with unlimited resources and every Infrastructure As Code feature. formae Cloud is billed monthly per installation because we manage it for you. formae Enterprise is priced for what you need. The cards above have the terms. - **Is there a free trial?** Yes, for formae Cloud: 7 days. At the end of them the trial becomes a paid subscription unless you cancel, and the subscription is monthly and cancellable at any time. - **What counts as an installation?** One formae agent instance, which we run and manage for you, with unlimited resources in it. formae is not priced per resource or per seat. - **What do I actually pay for?** Us managing it, and what a large estate needs: managed or custom installation, enterprise-grade policies and security, a non-public hub, non-OSS plugins and enterprise-grade support. - **What is the difference between formae Cloud and formae Enterprise?** formae Cloud is the hosted edition at a published price: we install it and we manage it. formae Enterprise is built around how you run formae at scale, so the installation, the policies, the security and the support are all shaped to that, and so is the price. - **What happens if I stop paying?** Your infrastructure stays in its last live state. It runs in your own cloud account and nothing is torn down. - **Can I start on formae IaC and move later?** Yes. --- ## formae IaC - open-source Infrastructure As Code Source: https://formae.ai/formae-iac --- title: "formae IaC - open-source Infrastructure As Code | Platform Engineering Labs" description: "Open-source Infrastructure As Code that starts from what already runs. formae IaC discovers your estate, versions drift and hands back current code." url: "https://formae.ai/formae-iac" --- # Self-hosted and fully yours Infrastructure As Code for the AI era: open source Stop pretending your legacy IaC repository describes reality. formae IaC starts with what exists, catches and versions out-of-band changes, and hands you always-current code to evolve. - No drift - Minimal blast radius - Always-current code - Full control [Quick start](https://docs.formae.ai/) [Pricing](https://formae.ai/pricing) `/bin/bash -c "$(curl -fsSL https://hub.platform.engineering/get/formae.sh)"` ### Featured in ![forbes.png](https://formae.ai/media/formae/forbes-800c.webp?__frsh_c=pma73x0pm9h0) ![thenewstack.png](https://formae.ai/media/formae/thenewstack-800c.webp?__frsh_c=pma73x0pm9h0) ![infoq.png](https://formae.ai/media/formae/infoq-148c.webp?__frsh_c=pma73x0pm9h0) ![siliconangle.png](https://formae.ai/media/formae/siliconangle-800c.webp?__frsh_c=pma73x0pm9h0) ## Infrastructure, before and after formae IaC 1. ![State & drift fight?](https://formae.ai/media/formae/left-800c.webp?__frsh_c=pma73x0pm9h0) *State & drift fight?* 2. ![Break free!](https://formae.ai/media/formae/mid-800c.webp?__frsh_c=pma73x0pm9h0) *Break free!* 3. ![IaC, as it should be](https://formae.ai/media/formae/right-800c.webp?__frsh_c=pma73x0pm9h0) *IaC, as it should be* ### Always-current infrastructure model **formae IaC** continuously discovers and synchronizes infrastructure across your entire estate - cloud, clusters, and beyond. It maintains an always-current model of what’s running and becomes the system of record without requiring migrations or mandates. ### Changes at any granularity **formae IaC** evolves infrastructure safely, from full rollouts down to single property updates, all expressed as code. It applies precise changes with minimal blast radius while schemas and constraints keep environments predictable and reduce cognitive load. ### Extensible and usable by anyone **formae IaC** is highly extensible and provides clear abstractions that make infrastructure accessible beyond infrastructure specialists. Engineers and AI systems can safely extend and evolve infrastructure as systems grow. ### No mandates. No migrations **formae IaC** can be introduced without replacing existing Infrastructure As Code or operational tooling. It runs alongside your current systems, continuously discovering infrastructure and enabling incremental evolution. ### No hacks. No workarounds. **formae IaC** gives you full control over your infrastructure model. Define your own schemas, shape infrastructure to match your mental model, and encode best practices directly into code. Build plugins, create abstractions, and expose simple interfaces for others - all without breaking safety or consistency. ### Keep what works. Move at your own speed. **formae IaC** works with what you already have. Your team's knowledge and your existing Terraform and Helm keep their value, whatever is running gets codified in minutes, and AI works from a short primer and one MCP. Nothing is mandated and nothing is rewritten. ## How formae IaC works: two loops, one infrastructure #### Reconciliation loop Infrastructure code declares the intended system. Changes flow through the infrastructure model and reconcile the running infrastructure based on the resulting diff, compatible with GitOps workflows. *How formae works: Infrastructure code declares the infrastructure model, which reconciles the running infrastructure. In the other direction, formae discovers the running infrastructure into the model, extracts code from the model, and applies patches back through it.* *How formae works: Infrastructure code declares the infrastructure model, which reconciles the running infrastructure. In the other direction, formae discovers the running infrastructure into the model, extracts code from the model, and applies patches back through it.* #### Extract - patch loop **formae** continuously maintains an always-current model of infrastructure. Engineers can extract code from the running system and evolve infrastructure through precise patches applied through the model, both at any granularity. ## Write simple, safe infrastructure code ## Powered by the Pkl language **formae IaC** uses **Pkl** to model infrastructure with schemas, constraints, and reusable abstractions. Pkl provides a clear and unambiguous way to express configuration, so infrastructure code stays simple to understand and safe to evolve. The result is code that humans can read at a glance and AI systems can generate and modify with precision. Schema The schema makes a resource absolutely precise. Once it passes validation it is effectively compiled: safe to run, with nothing left to break at apply time. Constraints Abstractions Resolvables schema.pkl 1 module aws.sqs.queuepolicy 2 3 import "../aws.pkl" 4 import "@formae/formae.pkl" 5 6 const type = "AWS::SQS::QueuePolicy" 7 8 @aws.ResourceHint { 9 type = module.type 10 identifier = "Id" 11 discoverable = false 12 } 13 open class QueuePolicy extends formae.Resource { 14 @aws.FieldHint 15 policyDocument: Dynamic 16 17 @aws.FieldHint 18 queues: Listing 19 } constraints.pkl 1 of 1 problem 1 typealias Team = "team-a" | "team-b" 2 typealias Size = "small" | "medium" | "large" 3 4 class Database { 5 team: Team 6 size: Size 7 } 8 9 local db = new Database { 10 team = "team-n" Type mismatch. Required: Team Actual: "team-n" 11 size = "medium" 12 } abstractions.pkl 1 properties { 2 team = new formae.Prop { 3 flag = "team" 4 } 5 6 size = new formae.Prop { 7 flag = "database-size" 8 default = "xs" 9 } 10 } $ formae apply --help abstractions.pkl Usage: formae apply [OPTIONS] Options: --mode Apply mode. This flag is required. --simulate Simulate rather than make changes. --force Overwrite changes since the last reconcile. --yes Run without any confirmations. Properties: --database-size property: database-size [default: xs] --team property: team [required] resolvables.pkl 1 class NetworkResources { 2 name: String 3 vpcLabel: String 4 vpcCidr: String 5 subnetCidr1: String 6 subnetCidr2: String 7 region: String 8 9 hidden attachIgw: vpcgatewayattachment.VPCGatewayAttachment = new { 10 label = "lifeline-igw-attachment" 11 vpcId = vpc.res.id id VpcResolvable vpcId ipv6CidrBlocks 12 internetGatewayId 13 } 14 15 hidden vpc: vpc.VPC = new { 16 label = vpcLabel 17 cidrBlock = vpcCidr 18 enableDnsHostnames = true 19 enableDnsSupport = true 20 } 21 } ## What engineers say about formae IaC > "Every enterprise tries to do Platform Engineering and at the end only abstract infrastructure with Backstage, then fights maintaining it. formae solved this differently with native IaC abstraction that just works. No portal to build, no catalogs to sync. Exactly what our customers need." Michael Mueller CTO re:cinq > "I used to shudder when a client would say they wanted to IaC their 10-year-old, click-ops created production environment. formae now makes this possible. I was able to accomplish this exact requirement using formae. The tool is easy to work with and the team at Platform Engineering Labs is highly accessible and eager to help. formae is now an integral part of my toolkit." Carson Williams Director Cloud Operations, Goods & Services > "I’ve been researching IaC options and formae came up. I instantly loved the idea! As a Platform Engineer, I feel like most current IaC tools are still primarily designed for developers and are somewhat lagging in this area. The Terraform struggle is real." Petr Cloud Engineer > "formae is designed for developers and platform engineers from the ground up. While this is a crucial pattern, formae doesn’t just move complexity from dev to ops - it truly helps achieve reduced cognitive load for both developers and operations teams by abstracting the complexity on both sides in modern cloud-native environments." Marc Schnitzius Platform Engineering Lead at codecentric > "I have felt the pain of Terraform/OpenTofu for a few years, and have gone to great lengths to try and ease the pain for the rest of my teams. formae’s mission to build a better API, so that I don’t have to do all of the craziness I’m doing now to make it sane for the rest of my platform engineers, is of strong interest." Sam DevOps Engineer > „The best time to sunset Terraform was 5 years ago, the second best time is now. Significant time was invested into making the situation better for teams dealing with infrastructure, and formae is approaching the problem in a way that makes it super convenient for teams to get started, yet stay in control.“ Stefan Staudenmeyer Retail tech lead & infrastructure practitioner > "I am building our internal dev platform and we have many challenges across multiple clouds. We currently use Terraform, but when I saw formae and its design decisions and philosophy, I thought to give it a go." Hassan Platform Lead > "formae keeps infra management simple. It’s super easy to get started with, and you don’t need to wrestle with overly complex state management like other IaC tools. What I love most is how it adapts to reality instead of pretending the world is perfect. It picks up changes made outside the tool, merges them cleanly, and keeps your infrastructure code as the actual source of truth. That’s a big deal when you're debugging weird issues or need to understand what’s really running at 3am." Anthony Moreno Seasoned On-Call Veteran > "Since I’ve seen the launch of the tool I’ve followed the evolution, and now with plugins I want to use it for almost everything. We are already using Pkl for most of our configurations, so formae being based on Pkl fits." Eduardo DevExp Lead > "I really like that Platform Engineering Labs is rebooting the space that is totally important for the modern IT, but is very prone to error and deprived of innovation for decades." Mirco Kater Information Security Officer at Ona > "I started focusing on platform and IaC after I started my new job and got overwhelmed by the crazy Terraform/Terragrunt management. I was genuinely thinking there should be a better way! formae sounds promising. At least the suffering you explained with classic IaC is real. Started tinkering with formae for the last couple of weeks. I hope this will grow and make our life easier!" Raja Data Platform Engineer > "This platform could be a major breakthrough in managing infrastructure in software projects. It allows both easier services management, dependency discovery and gives engineers a new way to collaborate." Robert Rychlik Director of Technology, Tipico > "I’ve been looking at this project for a while and decided to give it a try. I’ve been using Terraform since the beta version, back in 2015/2016, and I think it would be nice to give formae a try to compare both. Sounds promising! Excited to start this journey and contribute to the community." Raphael DevSecOps Engineer ## Who is formae IaC for - Why formae - State comes from what is really running, not from a file that claims to know - Apply at any granularity, from one resource to the whole stack - Out-of-band changes are captured and versioned instead of overwritten DevOps Engineer - Why formae - Minimal blast radius by design: change one thing without touching its neighbours - Patch mode for the incident, reconcile afterwards, and the drift is recorded - What you are reading is what is running, not what somebody committed Site Reliability Engineer - Why formae - Teams ask for what they need and never see what it is made of - You change what is underneath without anyone rewriting anything - Policies travel with the stack, so a guardrail is not a review meeting Platform Engineer - Why formae - Everything is found and described without anybody being asked to declare it - Order is applied continuously, not when somebody remembers to run something - The same rules run whoever is on shift, and every change is a versioned diff CISO - Why formae - One way to describe infrastructure instead of one per team and per vendor - The standard is executable: a forma is the document and the deployment - Roll it out against what already exists, team by team, without a mandate Enterprise Architect - Why formae - An inventory of what is really running, across clouds, without a discovery project - Most of what your teams do by hand is automated out of the box, with nothing to build - Adopt it on the estate you already have, with no big-bang migration to approve Enterprise CIO ## Frequently asked questions [Get in touch](https://platform.engineering/contact) - **What happens to everything my team and I know?** **Build on it. Put it to work.** Your knowledge is gold, and you need it. But you don't need the toil other tools throw at you. And you don't need to learn hidden semantics and provider misbehavior. - **What about the infrastructure we inherited, patched, and never fully documented?** **Discover it. Evolve it.** Automatically codify what is really running in minutes and make minimum-blast-radius changes right away - no manual inventory, imports, or cleanup needed. - **What about all the Terraform and Helm we already have?** **Keep it. Reuse it.** Use existing Helm charts and Terraform values quickly, then move at your own pace. - **Doesn't AI know other tools better?** **Show it formae. Put it to work.** A short primer, a few skills, one MCP - and AI helps make safe, high-impact changes fast. - **Is there a migration risk?** **Run side by side. Move gradually.** Start small with one resource, one property, or one chart. No mandates. No rewrites. ## Ready to try formae IaC? [Quick start](https://docs.formae.ai/) [Pricing](https://formae.ai/pricing) --- ## formae Cloud - fully managed infrastructure on autopilot Source: https://formae.ai/formae-cloud --- title: "formae Cloud - fully managed infrastructure on autopilot | Platform Engineering Labs" description: "formae Cloud is formae hosted and fully managed. Point your AI coding agent at your cloud account; it discovers, manages and keeps everything in sync." url: "https://formae.ai/formae-cloud" --- # Fully managed by us All infrastructure needs: writing the automation None of the work Build it and ship it yourself, live the same day. No ticket to raise, no platform to learn, no DevOps to hire or wait on. You just talk to infrastructure. Everything automatically stays in order, there before you need it, and nobody babysits it. - Nothing to adopt - Nothing to own - No DevOps to hire - Structure without effort [Quick start](https://docs.formae.ai/documentation/get-started/quickstart-cloud) [Go to Console](https://console.formae.ai/) Claude Code Codex 1 · install the formae plugin, then restart · Claude Code `/plugin marketplace add platform-engineering-labs/formae-marketplace` `/plugin install formae@formae-marketplace` 2 · ask for setup · Claude Code `set up formae for me` 1 · install the formae plugin · terminal `codex plugin marketplace add platform-engineering-labs/formae-marketplace` `codex plugin add formae@formae-marketplace` 2 · ask for setup · Codex `set up formae for me` ### Featured in ![Forbes](https://formae.ai/media/formae/forbes-800c.webp?__frsh_c=pma73x0pm9h0) ![The New Stack](https://formae.ai/media/formae/thenewstack-1032c.webp?__frsh_c=pma73x0pm9h0) ![InfoQ](https://formae.ai/media/formae/infoq-148c.webp?__frsh_c=pma73x0pm9h0) ![SiliconANGLE](https://formae.ai/media/formae/siliconangle-1014c.webp?__frsh_c=pma73x0pm9h0) ### Ask anything, change anything **formae Cloud** connects your AI coding agent to everything you run. What is there, what changed and what needs to be different are all the same conversation. ### Every change is precise and safe **formae Cloud** works out what has to change and in what order before anything moves, then applies the smallest set of changes that gets there. That machinery is ours to run and none of it is yours to see. ### Kept and versioned, out of sight **formae Cloud** keeps a complete record of what it built and every change since. You never have to look at it, and the day you do need it, for an audit or a handover, all of it is there. ### Nothing to run. Nothing to update **formae Cloud** is ours to keep running, patch and improve. Everything we ship next reaches you without an upgrade to plan, a version to chase or a window to book. ### No repository to own **formae Cloud** holds the definitions and every version of them. No code to maintain, and none of the rituals that go with it. ### No DevOps needed **formae Cloud** does what a pipeline would do: order the work, apply it, check it, retry it and record it. There is no automation to write and nobody needed to keep it working. ## How it works *How formae Cloud works: Your agent talks to console.formae.ai over MCP, which proxies that to your own formae agent, which formae runs for you. The agent manages your infrastructure in your AWS, GCP or Azure account through an OIDC role, and discovers what is running there back into its own state.* ## Talk to infrastructure without owning the detail - List everything running in eu-central-1 The answer comes from the account itself, so it includes what formae did not create. - Show what changed in checkout since it was last applied Every change is recorded as it happens, wherever the change came from. - Set the payment service memory to 2 GB One property on one resource, and nothing else in the stack moves. - Undo the redis-cache security group change and make it stick Somebody changed it by hand. Every later attempt is put back without being asked. - Stand up a staging copy of checkout, expire it Friday at 18:00 A whole environment, with a lifetime on it. Gone on Friday, with nobody remembering. - Take sandbox under management It was already discovered and versioned. Now it can be changed with formae too. ## Who is formae Cloud for - Why formae - Your team stays on the product instead of looking after infrastructure - A new service is live the day you write it, not the week after - It stays in order as you grow, with nobody babysitting it Startup CTO - Why formae - Your agent sets up what the service needs while you are still writing it - Staging and production come out the same, every time - No infrastructure team in the loop to deploy your own service Software Engineer - Why formae - Point it at an account and it tells you what is already there - Stand up a proof of concept from nothing, then tear it down on a timer - Nothing to install in the customer's estate to show them their own estate Solution Engineer ## Frequently asked questions [Get in touch](https://platform.engineering/contact) - **Where does my infrastructure actually live?** In your own cloud account, on AWS, GCP or Azure. formae Cloud runs the agent that manages it; the resources are yours, in your account, on your provider bill. Nothing of ours runs in there. - **What does formae Cloud get access to?** A role in your own account, granted by OIDC. There are no keys to hand over and no credentials of yours for us to hold, and what that role is allowed to touch is yours to set and to change. - **What do I have to learn?** Nothing. You talk to the AI coding agent you already use, with the formae plugin installed. There is no language to pick up, no repository to lay out and no pipeline to wire. - **What happens if I leave?** You stop using formae Cloud, and your infrastructure stays in its last live state. ## Ready to try formae Cloud? [Quick start](https://docs.formae.ai/documentation/get-started/quickstart-cloud) [Pricing](https://formae.ai/pricing)