Hands
EN
Inloggen Start met Hands
Bouw met zo min mogelijk bewegende delen

Wat heb je écht nodig om een website te hosten?

Een domein moet je zelf bezitten. Daarna hebben verrassend veel websites maar twee echte bouwstenen nodig: GitHub voor de bron en Cloudflare om te publiceren. Firecrawl en Supabase zijn ook als MCP-koppeling beschikbaar wanneer de site ze echt nodig heeft. E-mailbezorging is een aparte architectuurkeuze. In deze stack gebruiken we Resend als concreet mailvoorbeeld, los van de manier waarop die dienst op dat moment aan Hands wordt gekoppeld.

Gids · 8 min

Een Hand kan pagina’s schrijven, content opnieuw ordenen, styling aanpassen en later gewoon verder werken. Het belangrijkste is niet dat je hem de grootst mogelijke technische stack geeft. Het gaat erom dat je een paar systemen met duidelijke rollen neerzet, zodat de website een vaste plek heeft en er een voorspelbare route bestaat van wijziging naar publicatie.

Begin kleiner dan je denkt

Voor een bedrijfswebsite, portfolio, landingspagina of eenvoudige informatiesite kan een domein met GitHub en Cloudflare al genoeg zijn. Voeg geen database, CMS of extra dienst toe alleen omdat je die ooit misschien nodig hebt.

De minimale stack: domein + GitHub + Cloudflare

Het enige wat Hands niet uit de vergelijking kan halen is eigenaarschap van je domein. Je hebt een domein nodig waar jij controle over hebt. Daarna kun je de rest opdelen in twee simpele verantwoordelijkheden.

GitHub bewaart de bron.

Je pagina’s, stijlen, assets en wijzigingsgeschiedenis leven in een repository. De GitHub MCP-koppeling biedt tools om je repository te lezen. Of je Hand bestanden kan wijzigen, hangt af van de server en de rechten van je GitHub-token.

Cloudflare levert de webinfrastructuur.

De MCP-koppeling gebruikt een Cloudflare API-token met beperkte rechten. Welke deploy-, DNS-, Workers- of andere Cloudflare-tools werkelijk worden aangeboden, hangt af van de provider-MCP-server en die token en niet van een vaste Hands-actielijst.

Als die rollen eenmaal helder zijn, kan een later verzoek weer gewoon over het resultaat gaan:

Als de basis eenmaal staat

“Voeg een pagina voor zakelijke klanten toe, werk de navigatie bij en publiceer de nieuwe versie.”

De precieze uitvoering hangt af van de repository, het Cloudflare-account, de remote MCP-tools die iedere provider aanbiedt en de credentials die je koppelt. Het nuttige is dat je website niet langer een eenmalige export op iemands laptop is. Hij heeft een bron van waarheid en een herhaalbaar publicatiepad.

Heb je al een website? Gebruik de publieke site als bronmateriaal.

Als je een bestaande publieke website wilt vervangen, hoef je niet altijd vanaf een leeg scherm te beginnen. Firecrawl is beschikbaar in de MCP-catalogus. De huidige koppeling ondersteunt de beschreven tools voor zoeken, scrapen en mappen. Met een Firecrawl API-sleutel kan dat je Hand nuttig openbaar bronmateriaal geven voordat de nieuwe site in GitHub wordt opgebouwd.

Een verstandig migratieverzoek

“Breng de publieke pagina’s van onze huidige site in kaart, behoud de nuttige teksten en informatiestructuur en bouw daarna een schonere statische versie in de nieuwe GitHub-repository.”

Dat is niet hetzelfde als een automatische migratie. Een publieke crawl kan geen privé-databases, ingelogde delen, formulierverwerking, checkoutlogica, serverconfiguratie, redirects of iedere externe integratie achter de oude site zomaar terugbouwen. Zie scrapen als een manier om publieke content en structuur terug te halen en bouw daarna bewust opnieuw wat de nieuwe site echt nodig heeft.

Firecrawl is optioneel

Gebruik het wanneer openbaar bronmateriaal echt werk bespaart. De koppeling gebruikt een API-sleutel en beschrijft zoeken, scrapen en mappen; je Firecrawl-abonnement en credits blijven gelden. GitHub + Cloudflare blijven de kern van de website-opzet.

Moet een formulier een e-mail versturen? Voeg een maildienst toe, geen complete backend.

Een statische website wordt net iets minder statisch zodra een bezoeker iets moet insturen. Een contactformulier is een goed voorbeeld. Een geheime mail-API-sleutel hoort niet in de browser, dus een nette opzet gebruikt een kleine server-side endpoint — bijvoorbeeld een Cloudflare Worker of Function — die de invoer controleert en Resend vraagt de e-mail te versturen.

01⌨FormulierDe bezoeker vult alleen gewone formulierdata in.
02Cloudflare FunctionControleert de invoer server-side. Geen mail-secret in de browser.
03ResendVerstuurt de e-mail via de beschermde serverroute.
04✉MailboxDe aanvraag komt aan waar jij hem wilt hebben.

