GitHub verlaagt prijzen runners tot 39 procent en vraagt geld voor zelf hosten

GitHub verlaagt vanaf 1 januari de kosten van vrijwel alle door het codeplatform gehoste Actions-runners met 20 tot 39 procent. Op 1 maart voert het bedrijf ook een nieuw tarief in van 0,002 dollar per minuut voor het zelf hosten van de clouddienst van deze runners.

De initiële prijsverlaging is van toepassing op bijna alle types runners, met uitzondering van de Linux 1-core. Runners zijn virtuele systemen die een workflow kunnen draaien en maken gebruik van de GitHub Actions-clouddienst. Volgens het platform verandert er voor 96 procent van de gebruikers niets. De overige 4 procent bestaat uit Actions-gebruikers, waarvan het grootste deel per maand goedkoper uit zal zijn.

Zo'n vijftien procent van die laatste groep gebruikers gaat echter per maand ongeveer dertien dollar meer betalen, claimt GitHub. Dit heeft te maken met de nieuwe kosten voor het zelf hosten van runners in privérepository's. Hoewel de runner lokaal draait, zijn gebruikers alsnog afhankelijk van de orchestrationlaag van GitHub. Deze dienst draait in de cloud en gaat 0,002 dollar per minuut kosten.

De totale potentiële kosten zijn afhankelijk van het abonnement van de gebruiker. Gebruikers met een gratis account hebben bijvoorbeeld maximaal 2000 gratis minuten per maand voordat er kosten in rekening worden gebracht voor door GitHub gehoste en zelf gehoste runners. Pro-gebruikers hebben 3000 gratis minuten. Het blijft overigens gratis om runners op openbare repository's te draaien. Ook verandert er niets voor afnemers van een GitHub Enterprise Server-abonnement.

Volgens GitHub zijn de nieuwe tarieven voor het zelf hosten van runners bedoeld om de kosten hiervan eerlijker te verdelen. Tot dusver was het mogelijk om vrijwel gratis runners te gebruiken wanneer deze lokaal draaiden, waardoor de kosten daarvan werden doorberekend aan afnemers van door GitHub gehoste runners.

Reacties (55)

[OB1]

Als ik de mail erbij pak, valt op dat GitHub claimt dat 96% van de gebruikers geen wijziging of een verlaging in het factuur kunnen verwachten.

Voor de overige gebruikers die enkel maken van self hosted runners betekent dit dat de factuur hoger gaat worden, terwijl gebruikers van de cloud runners juist minder zullen betalen. Wat zou de afweging hierin zijn geweest?

Hieronder de mail de die ik ontvangen heb:

---

You are receiving this email because your usage of GitHub Actions may be impacted by upcoming changes to GitHub Actions pricing.

What’s changing, when

• On January 1, 2026, all customers will receive up to a 39% reduction in the net price of GitHub-hosted runners, depending on the machine type used.
• On March 1, 2026, we are introducing a new $0.002 per-minute GitHub Actions cloud platform charge that will apply to self-hosted runner usage. Any usage subject to this charge will count toward the minutes included in your plan.

No action is required on your part.

We’re excited to say that as a whole this means GitHub will be charging less than ever for Actions. 96% of customers will receive a lower bill or see no change.

Please note the price for runner usage in public repositories will remain free, and there will be no changes in price structure for GitHub Enterprise Server customers.

For more details, please visit our posts on GitHub’s Executive Insights page and the GitHub Changelog.

Why we’re making this change

Actions usage has grown significantly, across both CI/CD and agentic workloads. This update provides lower costs for most Actions users, aligns pricing with actual consumption patterns, and helps us continue investing in improvements to the Actions platform for the benefit of all customers.

Recommended resources

To help you prepare for this change, we’ve published several updated tools and guides:

• For answers to common questions about this change, see the FAQ in our post on GitHub’s Executive Insights page.
• See the GitHub Actions runner pricing documentation for the new GitHub-hosted runner rates effective January 1, 2026.
• For more details on upcoming GitHub Actions releases, see the GitHub public roadmap.
• For help estimating your expected Actions usage cost, use the newly updated Actions pricing calculator.
• If you are interested in moving existing self-hosted runner usage to GitHub-hosted runners, see the SHR to GHR migration guide in our documentation.

You can find more information on GitHub’s Executive Insights page and the GitHub Changelog.

[Reactie gewijzigd door OB1 op 17 december 2025 08:11]

[Christoxz]

Wat zou de afweging hierin zijn geweest?

