Neckbeard is een plugin die coding agents ondersteunt bij het creëren van cloud-infrastructuur. Het lost het probleem op waarbij AI-modellen vaak onveilige of onbetaalbare infrastructuur-code genereren door een strikte scheiding van taken: mensen beheren een catalogus van geversioneerde OpenTofu-modules, terwijl de agent enkel de applicatie analyseert en koppelt aan deze modules via deterministische Go-code.
Belangrijkste kenmerken:
- Multi-cloud ondersteuning: Werkt met AWS, GCP en Azure via serverless containers of Kubernetes.
- Kostenbeheersing: Integreert met Infracost om maandelijkse kosten te schatten voordat er gedeployed wordt.
- Validatie: Hanteert drie niveaus van controle: statische analyse (V0), geauthenticeerde planning (V1) en deployment verificatie (V2).
- Beveiliging: Maakt gebruik van OIDC-federatie in plaats van statische keys en hanteert standaard privé-netwerken.
De workflow volgt een vast pad van analyse (/neckbeard:analyze), planning, kostenraming (/neckbeard:estimate), scaffolding en validatie (/neckbeard:sync).
Neckbeard: Cloud-infrastructuur Scaffolding voor Coding Agents
Het probleem met AI en infrastructuur
Coding agents zijn uitstekend in applicatiecode, maar zijn vreemd genoeg overmoedig wanneer het om infrastructuur gaat. Als je een agent vraagt om "dit naar AWS te deployen", krijg je vaak driehonderd regels geloofwaardige HCL (HashiCorp Configuration Language), een security group die openstaat voor de hele wereld, een IAM-policy met een wildcard-teken, en geen enkel idee van wat dit alles kost. Het leest als het werk van iemand die elke blogpost heeft gelezen, maar nog nooit is opgeroepen tijdens een storing. Het model liegt niet; het heeft simpelweg nooit een factuur gezien.
De oplossing: Scheiding van taken
Neckbeard splitst het proces. Mensen beheren een catalogus van OpenTofu-modules die geversioneerd zijn, bij elke wijziging in CI worden getest en beperkt zijn tot één eerlijke workload-vorm: een container-image, maximaal tien HTTP-, worker- en cron-processen, Postgres, object storage en secrets.
De agent analyseert je repository, bepaalt wat de applicatie nodig heeft, stelt vragen die de code niet kan beantwoorden en koppelt de antwoorden aan de inputs van de catalogus. Alles daartussenin is deterministische Go-code. De planner schrijft een hash-geverifieerd blueprint.yaml, de renderer is een pure functie hiervan, en bij regeneratie weigert het systeem bestanden te overschrijven die door een mens zijn gewijzigd.
De agent verzint nooit infrastructuur. Als je applicatie Redis nodig heeft, krijg je een melding dat de catalogus Redis nog niet ondersteunt, in plaats van een module die eruitziet alsof hij zou kunnen werken.
Ondersteuning
- Cloudproviders: AWS, GCP en Azure.
- CI/CD: GitHub Actions of GitLab CI.
- Runtimes: Serverless containers (Cloud Run, ECS Fargate, Container Apps) of Kubernetes (EKS, GKE, AKS).
De vorm van de plugin is gebaseerd op ponytail, wat bewees dat een plugin grotendeels kan bestaan uit één goede prompt.
Installatie
Voor Claude Code
Voer de volgende twee prompts uit: /plugin marketplace add bealesh/neckbeard /plugin install neckbeard@neckbeard
Open vervolgens de repository van je applicatie en run /neckbeard:analyze. Het eerste commando installeert de kleine CLI die de plugin aanstuurt (een sha256-geverifieerd release-binary, of via go install als Go is geïnstalleerd).
Kostenramingen en validaties maken gebruik van tools die je mogelijk al hebt: Infracost, OpenTofu en Checkov. Met /neckbeard:doctor kun je zien wat er ontbreekt en wat elke tool toevoegt.
Overige tools
Voor Codex, Cursor of andere tools die een SKILL.md kunnen lezen: raadpleeg INSTALL.md.
Gebruik en Workflow
Wanneer je /neckbeard:analyze uitvoert, analyseert de agent de repository zoals een zorgvuldige nieuwe medewerker dat zou doen. Er wordt gekeken naar Dockerfiles, openstaande poorten, omgevingsvariabelen, health-endpoints, het Procfile en specifieke instellingen (zoals waar Django DATABASE_URL leest).
De agent stelt een applicatieprofiel op waarin elk feit is gekoppeld aan een bestand en regelnummer, elke inferentie een betrouwbaarheidsscore heeft en elke aanname expliciet wordt vermeld. Daarna stelt de agent vragen over zaken die het niet uit de code kan afleiden:
- Verwachte hoeveelheid verkeer.
- Tolerantie voor downtime.
- Of Postgres al draait of nieuw gebouwd moet worden.
- Het doel van de worker.
De planning start pas zodra alle openstaande vragen zijn beantwoord.
Commando-overzicht
| Commando | Functie |
|---|
/neckbeard:analyze | Analyseert de repo naar een app-profile.yaml met bewijslast, stelt openstaande vragen en stelt neckbeard.yaml voor. |
/neckbeard:estimate [comparison] | Plant tegen de catalogus en toont de maandelijkse kosten, inclusief zaken die niet geprijsd konden worden. Vergelijkt bijv. serverless vs kubernetes of solo vs smallteam. |
/neckbeard:sync | Plant, schat kosten, scaffoldt en valideert. Handmatige bewerkingen worden nooit stilzwijgend overschreven. Eindigt met PASSED, FAILED of NOT EXERCISED per check. |
/neckbeard:doctor [plan$\mid$estimate$\mid$validate$\mid$all] | Installeert de CLI indien nodig en rapporteert welke tools aanwezig zijn. |
/neckbeard:help | De korte versie van deze documentatie. |
Kostenramingen
In plaats van te wachten op de factuur, raadpleegt neckbeard eerst Infracost. Voor een referentie-applicatie (HTTP-service, worker, cron job, Postgres) op de kleinste tier in drie omgevingen, ziet de vergelijking er als volgt uit:
| Runtime | Maandelijkse kosten |
|---|
| Cloud Run | $77 |
| Container Apps | ~$98* |
| ECS Fargate | $250 |
| EKS | $396 |
| GKE (regional) | $754 |
| AKS | ~$801* |
\ Infracost kan compute voor Container Apps nog niet prijzen. Neckbeard is hier eerlijk over en vermeldt elke resource die niet geprijsd kon worden naast het totaalbedrag.*
Het rapport scheidt de idle baseline van het verbruik, legt de aannames over verbruik vast, biedt scenario's (laag, verwacht, hoog) en vermeldt de bron van de cijfers.
Validatieniveaus
Neckbeard rapporteert in drie niveaus om te voorkomen dat er onterecht wordt aangenomen dat iets direct deploybaar is:
- V0: Statisch (Syntax en Policy)
tofu validate [prd]checkov policy [prd] (elke skip moet een geschreven reden hebben)kubeconform (clusters/)- V1: Geauthenticeerd plan (Vereist cloud-credentials) → staat op
NOT EXERCISED tot een mens dit uitvoert.
- V2: Deployment verificatie (Vereist cloud-credentials) → staat op
NOT EXERCISED tot een mens dit uitvoert.
Wanneer live runs falen, worden deze fouten opgenomen in een publiek register met bevindingen, wat vervolgens leidt tot fixes in de catalogus.
Functionaliteiten
- Isolatie: Drie geïsoleerde omgevingen met eigen state, gebaseerd op tier-presets (verkeer, beschikbaarheid, recovery objectives).
- Pipelines: Een intern model voor CI: test, build, scan (Trivy blokkeert HIGH en CRITICAL), push, plans op pull requests (read-only), en applies op main (write).
- Beveiliging:
- Geen statische cloud-keys; gebruik van OIDC-federatie end-to-end.
- Netwerken zijn standaard privé.
- Secret managers bevatten namen die door de operator worden ingevuld (waarden passeren nooit via neckbeard of git-historie).
- Managed WAF-regels worden ingeschakeld waar de tier dit vereist.
Huidige Status (Pre-alpha)
| Claim | Bewijs |
|---|
| Analyse, planning, schatting, scaffolding en validatie op alle 12 cloud × VCS × runtime paden | Statische matrix draait in CI op elke PR; drie onafhankelijke fixture-apps onboarden end-to-end. |
| Live deploy, update en rollback op serverless containers | Geslaagd op AWS/GitHub en Azure/GitHub met echte database-checks. |
| Live deploy op GCP, GitLab lanes, Kubernetes, promotie en recovery drills | Geïmplementeerd, maar NOT EXERCISED. |
De huidige focus ligt op de voorkant: reviewbare infrastructuur, pipelines, kostenramingen en een runbook. Landing zones (organisatiestructuur en guardrails) zijn ontworpen maar nog niet gebouwd.
Architectuur
De workflow is als volgt opgebouwd:
Gebruiker / Agent → Deterministische Core → Output
- Analyse: De agent verzamelt feiten, bewijslast en antwoorden → resulteert in een
profile en config.
- Planning: De core koppelt dit aan gepinde versies in de catalogus → resulteert in een
blueprint.yaml (hash-verified lockfile).
- Uitvoering:
- Estimate: Via Infracost en scenario's.
- Scaffold: Ownership contract (geen stilzwijdige overschrijvingen).
- Validate: V0 statisch, V1 plan, V2 deploy.
De root van de repository is de plugin. skills/neckbeard/SKILL.md is de handleiding voor de agent, terwijl de Go CLI (cmd/) en de catalogus (catalog/) het deterministische deel vormen. De CLI kan ook onafhankelijk van een agent worden gebruikt:
go install github.com/bealesh/neckbeard/cmd/neckbeard@latest
neckbeard analyze && $EDITOR app-profile.yaml neckbeard.yaml
neckbeard plan && neckbeard estimate && neckbeard scaffold && neckbeard validate
Licentie
Apache-2.0, zie LICENSE.
Neckbeard: Cloud-infrastructuur Scaffolding voor Coding Agents
Het probleem met AI en infrastructuur
Coding agents zijn uitstekend in applicatiecode, maar zijn vreemd genoeg overmoedig wanneer het om infrastructuur gaat. Als je een agent vraagt om "dit naar AWS te deployen", krijg je vaak driehonderd regels geloofwaardige HCL (HashiCorp Configuration Language), een security group die openstaat voor de hele wereld, een IAM-policy met een wildcard-teken, en geen enkel idee van wat dit alles kost. Het leest als het werk van iemand die elke blogpost heeft gelezen, maar nog nooit is opgeroepen tijdens een storing. Het model liegt niet; het heeft simpelweg nooit een factuur gezien.
De oplossing: Scheiding van taken
Neckbeard splitst het proces. Mensen beheren een catalogus van OpenTofu-modules die geversioneerd zijn, bij elke wijziging in CI worden getest en beperkt zijn tot één eerlijke workload-vorm: een container-image, maximaal tien HTTP-, worker- en cron-processen, Postgres, object storage en secrets.
De agent analyseert je repository, bepaalt wat de applicatie nodig heeft, stelt vragen die de code niet kan beantwoorden en koppelt de antwoorden aan de inputs van de catalogus. Alles daartussenin is deterministische Go-code. De planner schrijft een hash-geverifieerd blueprint.yaml, de renderer is een pure functie hiervan, en bij regeneratie weigert het systeem bestanden te overschrijven die door een mens zijn gewijzigd.
De agent verzint nooit infrastructuur. Als je applicatie Redis nodig heeft, krijg je een melding dat de catalogus Redis nog niet ondersteunt, in plaats van een module die eruitziet alsof hij zou kunnen werken.
Ondersteuning
- Cloudproviders: AWS, GCP en Azure.
- CI/CD: GitHub Actions of GitLab CI.
- Runtimes: Serverless containers (Cloud Run, ECS Fargate, Container Apps) of Kubernetes (EKS, GKE, AKS).
De vorm van de plugin is gebaseerd op ponytail, wat bewees dat een plugin grotendeels kan bestaan uit één goede prompt.
Installatie
Voor Claude Code
Voer de volgende twee prompts uit: /plugin marketplace add bealesh/neckbeard /plugin install neckbeard@neckbeard
Open vervolgens de repository van je applicatie en run /neckbeard:analyze. Het eerste commando installeert de kleine CLI die de plugin aanstuurt (een sha256-geverifieerd release-binary, of via go install als Go is geïnstalleerd).
Kostenramingen en validaties maken gebruik van tools die je mogelijk al hebt: Infracost, OpenTofu en Checkov. Met /neckbeard:doctor kun je zien wat er ontbreekt en wat elke tool toevoegt.
Overige tools
Voor Codex, Cursor of andere tools die een SKILL.md kunnen lezen: raadpleeg INSTALL.md.
Gebruik en Workflow
Wanneer je /neckbeard:analyze uitvoert, analyseert de agent de repository zoals een zorgvuldige nieuwe medewerker dat zou doen. Er wordt gekeken naar Dockerfiles, openstaande poorten, omgevingsvariabelen, health-endpoints, het Procfile en specifieke instellingen (zoals waar Django DATABASE_URL leest).
De agent stelt een applicatieprofiel op waarin elk feit is gekoppeld aan een bestand en regelnummer, elke inferentie een betrouwbaarheidsscore heeft en elke aanname expliciet wordt vermeld. Daarna stelt de agent vragen over zaken die het niet uit de code kan afleiden:
- Verwachte hoeveelheid verkeer.
- Tolerantie voor downtime.
- Of Postgres al draait of nieuw gebouwd moet worden.
- Het doel van de worker.
De planning start pas zodra alle openstaande vragen zijn beantwoord.
Commando-overzicht
| Commando | Functie |
|---|
/neckbeard:analyze | Analyseert de repo naar een app-profile.yaml met bewijslast, stelt openstaande vragen en stelt neckbeard.yaml voor. |
/neckbeard:estimate [comparison] | Plant tegen de catalogus en toont de maandelijkse kosten, inclusief zaken die niet geprijsd konden worden. Vergelijkt bijv. serverless vs kubernetes of solo vs smallteam. |
/neckbeard:sync | Plant, schat kosten, scaffoldt en valideert. Handmatige bewerkingen worden nooit stilzwijgend overschreven. Eindigt met PASSED, FAILED of NOT EXERCISED per check. |
/neckbeard:doctor [plan$\mid$estimate$\mid$validate$\mid$all] | Installeert de CLI indien nodig en rapporteert welke tools aanwezig zijn. |
/neckbeard:help | De korte versie van deze documentatie. |
Kostenramingen
In plaats van te wachten op de factuur, raadpleegt neckbeard eerst Infracost. Voor een referentie-applicatie (HTTP-service, worker, cron job, Postgres) op de kleinste tier in drie omgevingen, ziet de vergelijking er als volgt uit:
| Runtime | Maandelijkse kosten |
|---|
| Cloud Run | $77 |
| Container Apps | ~$98* |
| ECS Fargate | $250 |
| EKS | $396 |
| GKE (regional) | $754 |
| AKS | ~$801* |
\ Infracost kan compute voor Container Apps nog niet prijzen. Neckbeard is hier eerlijk over en vermeldt elke resource die niet geprijsd kon worden naast het totaalbedrag.*
Het rapport scheidt de idle baseline van het verbruik, legt de aannames over verbruik vast, biedt scenario's (laag, verwacht, hoog) en vermeldt de bron van de cijfers.
Validatieniveaus
Neckbeard rapporteert in drie niveaus om te voorkomen dat er onterecht wordt aangenomen dat iets direct deploybaar is:
- V0: Statisch (Syntax en Policy)
tofu validate [prd]checkov policy [prd] (elke skip moet een geschreven reden hebben)kubeconform (clusters/)- V1: Geauthenticeerd plan (Vereist cloud-credentials) → staat op
NOT EXERCISED tot een mens dit uitvoert.
- V2: Deployment verificatie (Vereist cloud-credentials) → staat op
NOT EXERCISED tot een mens dit uitvoert.
Wanneer live runs falen, worden deze fouten opgenomen in een publiek register met bevindingen, wat vervolgens leidt tot fixes in de catalogus.
Functionaliteiten
- Isolatie: Drie geïsoleerde omgevingen met eigen state, gebaseerd op tier-presets (verkeer, beschikbaarheid, recovery objectives).
- Pipelines: Een intern model voor CI: test, build, scan (Trivy blokkeert HIGH en CRITICAL), push, plans op pull requests (read-only), en applies op main (write).
- Beveiliging:
- Geen statische cloud-keys; gebruik van OIDC-federatie end-to-end.
- Netwerken zijn standaard privé.
- Secret managers bevatten namen die door de operator worden ingevuld (waarden passeren nooit via neckbeard of git-historie).
- Managed WAF-regels worden ingeschakeld waar de tier dit vereist.
Huidige Status (Pre-alpha)
| Claim | Bewijs |
|---|
| Analyse, planning, schatting, scaffolding en validatie op alle 12 cloud × VCS × runtime paden | Statische matrix draait in CI op elke PR; drie onafhankelijke fixture-apps onboarden end-to-end. |
| Live deploy, update en rollback op serverless containers | Geslaagd op AWS/GitHub en Azure/GitHub met echte database-checks. |
| Live deploy op GCP, GitLab lanes, Kubernetes, promotie en recovery drills | Geïmplementeerd, maar NOT EXERCISED. |
De huidige focus ligt op de voorkant: reviewbare infrastructuur, pipelines, kostenramingen en een runbook. Landing zones (organisatiestructuur en guardrails) zijn ontworpen maar nog niet gebouwd.
Architectuur
De workflow is als volgt opgebouwd:
Gebruiker / Agent → Deterministische Core → Output
- Analyse: De agent verzamelt feiten, bewijslast en antwoorden → resulteert in een
profile en config.
- Planning: De core koppelt dit aan gepinde versies in de catalogus → resulteert in een
blueprint.yaml (hash-verified lockfile).
- Uitvoering:
- Estimate: Via Infracost en scenario's.
- Scaffold: Ownership contract (geen stilzwijdige overschrijvingen).
- Validate: V0 statisch, V1 plan, V2 deploy.
De root van de repository is de plugin. skills/neckbeard/SKILL.md is de handleiding voor de agent, terwijl de Go CLI (cmd/) en de catalogus (catalog/) het deterministische deel vormen. De CLI kan ook onafhankelijk van een agent worden gebruikt:
go install github.com/bealesh/neckbeard/cmd/neckbeard@latest
neckbeard analyze && $EDITOR app-profile.yaml neckbeard.yaml
neckbeard plan && neckbeard estimate && neckbeard scaffold && neckbeard validate
Licentie
Apache-2.0, zie LICENSE.
Groetjes,