Resend is hier de transactionele mailprovider. De architectuur blijft hetzelfde ongeacht de actuele Hands-koppelroute: het formulier stuurt naar een server-side Function of Worker, die Resend aanroept zonder mailcredentials in de browser te plaatsen. Welke Hands-App, Plug-in- of Connectorroute voor Resend beschikbaar is, kan veranderen zonder dat je deze websitearchitectuur hoeft te herschrijven.

Als je enige extra wens is “stuur deze contactaanvraag naar sales@example.com”, dan is dit nog steeds een kleine website. Je hebt één smalle functie toegevoegd, geen groot applicatieplatform.

Voeg Supabase pas toe wanneer de website echt iets moet onthouden.

Veel websites hebben helemaal geen database nodig. Als alle content in de repository staat en de assets met de site meekomen, kunnen GitHub en Cloudflare jarenlang genoeg blijven.

Supabase wordt interessant wanneer je site een applicatie wordt: blijvende records, gebruikersaccounts, dynamische content, applicatielogica of grotere externe opslag kunnen een aparte datalaag rechtvaardigen. Supabase is beschikbaar in de MCP-catalogus en de koppeling gebruikt een personal access token met beperkte rechten. Welke project- of databasetools werkelijk beschikbaar zijn, hangt af van de provider-MCP-server en die token; ga er dus niet vanuit dat elk Supabase-beheerscherm wordt aangeboden.

  • Zes productafbeeldingen? Houd ze gewoon bij de site, tenzij er een echte operationele reden is om dat niet te doen.
  • Honderden uploads van klanten? Externe objectopslag begint dan logisch te worden.
  • Profielen, inzendingen of gestructureerde records? Dan wordt een database logisch.
  • Gebruikers die inloggen? Dan ontwerp je inmiddels een applicatie-architectuur en niet alleen een statische website.

Een praktische volgorde

  1. Koop of kies het domein dat je wilt gebruiken. Houd eigenaarschap en facturatie onder je eigen controle.
  2. Maak een GitHub-repository voor de site. Maak die de duurzame bron van waarheid in plaats van een map die iemand af en toe uploadt.
  3. Koppel GitHub aan de Hand die de website gaat onderhouden. Gebruik een providertoken met alleen de repositoryrechten die de opdracht nodig heeft en bekijk welke MCP-tools die verbinding echt aanbiedt.
  4. Maak of koppel de relevante Cloudflare-opzet. Configureer het publicatiepad dat je wilt en gebruik daarna een afgebakende Cloudflare API-token voor de MCP-koppeling.
  5. Bouw de kleinste werkende versie en publiceer hem. Controleer dat wijzigingen betrouwbaar van GitHub naar de live site kunnen via de tooling die je werkelijk hebt ingericht.
  6. Voeg pas een extra dienst toe als er een concrete eis verschijnt. Firecrawl voor publieke migratie-input, een mailprovider zoals Resend voor e-mail of Supabase voor blijvende applicatiedata.
Laat de stack meegroeien met de opdracht

Bouw geen architectuur voor hypothetische toekomstige functies. Een simpele site moet simpel blijven. Je Hand kan de stack later uitbreiden zodra een volgende echte eis zich aandient.

Waar elke koppeling echt voor is

Als je de rollen expliciet houdt, blijft de hele opzet makkelijker te begrijpen:

GitHubMCP-koppeling beschikbaar in Hands. Repositorytools en rechten hangen af van de server en je GitHub-token.
CloudflareMCP-koppeling beschikbaar in Hands. Infrastructuurtools hangen af van de server en de rechten van je API-token.
FirecrawlMCP-koppeling voor de beschreven tools om het openbare web te doorzoeken, te scrapen en te mappen.
ResendMailprovider voor formulieren en transactionele e-mail. Gebruik Resend server-side; de actuele Hands-koppelroute kan veranderen zonder dat de websitearchitectuur verandert.
SupabaseMCP-koppeling voor een optionele datalaag. Tools hangen af van de server en de rechten van je personal access token.

Het doel is niet meer connectors. Het doel is een website met een duidelijke thuisbasis.

De nuttige eindtoestand is heerlijk saai: je domein wijst naar een site die uit GitHub opnieuw opgebouwd kan worden, Cloudflare weet hoe hij hem moet serveren en iedere extra dienst bestaat omdat één concrete eis hem rechtvaardigde. Daarmee geef je je Hand een stabiele omgeving waar hij volgende week, volgende maand of na tien wijzigingen gewoon weer op kan voortbouwen.

Begin met de twee koppelingen die je website een bron en een weg naar buiten geven.

Koppel GitHub en Cloudflare aan de Hand die de site gaat onderhouden. Voeg de rest pas toe wanneer het werk daarom vraagt.

← Terug naar alle Insights