De druk voelen van bijvoorbeeld blacksmith.sh? Mensen/bedrijven nog meer willen laten doen binnen Github i.p.v. extern?

Door de prijs te verlagen, wordt het wellicht interessant voor bedrijven om het toch volledig via Github te laten lopen i.p.v. extern (self hosted daar buiten gelaten).

Zie Blacksmith hun reactie:
www.blacksmith.sh/blog/actions-pricing

[elmuerte]

Met github's nieuwe prijzen betaal je dus 0.004 + 0.002 /minuut voor de goedkoopste blacksmith.sh runner (2 core), exact hetzelfde als een 2 core runner bij github.

[I_IBlackI_I]

Alleen de blacksmith.sh runner is wel sneller, en dus minder minuten nodig.

[supersnathan94]

Hoe goed is dat te kwantificeren? Als er uiteindelijk alsnog afgerond wordt per X seconden of minuut, dan maakt het weinig uit dat je 10% sneller bent.

[jeroen3]

Ik wist helemaal niet dat er services waren die "hosted" self-hosted runners aanboden. Lijkt me logisch dat GitHub Microsoft dit liever niet heeft, zeker niet als die externen dat elders dan Azure doen.

[BCC]

Naja, als je meerwaarde in het platform zit (GH actions) en niet meer zozeer in deCPU cycles verkopen, dan moet je je prijsmodel aanpassen imho.

[jeroen3]

Dan is er vermoedelijk sprake van een paar procent gebruikers die extreem veel gebruik maken van deze service. Want als er bij 96% geen verandering is, levert het ook geen extra cash op.

Of het is ter voorbereiding van een andere beleidswijziging?

[swhnld]

Het kan gewoon een push worden om het hele self-hosted minder aantrekkelijk te maken, en als je eenmaal over bent, dan kunnen ze langzaam maar zeker meer diensten slijten.

Als vuistregel, Microsoft speelt het lange termijn spel. Of het nu Windows, Office, Azure of Github is. Zit je immers solide in het eco systeem, dan blijf je erin want niet te duur, alles integreert lekker, etc.

Overigens, andere partijen werken op dezelfde manier. Doe maar eens contact opnemen met AWS over een lift en drop van je on prem servers naar hun cloud. Korting, gratis/goedkope consultancy, etc. vliegen je om de oren om je erheen te helpen. Zit je er eenmaal ben je immers een constante stroom aan inkomsten.

[supersnathan94]

Als vuistregel, Microsoft speelt het lange termijn spel. Of het nu Windows, Office, Azure of Github is. Zit je immers solide in het eco systeem, dan blijf je erin want niet te duur, alles integreert lekker, etc.

Nou... lekker is ook anders, maar het werkt voldoende goed om er niet helemaal horendol van te worden. Azure devops is nou niet bepaald een tool waar ik heel vrolijk van wordt.

[tszcheetah]

Ik vraag me wel af wie ze wel en niet onder die 96% klanten ("customers" obv de bron) rekenen. Noemen ze open source gebruikers/organisaties en hobbyisten ook klanten, of bedoelen ze alleen de betalende gebruikers? De berichten van Github zijn natuurlijk ook een stuk marketing, dus alle 1-persoons hobbyprojecten als klant meerekenen om dit percentage omhoog te krikken maakt de boodschap een stuk positiever; maar het zou goed kunnen dat het aantal klanten met self-hosted runners een stuk significanter is voor de omzet van Github dan die 4% nu doet vermoeden.

En: op langere termijn wil Microsoft natuurlijk ook inkomsten veilig stellen bij toekomstige prijsverhogingen. Een verhoging kan tot nu toe nog een trigger zijn om self-hosted runners in te richten, omdat dat uiteindelijk goedkoper is en de overstap relatief laagdrempelig is. Nu self-hosted minuten ook geld kosten, heeft dan minder zin (ook die prijzen zullen omhoog gaan bij algemene prijsverhogingen). Dan moet je heel het platform gaan migreren om onder de extra kosten uit te komen, en die investering is vele malen hoger. Kortom: nu de prijzen verlagen en self-hosted minder aantrekkelijk maken, en dan later over de hele linie de prijzen langzaamaan weer opdrijven om meer winst te pakken... ik zie het zo gebeuren.

[SilentLucidity]

voor het self-hosted stukje zal het vast ook zijn omdat er toch een team op moet zitten om de self-hosted images en infra moet onderhouden. Prijsverlagingen kunnen alleen maar door goedkopere concurrentie komen..

