Een browser-IDE-project deployen naar Vercel of Netlify

Het duidelijkste geval is een machine waarop een CLI installeren lastig of verboden is. Een Chromebook, een labcomputer of een vergrendelde zakelijke desktop kan een browsertab openen, maar niet altijd Node.js, Git en een provider-CLI installeren. Een browser-IDE haalt die eisen al weg voor het bewerken. Deployment is meestal de laatste stap die de ontwikkelaar terug naar een terminal stuurt; die in hetzelfde tabblad houden sluit de cirkel: het project wordt bewerkt, bekeken en gepubliceerd zonder lokale toolchain. Het tweede geval is snelheid. Een landingspagina, prototype of klantdemo heeft soms een URL nodig voordat er een repository of CI-pipeline is. Het browserpaneel publiceert de huidige snapshot en vertelt waar die live staat. Dat gemak heeft een grens. Dit is een directe upload, geen deploymentpipeline. Het volgt geen branch, draait geen tests en promoot geen builds tussen omgevingen; dat hoort bij Git-integratie of CI. De browserroute is voor de eerste URL, niet voor het hele releaseproces.

De Deploy-dialoog is een dunne bedieningslaag boven twee provider-API's. Zodra je op Deploy now drukt, bouwt GB Coder dezelfde bestandsbundel als Download ZIP. Dat detail is belangrijk: er is geen tweede verpakkingsroute die stiekem een stylesheet kan weglaten of een externe bibliotheek kan vergeten. Een eenvoudig project wordt index.html, style.css, script.js en een README. Een React- of Vue-project wordt een Vite-structuur met index.html, package.json, vite.config.js, .gitignore, een README en bronbestanden onder src/. De samenvatting toont het exacte aantal bestanden en de ongecomprimeerde grootte voordat er iets het tabblad verlaat. Vercel ontvangt de bestanden als inline JSON op zijn deployment-endpoint. Netlify ontvangt een ZIP als raw request body. Vercel bouwt of serveert het project; Netlify publiceert de geüploade bestanden als handmatige deployment. Er zit geen LadeStack-server tussen en er draait geen CLI op je machine. De browser is de client, de provider de host en het token de enige credential. One-click beschrijft de interface, niet het werk: verpakken, uploaden, remote verwerking en TLS gebeuren nog steeds na elkaar.

De bundel verschilt omdat de twee projecttypen anders behandeld moeten worden. Een gewoon HTML/CSS/JavaScript-project heeft geen package.json. Vercel krijgt de opdracht geen framework te gebruiken en serveert de bestanden statisch. Netlify publiceert de ZIP ongewijzigd, wat voor statische bestanden ook klopt. Er valt niets te installeren of compileren, dus de eerste deployment is meestal snel. Een React- of Vue-project bevat een gegenereerde package.json, een Vite-config en bronbestanden. Op Vercel herkent de provider Vite, installeert de dependencies, draait de productiebuild en publiceert de output. Dat is een echte cloudbuild, geen simulatie in de browser, en daarom kan het een minuut of langer duren. Vercel gebruikt ook de versies uit package.json, niet wat toevallig in de editor geladen was. De handmatige ZIP-deployment van Netlify voert geen build-commando uit, dus dezelfde Vite-bronboom wordt geüpload en ongecompileerd gepubliceerd. Gebruik voor React of Vue op Netlify de Git-integratie van de provider; de one-clickoptie van Netlify publiceert alleen statische output. Externe bibliotheken en injectie-instellingen zitten al in de bundel. Als een Vercel-build afhankelijk is van een privépakket, een native binary of een dienst die de build-image niet kan bereiken, mislukt de build terwijl de preview lokaal werkt. De logs laten zien welk geval je hebt.

