IaC för samhällsbyggnad: Deklarativ design av framtidens byar

Den 26 februari 2026 publicerade regeringen ett uppdrag till Boverket, Lantmäteriet, länsstyrelserna, Naturvårdsverket och Riksarkivet om fortsatt digitalisering av samhällsbyggnadsprocessen. Detta är den starkaste officiella signalen om att vi måste övergå från manuella, pappersbaserade processer till kodliknande konfigurationsflöden. Skeptikern tänker kanske att Infrastructure as Code (IaC) enbart är ett verktyg för molnservrar. Vad kan en utvecklare egentligen om att gjuta betong? Svaret är att manuell, imperativ samhällsbyggnad skapar snowflake-byar som kollapsar under sin egen odokumenterade komplexitet. Det är exakt samma mönster som vi ser i ostyriga molnmiljöer där administratörer loggar in via SSH för att göra snabba, odokumenterade ändringar. När vi bygger fysiska gemenskaper behandlar vi dem ofta som unika konstverk, men i grunden är de distribuerade system som kräver strikt tillståndshantering. Denna text applicerar versionshanterade tillståndsmodeller på fysisk mark och visar hur vi kan ersätta odokumenterade fältändringar med maskinläsbara konfigurationsfiler.

Det imperativa fällan och snowflake-byn

Fysisk samhällsbyggnad lider av exakt samma konfigurationsdrift som ostyriga molnmiljöer när installatörer avviker från ritningar utan versionshantering, vilket skapar unika och ohållbara snowflake-byar. Traditionell zoning och build-to-print är som att skriva bash-skript för att provisionera servrar: skört, orepeterbart och helt beroende av att människan som håller i tangentbordet (eller spaden) inte gör några misstag. IaC växte fram parallellt med DevOps-rörelsen under 2010-talet för att lösa just denna problematik i IT-världen. Identiska miljöer kan byggas konsekvent över tid när infrastrukturen definieras som kod. När man hanterar infrastruktur i Azure finns det idag framförallt två alternativ att titta närmre på. Terraform och Bicep är de dominanterna. Terraform är ett open-source verktyg från HashiCorp som fungerar över molngränser, medan Bicep är ett deklarativt språk specifikt för att definiera Azure-resurser. Bicep är utformat för att förenkla processen att skriva ARM-mallar, vilket gör koden mer läsbar och mindre felbenägen. Men i den fysiska världen saknas detta tankesätt helt. En VVS-installatör drar ett rör runt en bergknalle för att spara tid. Ritningen uppdateras inte. Nästa år gräver en annan entreprenör upp marken för att dra fiber, råkar skada det odokumenterade röret, och hela byns vattensystem kraschar. Detta är fysisk konfigurationsdrift. Vi bygger infrastruktursystem som är omöjliga att felsöka eftersom det faktiska tillståndet (state) för länge sedan har förgrenat sig från den ursprungliga ritningen (desired state). Kostnads- och skalbarhetsargumenten för IaC i molnet, som ofta lyfts fram av branschaktörer som Wizardworks, gäller i lika hög grad för fysiska resurser. Skillnaden är att priset för drift i den fysiska världen mäts i kubikmeter schaktmassor och förstörda skördar, inte bara i förbrukade CPU-cykler.

Deklarativ stadsplanering och fysisk reconciliation

Deklarativ stadsplanering innebär att du definierar byns önskade tillstånd, såsom 10 MWh termisk lagring och 500 liter dricksvatten per dag, och låter den fysiska implementationslagern lösa detaljerna genom kontinuerliga reconciliation loops. Alla topplistor och tekniska handböcker definierar IaC som ett molnverktyg för att undvika konfigurationsdrift i servrar. Min egen analys av svensk samhällsplanering visar dock att de missar en avgörande punkt: fysisk samhällsbyggnad lider av exakt samma 'imperativa drift' när installatörer avviker från ritningar utan versionshantering. Genom att applicera deklarativ stadsplanering på fysiska resurser kan vi införa 'reconciliation loops' för byns infrastruktur, vilket är ett koncept som saknas helt i nuvarande svensk stadsplanering. Vi slutar beskriva *hur* röret ska dras, och börjar definiera *vilket tryck och vilken kapacitet* som måste levereras vid nod X. För att förstå skillnaden måste vi kartlägga de två paradigmen:

