naxty.dev
← All writing

Preventing Costly Configuration Deployment Mistakes with formae

Using Pkl types, schema validation and reusable secure defaults to prevent infrastructure configuration mistakes.

Originally published in Platform Engineering Labs on Medium ↗.

On this page
Preventing Costly Configuration Deployment Mistakes with formae — original article illustration
Image created with ChatGPT

In a world where a single configuration mistake can cost millions and disrupt lives, preventing catastrophic outages is crucial. From the $500 million CrowdStrike error to major incidents at Meta and Google, configuration changes are consistently the riskiest operations. Discover how formae, our groundbreaking open-source Infrastructure-as-Code (IaC) tool, offers type-safe, drift-aware solutions to protect your infrastructure and your bottom line.

The $500 Million Configuration Error

On July 19, 2024, a single configuration update brought down 8.5 million Windows machines across the world. CrowdStrike’s faulty “Channel File 291” didn’t just crash computers — it grounded thousands of flights, disrupted hospitals, and left Delta Air Lines with over $500 million in losses from cancellations and lawsuits.

It wasn’t a hack.
It wasn’t a hardware failure.
It was a configuration error.

And it’s far from being the only one:

Every outage tells the same story: In modern, cloud-native systems, configuration changes are the riskiest operations we perform.

Yet most teams still treat configuration as an afterthought — scattered across YAML files, half documented, and detached from the reality of what’s actually running in production.

Meet formae: Infrastructure-as-Code, Reimagined

We built formae to prevent exactly the kind of configuration disasters that have taken down some of the biggest players in tech. formae discovers and codifies what’s really running in your environment, turning your live infrastructure into versioned code that stays continuously in sync. Instead of relying on outdated IaC files in Git, formae becomes your source of truth — grounded in what’s actually running, not what you think it is.

Why formae is different

  • Reality-First Approach: formae automatically discovers existing resources — whether they were created via Terraform, scripts, or pure ClickOps.
  • Automatic Codification: It transforms existing infrastructure into declarative code and tracks changes over time.
  • No State Files: Forget fragile .tfstate files. formae keeps state invisible and always up-to-date.
  • Pkl-Native: formae leverages and upgrades Apple’s Pkl lang — a modern, type-safe configuration language that prevents invalid or insecure configs before they’re ever deployed.

Why Pkl? Because Configuration is a Minefield

Let’s be honest: YAML and JSON are fragile. They weren’t designed for safety-critical infrastructure. One missing space or forgotten field, and your deployment crumbles.

Even AWS acknowledged this by extending Rain to support PKL templates. Their reason:

PKL allows you to write type-safe templates and reusable modules — like CDK, but fully declarative.

Here’s what that looks like in practice:

Traditional YAML (easy to break)

Parameters:
  AppName:
    Description: Name used as prefix for resource names
    Type: String
 
Resources:
  ObjectStorageBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub ${AppName}-${AWS::Region}-${AWS::AccountId}
      # Easy to forget security configs
      # No compile-time validation

PKL with formae (type-safe and secure)

// bucket.pkl
​​import "@aws/s3/bucket.pkl"
// Secure S3 bucket that prevents public access
local function secureBucket(properties: Dynamic?): bucket.Bucket = new bucket.Bucket {
    label = properties.name.value
    bucketName = properties.name.value
    versioningConfiguration = new bucket.BucketVersioningConfiguration {
        status = "Enabled"
    }
    tags {
        new {
            key = "Name"
            value = properties.name.value
        }
        new {
            key = "Project"
            value = "FormaeDemo"
        }
        new {
            key = "Environment"
            value = "Development"
        }
        new {
            key = "Security"
            value = "Private"
        }
    }
    // Force secure configuration - cannot be overridden
    publicAccessBlockConfiguration = new bucket.BucketPublicAccessBlockConfiguration {
        blockPublicAcls = true
        blockPublicPolicy = true
        ignorePublicAcls = true
        restrictPublicBuckets = true
    }
    bucketEncryption = new bucket.BucketBucketEncryption {
        serverSideEncryptionConfiguration {
            new bucket.BucketServerSideEncryptionRule {
                serverSideEncryptionByDefault = new bucket.BucketServerSideEncryptionByDefault {
                    sseAlgorithm = "AES256"
                }
            }
        }
    }
}