Beide providers authenticeren met een personal access token. Dat is niet je providerwachtwoord en geen GB Coder-account. De dialoog linkt naar de tokenpagina van de gekozen provider en legt de scope in gewone taal uit. Een Vercel-token kan publiceren naar elk project dat het account of team kan bereiken; gebruik waar mogelijk een team-scoped token. Een Netlify-token werkt op de sites waartoe het account toegang heeft, dus behandel het als accountbreed tenzij er een nauwere optie is. Maak het token voor dit doel, geef het de kortst nuttige levensduur en trek het in wanneer het project het niet meer nodig heeft. GB Coder controleert of er een token is en of de bundel binnen de lokale limieten past voordat Deploy now actief wordt. Het token staat standaard alleen in het geheugen van het tabblad. Remember on this device is een opt-in: op een secure origin wordt het token met AES-GCM verzegeld voordat het naar localStorage gaat; anders waarschuwt de dialoog dat onthouden het als platte tekst opslaat. Scope en intrekken zijn de belangrijkste controles.

Open een project en kies Deploy in de werkbalk; op een smal scherm zit het in het overflowmenu. Vercel is standaard geselecteerd; Netlify is één klik weg. De projectnaam wordt vooraf ingevuld. GB Coder zet die om naar kleine letters, vervangt ongeldige tekens door koppeltekens en toont de hostname die het gaat aanvragen, bijvoorbeeld jouw-project.vercel.app. Plak het token, beslis of je het wilt onthouden en controleer de bundelsamenvatting. Als het aantal bestanden of de grootte boven de limiet zit, legt de dialoog het probleem uit en blijft de knop uitgeschakeld. Druk op Deploy now. De provider maakt het project of de site aan, ontvangt de bundel en begint de deployment te verwerken. Als de deployment klaar is, toont het succescherm de live-URL, het aantal bestanden, de uploadgrootte, de verstreken tijd en een QR-code om de pagina op een telefoon te openen. Copy URL en Visit site helpen bij de overdracht, en Build logs opent de logweergave van de provider. Netlify-sitenamen zijn wereldwijd uniek, dus een gevraagde naam kan al bezet zijn. De provider wijst dan een andere naam toe en GB Coder meldt het adres dat echt live staat, niet wat je typte.

De voortgangsbalk gaat door verpakken, uploaden, bouwen, beveiligen en klaar. Bij Netlify staat het bouwlabel voor verwerking door de provider, niet voor een build-commando. Het is een rapport van de client, geen voorspelling van de provider. Het percentage loopt snel door de eerste twee fasen en blijft onder 100 staan terwijl de provider het werk op afstand afrondt. Dat is bewust: werk op afstand kan onvoorspelbaar lang duren en een balk die naar 99 procent racet, zou liegen. GB Coder pollt de provider elke anderhalve seconde en werkt het bericht bij wanneer de status verandert. Een uploadrequest heeft een timeout van twee minuten. Het paneel stopt na drie minuten deployment-polling met wachten en verwijst naar het dashboard, omdat de deployment kan afronden terwijl de browser niet meer kijkt. Annuleren, de dialoog sluiten of Escape indrukken breekt het lopende request en de pollinglus af. Als de provider de deployment al heeft geaccepteerd, kan de deployment aan zijn kant doorgaan; controleer het dashboard voordat je aanneemt dat annuleren een rollback was. De logs van de provider zijn de autoritatieve bron wanneer een deployment mislukt.

Deploy again gaat terug naar het formulier; het verstuurt de laatste bundel niet meteen opnieuw. Dat is handig wanneer het project is veranderd, de naam aangepast moet worden of het token is verlopen. Vercel en Netlify nemen daarna verschillende routes naar hetzelfde adres. Vercel maakt een deployment voor het genoemde project en richt zich op productie. Herhaalde deployments met dezelfde projectnaam werken dat project bij, en de productie-alias gaat voor op de deployment-specifieke URL, zodat het adres dat je deelt meestal stabiel blijft. Netlify heeft een site-id nodig om een bestaande site bij te werken in plaats van een nieuwe te maken. GB Coder bewaart die id in localStorage, gekoppeld aan de opgeschoonde sitenaam. Als je browseropslag wist, van browser wisselt, de naam wijzigt of de site in Netlify verwijdert, vindt de volgende deployment de oude site niet en maakt een nieuwe aan. Daarom kan het hernoemen van een Netlify-project de vorige site achterlaten. Beide providers bewaren deploymentgeschiedenis, custom domains, toegangscontrole en rollback in hun dashboards; het GB Coder-paneel toont alleen de upload en de live-URL. Elke deployment hier is een productiedeployment; er is geen branchpreview of omgevingskeuze.