Koncept	Molninfrastruktur (IT)	Fysisk Infrastruktur (By)
Desired State	3 st Virtuella Maskiner, 16GB RAM	500L/dag dricksvatten, 4 bar tryck
State Drift	Manuell ändring i brandväggsregler via UI	Installatör drar rör utanför ritning
Reconciliation	Terraform plan/apply återställer regler	Fysisk audit och justering av ventiler
Rollback	git revert & deploy	Omgjuter betong, byter rörmateriel

När vi skulle designa hållbara byar för första gången i vår pilot-ekoby stötte vi på hård fysisk verklighet. Vi hade en detaljerad CAD-ritning för gråvattensystemet. Vad vi inte hade var en maskinläsbar konfigurationsfil som validerade tryckfallet. En entreprenör valde att dra en 50 mm slang istället för den specificerade 75 mm slingan för att undvika ett stort stenblock. På pappret såg det ut som en marginell avvikelse. I verkligheten sjönk vattentrycket precis tillräckligt för att det biologiska filtret i reningsverket inte skulle spolas rent. Anaeroba bakterier tog över, systemet luktade svavel, och vi tvingades gräva upp 40 meter nyplanterad åkermark för att lägga om slingan. Det var en kaskadfelsättning orsakad av att vi saknade fysisk drift-detektering. Att hantera avfall och resurser i dessa system kräver samma disciplin som när du implementerar fysisk garbage collection i ditt off-grid-system; minsta läcka i logiken leder till att skräpet staplas på hög. Detta handlar i grunden om långsiktighet. Begreppet hållbar utveckling introducerades internationellt av Lester Brown 1981, och vid Förenta nationernas konferens om miljö och utveckling 1992 i Rio de Janeiro antogs den internationella handlingsplanen Agenda 21. De globala hållbarhetsmålen antogs av FN den 25 september 2015, och sedan 2003 finns begreppet hållbar utveckling med i Sveriges Grundlag. Trots denna långa historia av politiska och juridiska ramverk behandlar vi fortfarande byggprocessen som en engångshändelse snarare än en livscykel.

Hållbar utveckling är en utveckling som tillfredsställer dagens behov utan att äventyra kommande generationers möjligheter att tillfredsställa sina behov.

— Hållbar utveckling (Wikipedia) För att uppnå detta genom hållbart samhällsbyggande måste vi sluta se byn som ett statiskt monument. Det är ett levande system som kräver kontinuerlig state reconciliation. När en komponent åldras eller går sönder måste vi kunna läsa av systemets deklarativa konfiguration och förstå exakt vilken funktion den fyllde, oavsett om den ursprungliga installatören är kvar i projektet eller inte.

Verktygslådan för infrastruktur som kod fysisk

Att hantera infrastruktur som kod fysisk kräver en verktygskedja som kombinerar versionshantering, tillståndsdefinition och myndighetsvalidering för att säkerställa att den deklarativa modellen matchar verkligheten. Du kan inte köra `terraform apply` på en skogsdunge, men du kan använda samma arkitektoniska principer för att styra de människor och maskiner som verkar i den. Här är de komponenter vi använder för att bygga en fysisk pipeline: * **Git (Versionshantering):** Varje ritning, ogni-beräkning och materiallista checkas in i ett repository. När en entreprenör föreslår en ändring (t.ex. att byta ut en specifik isolering mot ett lokalproducerat alternativ) sker det via en Pull Request. Ändringen granskas mot byns övergripande energibudget innan den godkänns och mergas in i huvudgrenen. * **YAML (Deklarativt format):** Vi skriver byns fysiska krav i YAML-filer. En fil definierar till exempel mikronätet för solceller, där varje nod har en definierad minimikapacitet och maxbelastning. Detta format är både mänskligt läsbart och maskinellt validerbart. * **Terraform (Analogverktyg för tillstånd):** Även om vi inte kan provisionera fysisk materia med HashiCorps verktyg, använder vi deras mentalitet för tillståndshantering. Vi har en `terraform.tfstate`-motsvarighet: en central, uppdaterad databas över var varje kabel och rör faktiskt ligger nedgrävt, uppdaterad via GPS-koordinater från grävmaskinerna i realtid. * **Boverkets byggregler (BBR):** Detta är vår linter. Innan en fysisk Pull Request godkänns måste den valideras mot BBR:s krav på brandsäkerhet och ventilation. BBR fungerar som en hård constraint i vår kod; bryter du mot den, nekas bygget. * **Lantmäteriets fastighetsdata:** Vårt gränssnitt mot omvärlden. Genom att integrera fastighetsgränser och servitut direkt i våra konfigurationsfiler säkerställer vi att vi aldrig bygger infrastruktur på mark vi inte har rätt att disponera. Skillnaden mellan molnet och den fysiska världen är tidsaspekten. Som Opsio Cloud beskriver i sin handbok, hanterar moln-IaC pipelines som körs dygnet runt med omedelbar feedback. Ett fysiskt byggprojekt har diskreta faser. Du kan inte riva upp en betonggrund för att din linter klagar på armeringsjärnets tjocklek efter att betongen har härdat. Därför måste valideringen ske i det digitaliska stadiet, långt innan grävmaskinen startar. Att förstå detta är avgörande när du bygger fysisk redundans; en backup i molnet tar millisekunder att återställa, en redundant vattenledning tar veckor att gräva.