[yuckywucky]

"Wat zou de afweging hierin zijn geweest?"
vanaf nu kunnen prijsverhogingen doorgerekend worden aan beide, is mijn gok

[Cobesz]

Het zal wel zo zijn hoor... 2000 (3000 voor betaalde orgs) minuten zijn best een hoop. Je kan hier inzien hoeveel je verbruikt heb de afgelopen maand in je eigen org: https://github.com/orgs/<JOUW_ORG)/actions/metrics/usage?dateRangeType=DATE_RANGE_TYPE_PREVIOUS_MONTH

Wat mij vooral steekt is dat het nu toch wel heel erg onaantrekkelijk wordt voor degene die al hebben gekozen voor self hosted? Of het aanraden aan anderen trouwens, zal ik nu ook een stuk minder snel doen. Wij zaten wel al meteen te kijken wat de mogelijkheden zijn om onze CI op een eigen gehoste gitlab omgeving te draaien. Vooral tegenwoordig met een ChatGPT bijvoorbeeld het omzetten van je workflows ook zo gepiept lijkt mij.

Ik snap best dat iets geld kost, maar voor een organisatie als Github ben je nu toch wel een grote sellingpoint kwijt.

P.s. Terwijl ik dit typ zie ik de bui alweer hangen trouwens dat de andere grote git platformen een zelfde geintje uit gaan hangen. Denk aan Gitlab bijvoorbeeld. Ik krijg het idee dat het internet steeds minder leuk wordt..

[Reactie gewijzigd door Cobesz op 17 december 2025 16:26]

[Joost1981_2]

Voor organisaties, die GitHub Enterprise draaien is dit welkom. In Nederland draaien veel organisaties Azure DevOps. Al snel wordt het argument opgegooid dat GitHub Enterprise ruim 3x zo duur is tov Azure DevOps per gebruiker. Men vergeet vaak de kosten van de runners mee te berekenen. GitHub Enterprise zal in de meeste gevallen duurder zijn tov Azure DevOps (die is gewoon te goedkoop) echter niet 2x of 3x zo duur.

Self-Hosted is last resort, dat wil je vandaag de dag niet tenzij echt niet anders kan (on-premisses of speciale software)

[BasilFX]

Self-Hosted is last resort, dat wil je vandaag de dag niet tenzij echt niet anders kan (on-premisses of speciale software)

Of omdat het een stuk sneller is. Onze ervaring met de hosted agents op Azure DevOps, is dat builds 2-3x trager zijn dan self-hosted. We draaien onze builds op oude machines (oude Dells, i5-45xx), en dat gaat al jaren goed en goedkoper. De pipelines zijn ingericht dat we ze snel weer op hosted agents kunnen draaien, in geval van 'nood'.

[Joost1981_2]

Er bestaan in GitHub large runners. Daar betaal je uiteraard voor maar de performance is daar wel een stuk sneller.

Daarnaast is de filosofie anders: Zoveel mogelijk parallel draaien in GitHub want je betaald toch per minuut. Bij Azure DevOps ga je juist dingen sequentieel draaien omdat je daar per parallele job betaald:

In Azure DevOps: linting, sonar, SCA, building in 1 job
In GitHub allemaal separate jobs en dus sowieso sneller

[Reactie gewijzigd door Joost1981_2 op 17 december 2025 09:10]

[supersnathan94]

Zoveel mogelijk parallel draaien in GitHub want je betaald toch per minuut.

is dat zo? In mijn ervaring is het parallel draaien van meerdere jobs niet verschillende voor de uiteindelijke rekening. 1x 10 minuten of 10x 1 minuut wordt op dezelfde manier gefactureerd. Opzich ook niet gek aangezien je per taak een job opspint die gewoon geld kost.

[Kun]

Ik ben het niet met je eens dat self-hosted last resort is. Er zijn zat redenen waarom je self-hosted agents wilt. Denk aan betere performance of deployments naar omgevingen (cloud of on-premise) die je niet open wilt zetten voor deployments vanaf het internet.

[BCC]

Inderdaad de performance voor onze CI/CD pipline is zo idioot veel hoger self hosted dat de devs echt niet terug willen naar hosted. Helpt ook een boel dat je bijvoorbeeld WEL docker images kan cachen.

[Scriptkid]

Had je voor cloud runners wel grotere betaalde machines in de pool?

[Joost1981_2]

Er bestaat zoiets als caching he. En je hebt large runners

