Waarom deployen eigenlijk zo ingewikkeld moest zijn

Even heel eerlijk: een static website online zetten zou niet voelen als een trip naar de maan.

En toch. Het is 2024 en developers besteden uren aan het instellen van CI/CD pipelines, deployment scripts schrijven, environment variables managen, en worstelen met platformen die beloven simpel te zijn maar vooral complexiteit leveren. Vermoeiend, om het zacht te zeggen.

Totdat er iets voorbijkomt als pgs.sh — een piepklein deployment dienstje dat precies één ding doet, en dat verdomd goed doet.

De charme van rsync

Het mooie aan pgs.sh is dat het het wiel niet opnieuw uitvindt. Geen proprietary upload mechanisme, geen nieuwe CLI om te leren. In plaats daarvan steunt het op wat developers al kennen: rsync.

Wie al een tijdje in de tech zit, kent rsync waarschijnlijk als de redder in nood. Het is de Zwitsarse zakmes voor bestandsoverdracht — snel, betrouwbaar, en bewezen door decennia gebruik. pgs.sh geeft rsync simpelweg een plek op het web, met automatische TLS erbij.

De opdracht spreekt voor zich:

rsync -rv public/ pgs.sh:/myproj/

Klaar. Je public/ folder, gesynchroniseerd naar een live URL. Geen YAML bestanden. Geen webhooks. Geen "even wachten terwijl we je build environment opzetten."

Waarom dit telt voor developers en startups

Het ding over complexiteit: het stapelt op. Een deployment proces dat "voor nu" simpel is, verandert nogal eens in technische schuld waar je maandenlang mee worstelt. Elk configuratiebestand is een potentiële storingsbron, iets wat nieuwe teamleden moeten leren, een extra laag tussen jou en je live site.

Als je de onnodige lagen weghaalt, houd je dit over:

Snelheid. Niet alleen deploy snelheid, maar mentale snelheid. Je schakelt niet heen en weer tussen dashboarden en documentatie. Je typt gewoon een commando dat je al kent.

Betrouwbaarheid. Minder bewegende delen betekent minder dingen die kunnen falen. Geen uitval van je CI provider die je workflow platlegt. Geen verrassende rate limits. Gewoon rsync dat zijn werk doet, zoals sinds 1996.

Draagbaarheid. rsync commando's zijn overdraagbare kennis. Het deploy script dat je vandaag schrijft, werkt op pgs.sh, je eigen server, of de infrastructuur van een vriend. Dat is krachtig.

De filosofie achter het gereedschap

Er zit een bredere les in over de tools die we kiezen en bouwen.

We hebben onszelf allemaal wijsgemaakt dat meer features gelijk staat aan meer waarde. Dat een deployment platform Kubernetes integratie nodig heeft, preview environments, branch deployments, real-time analytics, en AI-gestuurde optimalisatie om zijn bestaan te rechtvaardigen.

Maar pgs.sh stelt een andere vraag: wat als de beste feature juist geen feature is?

Dit is geen anti-progressie — het is bewuste beperking. Door de scope agressief te beperken, wordt pgs.sh ongelooflijk betrouwbaar in zijn ene taak. Geen feature matrix om te navigeren, geen prijsstructuren om te ontcijferen, geen enterprise plan om te verkopen.

Voor startups die snel bewegen en developers die gewoon willen shippen, is die helderheid enorm waardevol.

Waar eenvoudige deploys passen in je stack

Laten we realistisch zijn: één-commando rsync deploys zijn niet voor elk project de juiste oplossing. Complexe applicaties met backend API's, databases en dynamische routing hebben geavanceerdere infrastructuur nodig. Daar verdienen cloudplatformen, container orchestration en volledige CI/CD pipelines hun plek.

Maar voor de ontelbare static sites, landingspagina's, documentatie en side projects die het web vormen? Dan wint de eenvoudige aanpak.

En eerlijk? Zelfs voor grotere projecten is er iets te zeggen voor een zo simpel mogelijke static asset deployment, terwijl je complexiteit reserveert voor waar het echte waarde toevoegt.

Afsluitend

De beste tools voelen achteraf vaak onvermijdelijk. Natuurlijk zou deployen zo simpel moeten zijn. Natuurlijk zou je geen DevOps PhD nodig moeten hebben om een website te publiceren.

pgs.sh herinnert ons eraan dat de tools die we dagelijks gebruiken dezelfde doordachte design verdienen als de producten die we bouwen. Soms is de meest indrukwekkende engineeringprestatie weten wat je niet moet bouwen.

Als je nog niet hebt gespeeld met friction-free deployment tools, is dit het perfecte moment om te verkennen. Je toekomstige zelf — en je gebruikers — zullen je dankbaar zijn.

Wat is jouw deployment filosofie? Houd je van complexe pipelines of omarm je eenvoud? Laat een reactie achter — we horen graag hoe jij code shippt.