DEV Community: TuviDev

Say Goodbye to YAML Hell: Introducing Infra Lang v0.5.1

TuviDev — Tue, 25 Aug 2026 19:56:11 +0000

If you've ever spent 3 hours debugging a missing 2-space indentation in a 1,000-line Kubernetes YAML file or copy-pasting the same service definition between docker-compose.yml, Helm templates, and Terraform HCL — you're not alone.

Today, I’m excited to share Infra Lang v0.5.1, an open-source, human-friendly Infrastructure-as-Code (IaC) compiler that lets you define your architecture once in a clean, typed DSL and compile it to Kubernetes, Docker Compose, Helm Charts, and Terraform HCL.

🌟 Why Infra Lang?
Instead of choosing between raw YAML files or full imperative programming languages (JS/Python SDKs), Infra Lang provides a declarative, type-safe DSL with built-in FinOps cost calculation, live drift detection, and security linting.

Define Once, Deploy Anywhere
Write a single .infra file for local development (docker compose) and production (Kubernetes / Helm / Terraform):

environment "prod" {
service api {
replicas: 5
}
}

service api {
image: "myorg/api:v1.5.0"
port: 8080
cpu: "500m"
memory: "512Mi"
depends_on: [postgres_db]
env {
NODE_ENV: "production"
}
}

database postgres_db {
type: "postgres"
storage: "20Gi"
}

network_policy "api_sec" {
target: "api"
allow_ingress: ["frontend"]
block_all_ingress: true
}

🔥 What's New in v0.5.1?
Here are the flagship features packed into the v0.5.1 release:

⚡ 1. Service DAG Dependencies (depends_on)
Declare architectural dependencies (depends_on: [postgres_db]). Infra Lang automatically cross-compiles them into:

Kubernetes: initContainers (busybox waiting for TCP port availability before starting).
Docker Compose: Native depends_on with service_healthy conditions.
Terraform / Helm: Explicit DAG resource dependency edges.

🔒 2. Cloud Secret Stores (secret_store)
Native integration for HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, and Kubernetes ExternalSecret CRDs (external-secrets.io/v1beta1).

🛡️ 3. Network Policy Security DSL (network_policy)
Declaratively define traffic isolation rules and default-deny policies. Compiles to Kubernetes NetworkPolicy, isolated Compose networks:, or Terraform aws_security_group.

💰 4. FinOps Cost Estimation & CI/CD Guardrails (infra cost)
Know your cloud bill before deploying!

infra cost app.infra --format markdown

Generates clean Markdown tables for GitHub Pull Request comments and fails CI pipelines if monthly costs exceed budget (infra validate --max-cost 200).

🔎 5. Live Drift Detection & Terraform-Style Preview
infra doctor --check-drift --live — Compare running K8s/Compose state against .infra source files.
infra diff app.infra --live — Visual color-coded preview of planned changes before running infra up.

📦 Getting Started in 30 Seconds
Install via PyPI:

pip install --upgrade infra-lang

Compile to your favorite target:

infra compile app.infra -t kubernetes
infra compile app.infra -t compose
infra cost app.infra

VS Code Extension:
Search for Infra Lang in the VS Code Marketplace for live syntax highlighting, diagnostics, and autocompletion!

🤝 Open Source & Community
Infra Lang is 100% open-source under the MIT License, backed by 2,660+ unit tests, 96.7% test coverage, and 100% strict Mypy type safety.

GitHub Repository: github.com/TuviDev/infra-lang
Documentation: TuviDev.github.io/infra-lang
If you find the project useful, drop a ⭐ on GitHub and let me know your thoughts in the comments below!

How I built a DSL for infrastructure in 10 days with AI

TuviDev — Wed, 19 Aug 2026 20:34:36 +0000

Lessons from building infra-lang — an IaC DSL with 5 compilation targets, an LSP, and live K8s E2E tests. What worked, what surprised me, and what I'd do differently.

The idea

Every team I've worked with maintains the same application in at least three formats: Kubernetes manifests for production, a docker-compose.yml for local dev, and a GitHub Actions workflow for CI. Every change touches all of them. They drift. And bugs in the K8s YAML only surface when kubectl apply rejects them — not when you write them.

I wanted one file that compiles to all of them. So I built Infra Lang.

What it looks like

service api {
    image: "myapp/api:v1.0.0"
    replicas: 3
    port 8080
    health http("/health")
    resources {
        requests { cpu: 200m, memory: 256Mi }
        limits   { cpu: 1000m, memory: 512Mi }
    }
}

That block compiles to a Kubernetes Deployment + Service, a Docker Compose service, a Helm chart, Terraform HCL, or a GitHub Actions workflow. One source of truth, five targets.

Why a DSL, not YAML templates
Helm, Kustomize, and string interpolation in CI all push the same problem down the road: you still write YAML, just with placeholders. Validation still happens late.

A real DSL gives you three things:

