Snart
Deploy hvor du ejer. Betal 10x mindre.
pks-aspire-coolify
En Aspire hosting-udvidelse på én linje, der sender hele din AppHost til en Coolify-host på din egen billige Hetzner- eller Scaleway-VPS — en besparelse på cirka 10x i forhold til de store skyer, uden en deploy-pipeline du ikke selv styrer.
Aspire gør det nemt at bygge. De store skyer gør det dyrt at sende ud.
Du har modelleret hele dit system i `AppHost.cs` — projekter, containere, referencer, miljøer — og det kører smukt på din maskine. Så kommer deploy, og den eneste velbetrådte vej er en managed sky: et målt control plane, en regning pr. ressource og en pipeline, du ikke kan se ind i. Den graf, du har skrevet så bevidst, bliver overladt til infrastruktur, du lejer og ikke ejer. Coolify modellerer allerede destinations, projekter, miljøer og services på en VPS, du selv ejer — så vi byggede den ene brik, der manglede: broen fra din Aspire-graf til den ejede hardware, på én linje.
Managed skyer måler hver ressource og hvert deploy — omkostninger der vokser med præcis det, Aspire producerer: mange små services, deployet ofte.
En Hetzner- eller Scaleway-VPS, der kører Coolify, koster cirka en tiendedel af det tilsvarende managed-fodaftryk — og maskinen er din, ikke lejet compute du ikke kan gennemskue.
Det "nemme" cloud-deploy er en black-box-pipeline: du kan ikke læse regningen linje for linje, du kan ikke flytte den, og du ejer ikke den hardware, dine agenter sender ud til.
Hvordan det virker
Tilføj én linje til din AppHost.
Kæd `.WithCoolifyDeploy(url, token)` på din builder, peg den mod din Coolify-host, og vælg en destination. Intet `using`-direktiv, ingen nye ressourcetyper — den lever i `Aspire.Hosting`-namespacet lige ved siden af `WithRedis` og `WithPostgres`.
Send dit token som en secret.
`AddParameter("coolify-token", secret: true)` — et typet håndtag, aldrig en værdi i kildekoden. Configure-fasen fejler hurtigt med et tydeligt symbol (`E_AUTH_TOKEN_MISSING`, `E_COOLIFY_UNREACHABLE`, …), før noget med sideeffekter overhovedet kører.
Kør `aspire deploy`.
Publisheren går gennem fem faste faser i rækkefølge — configure → build → push → deploy → verify. Den bygger dine images, pusher dem til dit registry og upserter Coolify-projektet, miljøerne og servicene, så de matcher din graf.
Kør igen når som helst.
Deploys er navne-nøglede og idempotente: at køre `aspire deploy` igen får din Coolify-host til at konvergere mod den aktuelle graf i stedet for at duplikere noget. Én AppHost forbliver ét Coolify-projekt, deploy efter deploy.
Én linje, intet nyt direktiv
`.WithCoolifyDeploy(url, token)` kædes på din eksisterende builder i `Aspire.Hosting`-namespacet — samme form som `WithRedis` eller `WithPostgres`, intet nyt at lære.
Fem bevidste faser
Hvert deploy går gennem configure → build → push → deploy → verify i fast rækkefølge, så du altid ved præcis, hvor du er i pipelinen.
Fejl hurtigt, fejl tydeligt
Configure-fasen nægter at gå videre ved et forkert token eller en unåelig host og viser ét af fire diagnose-symboler, før noget med sideeffekter overhovedet starter.
Idempotente gen-deploys
Navne-nøglede upserts betyder, at én AppHost mapper til ét Coolify-projekt; at køre `aspire deploy` igen konvergerer din host i stedet for at duplikere projekter eller services.
Din graf, mappet rent
Hvert Aspire-miljø bliver et Coolify-miljø, og hver containeriserbar ressource en Coolify-service — din `AppHost.cs`-mentale model overlever rundturen.
Secrets som typede håndtag
Coolify-URL, token og registry flyder ind som Aspire-parametre — `secret: true` på tokenet — aldrig som klartekst i din kildekode.
En håndskrevet client, ikke en genereret afhængighed. Broen til Coolify er en tynd, håndskrevet REST-client, vi pinner og ejer — ikke en SDK, vi ikke kan se ind i. Hver fase og hver diagnose er en beslutning, vi har truffet bevidst.
Du ejer destinationen. Hele pointen er, at hardwaren i den anden ende er din: din Coolify-host, din Hetzner- eller Scaleway-VPS, dit registry. Vi ejer publisheren; du ejer maskinen, den sender ud til.
Kører overalt, hvor Coolify gør. En homelab-server, én Hetzner-boks, en Scaleway-instans — den samme ene linje deployer den samme graf til hvilken som helst af dem. Intet managed control plane i vejen, som du ikke kan flytte væk fra.
Komponérbar af design. Det er det øverste delivery-lag, der ligger stille under resten af suiten: de underliggende lag producerer grafen og imagene, og dette lag sender dem ud — til hardware, du styrer, for cirka 10x mindre.
Bygger sammen med
Din Aspire-app. Sendt til hardware du ejer.
pks-aspire-coolify kobler `aspire deploy` direkte ind i din egen Coolify-host. Én linje i din AppHost forvandler hele din ressourcegraf til en kørende deployment på en Hetzner- eller Scaleway-VPS — for cirka en tiendedel af, hvad de store skyer tager. Samme kode, samme `aspire deploy`, en regning du endelig kan læse.