[BCC]

Uiteraard, maar daar hangt ook een ander kostenplaatje aan.

[daanb14]

Dit is een heel goed argument. Er zijn genoeg redenen waarom je dit soort zaken intern wilt houden en het is prima mogelijk om self hosted je runners te draaien en dat goed in te richten.

[Joost1981_2]

Je hebt large runners voor performance en vnet peering (in Azure). Dus waarom zou je het zelf willen beheren (op het argument van on-premisses of speciale software wat niet in containers kan draaien)?

[Xorgye]

Omdat eigen hardware nog steeds goedkoper is dan cloud. Dat is t altijd al geweest en zal het altijd blijven.
Cloud is alleen goedkoop bij onvoorspelbare loads en als je niet weet of je een paar jaar vast wil zitten aan afschrijving en beheerkosten.

Het is vaak andersom: je neemt een paar eigen machines die je helemaal vol zet qua resources met de zwaarste processen, en de rest (en flexibele zaken) host je in de cloud.
Dan heb je t beste van beide werelden.

[Joost1981_2]

Heb je zelf ervaring met het managen van dit soort runners? Framework updates? Security patches? Up & down schalen?

[Wouter-KaBouTeR935]

Bijvoorbeeld: een Android emulator draaien om ui test met geautomatiseerde screenshots uit te voeren. Werkt voor geen meter op github Actions/linux. Wel op lokale macOS runners.

[Djerro123]

Juist voor enterprises is de AzDO pricing prettiger. Je betaalt 15$ per maand voor een parallelle job op eigen runner (agent). Wil je 10 jobs tegelijk kunnen draaien, betaal je 150$.

Daar kan je bij GitHub die tien runners dus 125 uur laten draaien per stuk, ongeveer 1/6e van de tijd. In mijn organisatie rekent dat niet rond, de agents staan meer dan 1/6e van de tijd wat te doen.

[Joost1981_2]

Ja? En wat zijn de kosten voor het beheren/automatiseren van je eigen runners? Hoe hou je die up-to-date? Hoe provision je die? Hoe hou je die schoon?

[Reactie gewijzigd door Joost1981_2 op 17 december 2025 09:14]

[Meauses]

Golden image maken met al je tools erin, of alleen docker/podman en de runner agent (bijv. m.b.v. packer en ansible), en m.b.v. cloud-init updates laten draaien en runner registreren bij boot. Deze runners iedere 24u cyclen in bijv een scaling set. En bij benodigde tool updates eens in de zoveel tijd een nieuwe golden image maken, Rinse and repeat :)

[Reactie gewijzigd door Meauses op 17 december 2025 09:55]

[Joost1981_2]

ah elke 24 uur. Dus gedurende dag raken ze vervuild?

[Meauses]

Ligt eraan wat je als vervuild beschouwt, maar vanwege de verschillende taken wordt je storage gebruikt en kan bijv door grote docker images vollopen, en iedere dag kunnen updates uitkomen. Je kan er ook iedere x dagen van maken, het is maar net waar je behoefte ligt en wat je belangrijk vindt. Maar jouw vraag was; hoe houd je die schoon. Nou o.a. zo :)

[Reactie gewijzigd door Meauses op 17 december 2025 10:02]

[Clueless]

Optie die we bij ons in de organisatie gebruiken is de Azure Managed DevOps Pools. Dan heb je keuze in je pre-provisioning, reuse etc. En je kunt zelfs de images van Microsoft gebruiken die zij dus bijhouden voor je. Scaling-wise kun je ze ook op 0 pre-provisioned zetten en dan heb je dus geen kosten als er niks draait; duurt dan wel wat langer om een agent te provisionen voor je.

Deze Pools kun je ook injecten in je eigen Azure netwerk en ze als interne runner gebruiken.

Meer info: https://learn.microsoft.com/en-us/azure/devops/managed-devops-pools/overview?view=azure-devops

[Reactie gewijzigd door Clueless op 17 december 2025 11:10]

[Joost1981_2]

MDP is lekker makkelijk en weinig omkijken aan maar je betaald ook voor de standby uren. En dat is dus wat ik probeer te zeggen: Met GitHub heb je dat niet meer nodig. Large runners en VNet peering.

De software op de microsoft images is gelijk. Less is more

[divvid]

