Supported stacks and git hosts

What Deltz reads, and — the part worth more to you — where that support is deep and where it is not.

Infrastructure languages

CDK and Pulumi are gated, not learned

Both are reviewed through an artifact your own toolchain produces — CDK’s synthesised template, Pulumi’s preview JSON. The gate works on both. Neither gets convention derivation, and that is a decision rather than a backlog item: derivation over evaluated output finds the convention’s effect instead of the convention, so a loop that tags forty buckets reads as forty separately-tagged buckets and the actual rule is lost.

If learning your conventions is the reason you are evaluating Deltz, neither is served today. If you want the destructive-change and security gate on what your change actually does, both are.

Never read “CDK” or “Pulumi” in a list beside Terraform as parity. It is not.

Where it is thin, specifically

Crossplane convention derivation. On our benchmark corpus the gate derived only 3 conventions from three Crossplane repositories — one each — against 27 findings on those same repositories (17, 5 and 5). Between August 30 and September 6, 2026 the claim gate did not read their hand-authored composite resources at all, a coverage gap we published rather than counted as noise; garboard v0.1.65 closed it by gating a composite of an XRD family with no claimNames as the claim-shaped object a user authors, and 22 of the 23 findings came back (the 23rd was a false positive and stays fixed). So on a Crossplane tree, Deltz currently has more to say from its rules than it has learned from your repo. The rules are good; the learning is shallow. If your evaluation is mostly about “does it learn our conventions”, weight that accordingly.

Two deriver families fire on nothing in that corpus at all. We publish that on the gauntlet page rather than quietly dropping them.

Git hosts

One instance can serve both. GitHub and GitLab credentials are stored per organisation, so one deployment reviews a GitHub tenant and a GitLab tenant at the same time. Earlier builds chose one host at startup for the whole process; that is no longer the case.

GitHub is the deep path: a GitHub App with least-privilege scopes, pull request comments, and check runs with a proper neutral state for advisories.

GitLab now runs against live GitLab projects: a real merge request on gitlab.com was reviewed end to end — webhook delivery, the gate, a posted note and evidence links resolving into the project. It remains younger than the GitHub path, and the parts still unproven are named on its own page rather than left to the reader to guess.

There is also a real behavioural difference worth knowing before you evaluate it: GitLab commit statuses have no neutral state. GitHub can mark an advisory as neutral; GitLab cannot. So on GitLab an advisory posts a success status with the description prefixed advisory ·. The information is preserved; the traffic light is not, because GitLab does not have that colour.

Provider schemas

Crossplane gating is grounded in real provider CRD schemas rather than guesses, pinned in a local cache and managed with garboard schema sync and garboard schema ls. An unknown resource kind is reported as unknown rather than assumed valid.