Drift¶
Virtuella maskiner och Docker Compose, skapade och underhållna med automation, på infrastruktur organisationen själv råder över.
Två driftformer¶
- Delad appvärd för teamappar. Många mindre appar delar en VM. Varje app får egna containrar, ett eget nätverk och en egen databas; containrarna körs utan root-rättigheter och med resursgränser, så att en app som skenar inte tar ner grannarna. Appar med olika informationsklass blandas inte – hellre flera delade värdar, till exempel per förvaltning eller per klass.
- Egen VM för verksamhetsappar. Gränsen mellan apparna ligger då i hypervisorn i stället för i en delad kärna, och ett fel eller intrång drabbar en app.
Varför VM:ar och inte Kubernetes¶
- Apparna är byggda med hjälp av AI av användare som inte är utvecklare. Det är kod man inte helt litar på, och en egen VM ger den starkaste isoleringen.
- Fel blir begränsade och begripliga: en app går sönder, inte ett kluster.
- VM:ar kan de flesta organisationer redan förvalta. Kubernetes kräver specialistkompetens som få kommuner har.
- En VM kan flyttas mellan leverantörer eller tas hem.
Förutsättningen är automation. Robustheten kommer inte från VM:arna i sig utan från att grundavbildning, patchning, backup, övervakning och certifikat sköts centralt. Utan det lagret blir hundra VM:ar hundra operativsystem att patcha för hand.
Kedjan¶
| Steg | Verktyg | Ansvar |
|---|---|---|
| Skapa infrastruktur | OpenTofu | VM, nätverk, brandväggsregler, DNS och backupprofil – genererat ur appens manifest |
| Konfigurera maskinen | cloud-init eller Ansible | Härdning, Docker, övervakningsagenter, utgående från en gemensam grundavbildning |
| Bygga och granska | Forgejo Actions | Bygga, köra granskningens kontroller, lägga avbildningen i organisationens eget register |
| Driftsätta | Forgejo Actions via SSH, eller Coolify | Docker Compose på mål-VM:en |
| Övervaka | Till exempel Prometheus, Grafana, Uptime Kuma | Loggar, mätvärden, tillgänglighet |
Verktygen i varje steg håller sig till sin uppgift. OpenTofu skapar maskinerna men konfigurerar inte operativsystemen, och driftsättningen av appen är skild från båda.
OpenTofu¶
OpenTofu är en förgrening av Terraform från tiden före HashiCorps licensbyte 2023, förvaltas under Linux Foundation och har licensen MPL 2.0 (ej oberoende verifierat i detta utkast). Valet följer av samma skäl som resten av analysen: det deklarativa verktyget för infrastrukturen ska inte självt bli ett beroende.
En provider är den insticksmodul som översätter OpenTofus kod till API-anrop mot ett visst system – Proxmox, en OpenStack-baserad svensk molnleverantör eller en tjänst som Elestio. Konceptet bygger en egen modul, till exempel app-vm, med ett gemensamt gränssnitt (namn, storlek, informationsklass, backupprofil) och en implementation per mål. Manifestets fält drift.miljo avgör vilken som används. Två saker att bevaka:
- Providerns underhåll. Kvaliteten varierar. För de mål som bär driften bör providern vara aktivt underhållen, eller så måste organisationen kunna ta över den.
- Tillståndsfilerna. De innehåller känsliga uppgifter och läggs i en egen S3-kompatibel lagring med låsning och kryptering, inte i Git.
Elestio har en egen provider och kan fungera som tillfälligt mål under en övergång, medan den egna automationen byggs upp. Providerns repo på GitHub har obehandlade uppdateringsförslag från september 2023, vilket bör kontrolleras innan man förlitar sig på den.
Coolify – valfritt¶
Coolify är en självhostad driftsättningsplattform av Heroku-typ. En styrserver ansluter till målservrar via SSH och kör Docker på dem, så den passar modellen med VM:ar. Version 4.0 blev stabil i april 2026, och version 4.1 i maj 2026 lade till strukturerad granskningsloggning. Licensen är Apache 2.0. Coolify saknar inbyggd övervakning, och stöd för att skala över många servrar är utlovat först i version 5, utan releasedatum.
I konceptet är Coolify ett bekvämlighetslager, inte en förutsättning. Egna pipelines i Forgejo Actions räcker, och eftersom allt körs som vanliga containrar på organisationens egna maskiner kan Coolify bytas ut utan att någon app flyttas. Styrservern har SSH-åtkomst till alla servrar och ska skyddas som en kritisk komponent.
En organisation per instans¶
Driften byggs för en organisation. Det följer ansvaret – varje organisation ansvarar för sina system och sin personuppgiftsbehandling – begränsar följderna av fel och intrång till en organisation, och gör att en organisation kan börja utan att först vänta på gemensamma avtal och finansiering. Mindre organisationer kan välja att gå ihop med grannar eller köpa driften av någon annan, men det är ett val och inte något konceptet förutsätter.
Källor¶
- Coolify: bitdoze.com, »Coolify v5 Review«, 20 maj 2026 (v4.0 stabil april 2026, v4.1 maj 2026 med granskningsloggning, v5 under utveckling).
- Coolify: temps.sh, »Coolify Review 2026« och »Coolify Pricing 2026«, 4 augusti 2026 (Apache 2.0, Traefik eller Caddy, saknar inbyggd övervakning, v5 utan releasedatum). Konkurrerande leverantör – uppgifterna om brister bör läsas som sådana.
- Coolify: Contabo blog, »Coolify vs CapRover«, 6 augusti 2026 (schemamigreringar vid uppgradering, backupråd).
- Elestio: »Managed Vibecoder Service«, elest.io, hämtad 26 september 2026 (en tjänst per VM, molnleverantörer, kontodata i EU, säte i Dublin). Leverantörsuppgift.
- Elestio Terraform provider: docs.elest.io och github.com/elestio/terraform-provider-elestio, hämtade 26 september 2026.