Self-Hosted is last resort, dat wil je vandaag de dag niet tenzij echt niet anders kan (on-premisses of speciale software

Op een closed repo van een non-profit project zonder financiële resources, met bijbehorend systeem (gedoneerde VPS), draaien wij al meer dan 4 jaar een selfhosted runner. Nog nooit problemen mee gehad. Voor ons zal er niet zoveel veranderen omdat we 'nu' niet aan de 2000 build time minuten komen, op ons eigen systeem nb). Daar zou je nu ineens voor moeten betalen voor iets dat een paar MB grootte checkout doet en wat api calls? Ik ben dan ook benieuwd hoe ze die runner minuten willen berekenen.

Alleen als we een merge naar master of dev doen?

Dat runner ding draait gewoon als een daemon en doet misschien 3x per maand iets, maar als ze 24/7 gaan rekenen kom ik inderdaad op $89/maand uit.

Als iemand er iets meer over kan vertellen HOE ze die selfhosted runners berekenen? ik kan er niets over vinden zo gauw

[Reactie gewijzigd door divvid op 17 december 2025 08:37]

[Joost1981_2]

Hoe zorg je ervoor dat je wel gebruik maakt van de laatste versies van bijvoorbeeld SDK's?

[Lijmer]

Tenzij je een GPU nodig hebt, dan is cloud hosted idioot duur vergeleken met self-hosted.

Daarnaast is het van de zotte dat ze extra geld gaan vragen op basis van hoe lang iets op je eigen server draait. Helemaal nu die action runners AI rommelcode bevat die infinite loops veroorzaakt.

[Joost1981_2]

Er zullen altijd uitzonderingen zijn.

Je angular/react/vue thingie of java/c# thingie kan prima op cloud runners. Heb je performance nodig doe je een large runner.

[jeroen3]

Nu heeft github wel goed uitgeruste windows runners. Maar gitlab en bitbucket hebben dat totaal niet, dus daar moet je wel self-hosted gaan.

[MiKE_B]

het opvallende vond ik dat er wordt geclaimed dat er “up to 35%” discount is voor hosted minutes. En dat klopt ook, maar dat is alleen voor de grotere/luxere runners. De standaard Linux 1 core runner blijft exact even duur als voorheen. En het tarief daarvoor is exact hetzelfde tarief als wat ze gaan rekenen voor self-hosted runners. Ze hebben mogelijk best een aantal heel grote klanten die veel self-hosted runners hebben die extreme hoeveelheden data en API-calls kosten?

Nog een extra reden voor mij om me achter mijn oren te krabben en te denken over Forgejo of codeberg!

[Scriptkid]

Denk je dat andere diensten gratis blijven, ze moeten omdat de grote dat deden nu die niet meer gratis zijn kun je rekenen dat zij ook kosten gaan maken..

In deze wereld is niks gratis,

[MiKE_B]

Het gaat me niet zo zeer om het “gratis”.

Forgejo is self-hosted en codeberg drijft op donaties. GitHub heeft een extreem netwerk-effect. Maar ik geef liever geld aan codeberg dan aan GitHub!

[s0ulmaster]

Als ik even een snelle rekensom maak kost het mij 86 dollar per maand om 24/7 runners zelf te hosten ongeacht de schaalgrote voor hoeveel mensen hier gebruik van maken? (ben niet bekend met hithub runners) of is elke runner opzich een instance waar je voor bestaald?

[Reactie gewijzigd door s0ulmaster op 17 december 2025 08:15]

[JBVisual]

Tot dusver was het mogelijk om vrijwel gratis runners te gebruiken wanneer deze lokaal draaiden, waardoor de kosten daarvan werden doorberekend aan afnemers van door GitHub gehoste runners.