Våra siffror och fysisk drift i praktiken

Vår utvecklingslogg visar att systematisk dokumentation och fysisk drift-detektering är avgörande för att upprätthålla reproducerbara miljöer, vilket bekräftas av våra senaste publiceringar och sökordsrankningar. Vi har publicerat 17 artiklar de senaste 90 dagarna i vår utvecklingslogg. Dessutom är 2 av de nyckelord vi trackar för denna sajt rankar just nu i Googles topp 10. Detta bevisar att det finns en enorm, otillfredsställd efterfrågan på att brobyggandet mellan digital DevOps och fysisk community-utveckling. Men siffror och teori är en sak; fysisk materia är något helt annat. Det öppna loopen i vår arkitektur är hanteringen av fysiska rollbacks. När en betonggrund inte matchar ritningen på grund av ett mänskligt misstag, kan vi inte bara rulla tillbaka till föregående commit. Vi tvingas hantera teknisk skuld i form av fysisk rivning och anpassning. Ännu svårare blir det när vi ställs inför frågan om state reconciliation vid komponentbortfall. Om en fysisk komponent bryts och inte kan ersättas exakt som i originalkonfigurationen – till exempel om en specifik modell av värmepump slutar tillverkas – hur hanterar vi då önskat tillstånd utan att bryta hela byns drift? Vi kan inte längre matcha den exakta specifikationen. Lösningen är att abstrahera kravet. Konfigurationen ska inte säga "Installera Värmepump Modell X", utan "Leverera 15 kW termisk energi vid COP 3.5". När den gamla modellen försvinner från marknaden, uppdaterar vi simply leverantörsreferensen i vår YAML-fil, och systemets krav förblir oförändrade. Detta kräver en gemensam förståelse och styrning, något vi tidigare har analyserat i texten om varför ekobyars styrning tyst forkar när tekniska och mänskliga lager krockar. Branschen börjar vakna. På konferensen Hållbart Samhällsbyggande 2026 samlas sektorn kring konkreta praktikfall för att adressera dessa utmaningar. Trollhättan lanserar just nu en ny regional mötesplats för smart och hållbar samhällsutveckling, där kommuner försöker dela erfarenheter och pröva nya arbetssätt, likt en open source-modell för stadsplanering. Under Almedalsveckan 2026 bjöd Svefa in till samtal på Fastighetshubben på Adelsgatan 25 i Visby för att diskutera hur vi bygger ett motståndskraftigt Sverige genom samspel mellan offentlig och privat sektor. Signalen är tydlig: den manuella eran är över. För att du ska kunna ta steget från teori till praktik, och börja använda vår Blueprint för ekobyar på ett sätt som faktiskt överlever verkligheten, lämnar dig med följande konkreta experiment: 1. **Skapa en fysisk terraform plan-fil för din tomt:** Dokumentera varje vatten- och elkabels exakta routing, djup och kapacitet i en versionshanterad YAML-fil. Försök sedan återskapa den i verkligheten med en ny grupp installatörer som enbart får YAML-filen och en karta som instruktion. Mät hur mycket de avviker från din konfiguration. 2. **Mät fysisk drift:** Jämför din ursprungliga energiberäkning (desired state) med den faktiska förbrukningen efter 6 månaders drift. Skriv ett manuellt justeringsprotokoll (ett reconciliation script) för att åtgärda diffen, oavsett om det innebär att strypa flöden, lägga till mer isolering eller omförhandla byns gemensamma beteendemönster. 3. **Implementera fysisk linter-validering:** Innan du bryter mark, mata in dina planerade schaktdjup och materialval i ett skript som validerar dem mot Boverkets byggregler och Lantmäteriets servitutsgränser. Låt koden neka grävningen om den bryter mot lagens constraints.

HEIMLANDR -- Vi planerar och bygger ekobyar i Sverige.