Er gelden twee limieten voordat het request het tabblad verlaat: 900 bestanden en 64 MB ongecomprimeerde inhoud. Ze liggen onder de plafonds van de providers, zodat een enorme upload niet halverwege een browsersessie mislukt. Een mediarijke site kan grote afbeeldingen en video beter op een CDN of in Git houden dan in de projectbundel. Fouten zijn per oorzaak gescheiden. Een 401 betekent dat het token is geweigerd; een 403 wijst meestal op ontbrekende rechten voor het account of team; een 413 of 429 betekent dat de payload te groot is of dat de provider de snelheid beperkt; een 422 betekent dat het project als ongeldig is afgewezen; een 5xx is meestal tijdelijk. Op Vercel is een mislukte frameworkbuild anders: de upload slaagde en de build faalde, dus lees de logs in plaats van een nieuw token te plakken. Een Vercel-build die omgevingsvariabelen nodig heeft, is een andere grens. De dialoog heeft geen editor daarvoor. Stel de waarden in de projectinstellingen van Vercel in en deploy opnieuw; de eerste build kan mislukken voordat het project bestaat. De handmatige ZIP-route van Netlify heeft geen buildstap, dus daar geldt dit niet. Een poll-limiet van drie minuten is geen mislukte deployment, alleen een mislukte wachttijd.

De deploymentroute is direct: de browser roept api.vercel.com of api.netlify.com aan met je token. Er is geen proxy die de credential opslaat en er is geen LadeStack-account nodig voor het paneel. Tokens zijn standaard sessiegebonden en worden alleen met AES-GCM verzegeld als je ervoor kiest er een te onthouden op een secure origin. Dat beschermt tegen een leesbaar token in een browserprofielback-up of supportbundel, maar niet tegen kwaadaardige code op dezelfde origin terwijl het tabblad open is. Gebruik het nauwste token dat beschikbaar is, stel een vervaldatum in en trek het bij de provider in als het werk klaar is. Eigendom volgt het token: het project of de site wordt aangemaakt in het provideraccount dat eigenaar is, onder de voorwaarden, quota, logs en facturering van die provider. GB Coder blijft local-first, maar deployen is een expliciete export van het project naar de provider. De provider ontvangt de bron van de site, en het resultaat is standaard een openbare HTTPS-URL; wachtwoordbeveiliging, SSO en custom domains zijn providerfuncties. Bewaar een ZIP of GitHub-kopie als het browserprofiel de enige andere plek is waar het project bestaat.

Gebruik deze route om een kleine site snel online te zetten: een landingspagina, portfolio, klassendemo, prototype voor klantreview of statische documentatiepagina. Het past ook wanneer het project al in GB Coder staat en het alternatief een ZIP exporteren, een terminal openen en een CLI configureren op een machine die niet van jou is. Het past slecht bij een monorepo, een server-rendered applicatie met database, een build met private registry-referenties, een team dat releases via branchpreviews en approvals doet, of assets boven de uploadlimieten. Dat zijn taken voor Git-integratie, een CI-pipeline of een desktopomgeving. De twee benaderingen kunnen samenwerken: ontwerp en itereer in de browser, push de bron naar GitHub wanneer het historie verdient en laat CI de productiebuild publiceren. Een praktische routine: test de preview op telefoonbreedte, controleer de bundelsamenvatting, deploy, open de live-URL op een tweede apparaat en bewaar de buildlog. Om het te proberen open je het Projectendashboard op /app/projects, maak of open je een project en kies Deploy. De configuratiereferentie staat in de documentatie.