A parser that catches errors immediately. Infra Lang uses a hand-written LALR(1) grammar with {} blocks. A typo is caught at parse time with a location and a helpful message — not after you deploy.

Compile-time linting. 10 security rules catch hardcoded secrets, mutable image tags, and privileged containers. 13 reliability rules catch thundering-herd replica counts, databases without backups, and single-replica Kafka. Error-severity findings block compilation entirely.

One mental model. You think in services, databases, queues, and pipelines — not in individual YAML documents for each platform.

The AI-assisted process
I want to be transparent: this project was built with extensive AI assistance — about 40 sessions over 10 days using Claude as a coding partner.

Here's how the process actually worked:

I owned every architecture decision. The DSL syntax, which backends to support, what the LSP should do, how to structure tests. AI doesn't make those calls.

AI wrote implementation and tests. I reviewed, ran, and iterated. Every session had a specific scope: "add semantic tokens to LSP", "fix Compose secret mounting", not "build me a DSL".

I ran everything locally. Docker Desktop, kind for Kubernetes E2E, real helm lint, real docker compose up. AI can't do that.

27 real bugs were found through the process. Secret base64 encoding that passed unit tests but failed kubectl apply. Service port naming that Kubernetes rejected. Windows URI path conversion that crashed the LSP. These are things you only find by actually running the code against real targets.

Is there risk in AI-assisted development? Yes — I don't know 100% of the codebase intimately. But the code runs, tests pass on 3 operating systems and 3 Python versions, and the output is validated against real Kubernetes clusters.

What surprised me
Coverage lies
93% line coverage sounded impressive. Then I ran mutation testing — automatically introducing bugs into the code and checking whether tests catch them.

Results: some modules had 34% mutation score despite high line coverage. The tests executed the code but didn't verify the output. A test that says assert result is not None gives you coverage but catches nothing.

After two sessions of targeted fixes, critical modules reached 82-100% mutation score. The lesson: line coverage tells you what code ran, not whether your tests actually work.

Cross-platform is harder than you think
My first CI run on Windows failed because .read_text() without encoding="utf-8" uses the system default (cp1252 on Windows). Every file read in the entire codebase needed explicit UTF-8.

Docker daemon detection needed special handling too — Windows CI runners have the Docker CLI installed but no running daemon. docker version succeeds but docker compose up fails. The fix: check docker info exit code, not just whether the binary exists.

The LSP was the most rewarding part
Building a language server taught me more about developer experience than anything else in this project. Each feature had its own challenge:

Cross-file rename needed word-boundary-aware regex — renaming db shouldn't touch main-db
Semantic tokens required a line-based tokenizer that doesn't crash on malformed input
Signature help needed brace-balance counting to detect which block the cursor is inside
Workspace indexing needed to scan files on disk without blocking the main LSP thread
The result: completion, hover, diagnostics, go-to-definition, find-references, rename, semantic tokens, signature help, document highlight, and folding — all working across every .infra file in the project.

Live E2E tests catch what unit tests miss
Three of the most serious bugs were invisible to unit tests:

Kubernetes Secrets with invalid base64 — unit tests checked structure, kubectl apply rejected the values
Multi-port Services without port names — valid YAML, invalid Kubernetes API
Compose secrets declared but never mounted to services — file existed, container couldn't access it
Now there's an opt-in test suite that actually spins up a kind cluster, runs kubectl apply, starts docker compose up, and runs helm lint --strict. These tests found real bugs that 1800+ unit tests missed.

What I'd do differently
Start with PyPI from day 1. I spent the first week telling people to pip install git+https://github.com/.... The friction was enormous. Once I published to PyPI, installation became pip install infra-lang — 5 seconds instead of a paragraph of instructions.

Write blog posts before launching. SEO takes weeks to build. Dev.to articles, technical deep dives, comparison posts — all of these should exist before you post on HN, not after.

Build community before features. I built 5 backends, a full LSP, Helm chart generation, and live E2E tests. Then I posted on Hacker News and got 13 upvotes. Features don't create adoption. Reach does.

The numbers
1877 tests, 93% line coverage, mutation testing on all critical modules
5 backends: Kubernetes, Helm, Docker Compose, Terraform, GitHub Actions
LSP with 10+ features including completion, hover, rename, semantic tokens, and signature help
CI on Linux, macOS, Windows across Python 3.11, 3.12, 3.13
Live E2E: real kubectl apply on kind, real docker compose up, real helm lint
Try it
Bash

pip install infra-lang
infra --help
Or with the VS Code language server:

Bash

pip install 'infra-lang[lsp]'
Links:

If you maintain infrastructure in multiple formats, I'd love your feedback — especially on language design and which compilation targets matter most.

One infrastructure definition, many targets

TuviDev — Tue, 18 Aug 2026 19:39:51 +0000

I built an open-source DSL that compiles a single .infra file to Kubernetes, Helm, Docker Compose, Terraform, or GitHub Actions.