A few months ago I wrote a post asking whether there’s something better than JSON. Two configuration languages that sit above JSON kept coming up: CUE and Dhall. Both give you the things JSON lacks when you author config by hand, and both compile down to plain JSON, YAML, or whatever your services actually read. I spent more time with CUE back then and never gave Dhall a real look. This post is me going back for that second look, because the one feature I kept wanting was a type system over my config.
\nJSON is the universal language of API payloads and config files, and I don’t want that to change. But as a format for authoring configuration by hand, it’s rough:
\n"8080" and 8080 look equally valid.The usual escape hatch is a templating engine like Jinja or Helm, or a real programming language like Python or TypeScript that spits out JSON. That works, but you’ve traded one problem for a scarier one: your config generator is now Turing-complete. It can crash, hang in an infinite loop, or reach out and read some local environment variable, and it’ll do it at 2 AM when the pipeline runs.
\nThis is where Dhall comes in.
\nThe short version: Dhall is JSON plus types, plus functions, plus imports. It’s a programmable, strongly-typed configuration language.
\nThe part I actually care about is what it doesn’t have. Dhall is not Turing-complete. No arbitrary recursion, no side effects. Every Dhall program is guaranteed to terminate. You get the abstraction power of a functional language like Haskell or Elm, with the guarantee that it will never hang your build. That’s a different trade than “just write a Python script.”
\nHere’s a normal config.json for a microservice:
{\n "serviceName": "payment-api",\n "port": 8080,\n "environment": "production",\n "database": {\n "host": "db.internal.net",\n "maxConnections": 50\n }\n}\nThree ways can be a problem in production: someone writes "port": "8080" and the service won’t boot, someone typos "prodution" and it silently runs in debug mode, or someone forgets maxConnections entirely and you get a null blowup at runtime. Nothing catches any of it until it’s live.
In Dhall you define the shape up front. Enums, record types, default values:
\n-- schema.dhall\nlet Environment = < Local | Staging | Production >\n\nlet Database =\n { Type = { host : Text, maxConnections : Natural }\n , default = { maxConnections = 20 }\n }\n\nlet Config =\n { Type =\n { serviceName : Text\n , port : Natural\n , environment : Environment\n , database : Database.Type\n }\n , default =\n { port = 8080, environment = Environment.Local }\n }\n\nin { Environment, Database, Config }\nNow you author against that schema, and you get defaults and composition for free:
\n-- config.dhall\nlet Schema = ./schema.dhall\n\nlet myConfig : Schema.Config.Type =\n Schema.Config.default\n // { serviceName = "payment-api"\n , environment = Schema.Environment.Production\n , database = Schema.Database.default // { host = "db.internal.net", maxConnections = 50 }\n }\n\nin myConfig\nMisspell Production, or pass "8080" as a string, and Dhall throws a type error before a single line of JSON is generated. Hopefully the benfit is now clear; adding a type safety layer to your config files.
You don’t ship Dhall to your services. You ship the JSON they already understand:
\nbrew install dhall-json\ndhall-to-json --file config.dhall\nOut comes clean, boring, standard JSON. Your services never know Dhall was involved. The part that I like is the safety lives at authoring time, and the runtime artifact stays dumb.
\nHermetic imports with hash pinning. Dhall can import from a URL, so shared utilities live in one place instead of being copy-pasted across five repos. To keep someone from swapping the file out from under you, you pin the import to a SHA-256 hash of its normalized form:
\nlet Prelude =\n https://prelude.dhall-lang.org/v22.0.0/package.dhall\n sha256:10db4c919c25e4d262db3ed0d1d6120da3e3906673f00e3012c1d14e1963976a\nIf the remote content changes, the hash won’t match and the build fails. The hash above is just an example, and each Prelude version has its own, so don’t copy it by hand. dhall freeze --inplace config.dhall computes the correct hashes for whatever you’ve imported and pins them automatically.
Exhaustive matching with merge. When you map a union type to output, Dhall makes you handle every variant:
let getLogPrefix = \\(env : Environment) ->\n merge\n { Local = "[DEV] ", Staging = "[STAGE] ", Production = "[PROD] " }\n env\nAdd a QA variant later, and every merge block that touched Environment fails to compile until you deal with it. No forgotten switch case slipping into production. The compiler keeps a running list of everything you now owe it.
| \n | Raw JSON | \nDhall | \n
|---|---|---|
| Type safety | \nNone, fails at runtime | \nStatic, at compile time | \n
| Comments & logic | \nNo | \nYes | \n
| Termination | \nN/A | \nGuaranteed | \n
| Dependency pinning | \nNo | \nSHA-256 | \n
| Output | \nConsumed directly | \nCompiles to JSON/YAML/TOML | \n
For a two-key config file, it doesn’t make sense, but once you’re staring down Kubernetes manifests, a pile of near-identical microservice configs, or anything where a typo takes down a service, the calculus changes. You keep clean static JSON as the thing your services actually read, and you move all the ways-to-get-it-wrong to a place where a compiler catches them first.
\ndhall-to-json, and dhall freeze.\n\n", "date_published": "2026-07-11T10:00:00-05:00", "url": "https://llbbl.blog/2026/07/11/adding-types-to-json-with.html", "tags": ["DevOps","Programming","Json","Configuration","Dhall"] } ] }I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.
\n