YAML makes it easy to forget about security. With Pkl we can ensure security by design. The secureBucket() function enforces best practices automatically: versioning enabled, AES-256 encryption and public access fully blocked. This isn’t just convenience — it’s a safety net. You’re not hoping developers remember to lock the door. You’ve designed the system so the door locks itself.

Pkl’s Safety Advantages Inside formae

formae’s integration with Pkl turns configuration safety into a framework for deploying infrastructure safely and securely:

  1. Type Safety: Errors are caught before deployment and not during a Friday-night rollback.
  2. Schema Validation: Each resource is validated against a strong schema; invalid configs can’t even be generated.
  3. Security by Function: Functions like secureBucket() encapsulate policy-as-code. Developers can’t accidentally make a public S3 bucket.
  4. Abstraction Without Blindness: You can build reusable components without losing visibility into the underlying infrastructure.

Full Example: Provisioning the secure bucket

In formae we communicate with the user through formas. The following is a forma that shows how to deploy a secure AWS S3 bucket:

// s3.pkl
amends "@formae/forma.pkl"
import "@formae/formae.pkl"
import "@aws/aws.pkl"
import "./bucket.pkl"

properties {
    name = new formae.Prop { flag = "name"; default = "pel-s3-demo" }
}

forma {
    new formae.Stack {
        label = "pel-s3-simple-bucket"
        description = "Stack for a simple S3 bucket"
    }

    new formae.Target {
        label = "default-aws-target"
        config = new aws.Config { region = "us-west-2" }
    }

    bucket.secureBucket(properties)
}

Once you crafted the forma and saved it to a file, let’s say s3.pkl, you can check this forma’s contextual help through the apply command providing that Pkl file, and it will show you exactly which properties are available for configuration:

❯ formae apply --help s3.pkl
Properties:
 - name property: name [default: "pel-s3-demo"]

Everything else — encryption, versioning and access control is encapsulated inside the forma itself.

That means you can’t make a mistake. You can’t forget to turn on encryption or disable public access. You can’t have avoidable typos.

Now, apply that forma, and formae will tell you exactly what’s going to happen before actually changing anything:

 
❯ formae apply --mode reconcile --name my-awesome-bucket-1337 
Command will
└── create resource my-awesome-bucket-1337
├── of type AWS::S3::Bucket
└── in stack pel-s3-simple-bucket
Do you want to continue? (Y): Y

Once you confirm, formae creates the actual resource fully asynchronously, and you can check the progress by looking up the status of the apply command you just ran.

The beauty here is abstraction without blindness. You see the properties that matter — name in this case, while formae handles everything else applying the secure, validated, schema-checked defaults defined in your Pkl code.

How formae prevents the next $500M outage

formae’s architecture tackles configuration risk at multiple layers:

  1. Compiler-Grade Safety: Pkl guarantees that invalid configurations never reach production.
  2. Always up-to-date state: formae continuously scans your environment to detect and codify its current state. With formae, there is no drift. The state is always up-to-date and immediately versioned and codified.
  3. Versioned Changes: Every update is meticulously tracked and reviewable, providing a complete audit trail.
  4. Incremental Rollouts: Changes are applied as small, testable patches, minimizing the risk associated with large, “big-bang” updates.

The result: A system that knows what’s running, codifies it automatically, and protects you from accidental misconfigurations.

Why Configuration-as-Code Matters More Than Ever

Configuration mistakes are no longer just “technical incidents.” They’re business risks with million-dollar consequences. To stay safe in today’s cloud-native landscape, teams need tools that:

  • Treat configuration as first-class code
  • Offer robust type-safety and schema validation.
  • Continuously and automatically eliminate drift between declared and real state
  • Enable safe, incremental rollouts

Don’t wait for your own $500 million configuration mistake. Ask yourself:

  • Are you still managing infrastructure with fragile YAML or JSON?
  • Do you have type safety or schema validation for your configurations?
  • Can you detect configuration drift in real time and safely ?
  • Can you guarantee a small change won’t take down production?

If not, it’s time to rethink your tools.

formae is a new generation of Infrastructure-as-Code: compiler-grade type-safe, drift-aware, and grounded in the reality of your infrastructure. It prevents configuration errors through schema validation by design and applies changes with minimal blast radius — eliminating human error from the deployment process and making configuration safety a built-in property of the system.

Try it yourself

Keep exploring

Dvc: Develop Machine Learning Experiments In A Structured And Scaled Way

10 results↑ ↓ to explore · Enter to open
Project notes

Open project page