Dit is ook gewoon een eerlijker systeem, en ook iets wat zeer logisch klinkt.
Het feit dat ze ook andere prijzen verlagen, geeft aan dat het ze momenteel ook dus eerlijker willen gaan verdelen. (De marge van de diensten die goedkoper worden verschuift nu tenslotte naar het "per minuut tarief".

Let op, hier volgt een speculatie
Ondanks dat ik dit soort actief goed vind omwille van transparantie, heb ik het gevoel dat ze meer mensen proberen te onboarden naar hun eigen cloud ipv het zelf hosten.
Als over 3-5 jaar nog maar een handjevol over is, kunnen ze aangeven dat het in stand houden van deze service niet langer rendabel meer is.
Daarna kunnen de cloud-prijzen uiteraard weer omhoog.
Niks omwille van deze actie, maar in het verleden bij andere diensten dit grapje iets te vaak gezien.

[DaanHetEendje]

Gebruikers met een gratis account hebben bijvoorbeeld maximaal 2000 gratis minuten per maand voordat er kosten in rekening worden gebracht voor door GitHub gehoste en zelf gehoste runners.

Dit komt niet overeen met het prijsvoorbeeld op de docs van GitHub Daar staat:

From March 1, 2026, regardless of your plan, using 5,000 minutes on self-hosted runners would have a total actions minutes cost of $10 USD for using the GitHub Actions cloud platform.


Calculation: 5,000 * $0.002 USD per minute = $10 USD

Oftewel met selfhosted runners krijg je per 1 maart 0 minuten gratis.

Erg jammer nu ik echt net vorige week begonnen ben met de migratie van Azure DevOps naar GitHub.

[rolf-smit]

Dit is natuurlijk gewoon het mooi verpakken van "we willen meer mensen in ons eigen ecosysteem locken".

Ik snap dat Microsoft nog steeds kosten maakt aan self-hosted runners, immers gaat er wel gewoon data-verkeer naar zo'n self-hosted runner. Maar in dit geval is de combinatie met de prijzen voor je eigen runners verlagen, natuurlijk een slimme zet. Ik zie dit als self-hosten onaantrekkelijk maken, en dat is in mijn ogen iets waar alleen de big-tech voordeel aan heeft.

[Pusherman_]

Runners zijn virtuele systemen die een workflow kunnen draaien

Het hele begrip runner is nieuw voor me en ook met deze uitleg nog wat abstract. Ik kan natuurlijk aan GPT een uitleg vragen, maar er is vast een mede tweaker die dit beter kan verduidelijken.

[s0ulmaster]

Het is bedoeld om geatomatiseerd zaken door te kunnen draaien (workflow). Denk aan Automatische deployments, nachtelijkse software testen, automatisering voor re releaseflow van je software en ga zo maar door. Dit haakt in op je geversioneerde software die je dan ook in github hebt staan.

[PaulHelper]

Effectief zijn het tijdelijke resources/stukjes servers die jouw taken voltooien. Vaak duurt het wel even voordat het geïnitieerd is maar voor dagelijkse/wekelijkse dingen is dit natuurlijk geen probleem. Je doet dit niet voor dingen die instant of elke minuut moeten draaien voor zover ik weet.

Persoonlijk vind ik runners ook een speciale benaming, maar ik gok dat ze iets anders wilden dan algemene termen die weer andere betekenissen kunnen hebben

[Reactie gewijzigd door PaulHelper op 17 december 2025 11:02]

[Ed Vertijsment]

ik heb de laatste tijd het gevoel dat de (gratis hosted) runners trager zijn geworden, heeft iemand soortgelijke ervaringen?

[sint_ignucius]

Als u infra afhankelijk is van een verbinding die niet door jou beheert wordt in hoeverre ben je dan aan het zelfhosten.

Ik versta onder zelfhosting volledig in beheer zijn van Alle infrastructuur die centraal on prem staat, zonder afhankelijk te zijn van een vage cloud dienst voor containers of vm's. Het enige wat verdedigbaar is om afhankelijk te zijn is imho de devteams van gebruikte software voor veiligheidsupdates desnoods maar dit is maar een bijzaak naar mijn mening... als u systeem al afhankelijk is van een "Propitiatory Backdoor" om een cronjob te doen op uw codebase/containers dan lijkt me dat toch wel een grotere dreiging allesinds in mijn threat model...

In dat licht hoe zorg je voor de contiuiteit van de dingen die je aanbied als je afhankelijk bent van propitiatory backdoors die tegen je gebruikt kunnen worden... zij het al door een prijsverhoging... Dat men dan gaat lopen roepen "wij willen Euro soevereine cloud" dan is dat toch de ultieme misvorming in het denken aangaande netwerken/systemen/software in die zin wat is "De Cloud" of beter gezegd "Wat verwacht men van de cloud?" en dit kan verschillen van individu tot organisatie maar zolang mijn ups blijft draaien heb ik basis infrastructuur genoeg om te voorzien in basis communicatie(netwerken) voor vrienden en familie.

Het is voor een deel te wijten aan het niet doorhebben hoe decentraal alles geregeld kan worden en dat ook niet ten volle benutten. Maar natuurlijk als u ene maatschappij wil organiseren waar bewust single points of failure worden ingebouwd is dat iets anders... Dan wil u wel ene SHAPE met een soc, noc, en weet ik veel wat nog allemaal...