Hands Use cases Apps Insights Pricing Handbook Sign in
NL
Get started with Hands
Build with fewer moving parts

What do you really need to host a website?

You need to own a domain. After that, a surprising number of websites only need two core building blocks: GitHub for the source and Cloudflare for publishing it. Add Firecrawl, Resend or Supabase only when your site has a real reason to need them.

Guide Β· 8 min

A Hand can write pages, reorganize content, fix styling and keep making changes later. The important part is not giving it the biggest possible technical stack. It is giving it a small set of systems with clear jobs, so the website has somewhere stable to live and a predictable path from a change to a published result.

Start smaller than you think

For a brochure site, portfolio, landing page or simple company website, a domain plus GitHub and Cloudflare can already be enough. Do not add a database, CMS or extra service just because you might need one someday.

The minimum stack: domain + GitHub + Cloudflare

The one thing Hands cannot remove from the equation is ownership of your domain. You need a domain you control. Once you have that, split the rest into two simple responsibilities.

GitHub keeps the source.

Your pages, styles, assets and change history live in a repository. Your Hand can read that repository and, within its reviewed-action settings, create branches, create or update files and work through pull requests.

Cloudflare gets it online.

Your Hand can work with bounded Cloudflare actions for Pages, DNS, Workers and related website infrastructure. That gives the code a publication path and the domain a place to point.

With those roles separated, a later request can be about the result instead of the plumbing:

Once the foundation is in place

β€œAdd a page for enterprise customers, update the navigation and publish the new version.”

The exact execution still depends on the repository, the Cloudflare account and the connector permissions you give that Hand. The useful part is that the website no longer lives as a one-off export on somebody's laptop. It has a source of truth and a repeatable deployment path.

Already have a website? Use the public site as source material.

If you are replacing an existing public website, you do not always need to start from a blank page. Firecrawl can search, scrape and map public pages. When the Firecrawl preview is available for your Hands account, that can give your Hand useful source material before rebuilding the site in GitHub.

A sensible migration brief

β€œMap the public pages on our current site, preserve the useful copy and information architecture, then rebuild a cleaner static version in the new GitHub repository.”

That is not the same thing as an automatic migration. A public crawl cannot magically reproduce private databases, logged-in areas, form processing, checkout logic, server configuration, redirects or every third-party integration behind the old site. Treat scraping as a way to recover public content and structure, then deliberately rebuild what the new site actually needs.

Firecrawl is optional

The Hands Firecrawl connection is currently a bounded preview. General availability can differ by account. If it is not available, export or provide the existing content another way; GitHub + Cloudflare remain the core website setup.

Need a form to send you an email? Add Resend, not a whole backend.

A static website stops being completely static when a visitor needs to submit something. A contact form is a good example. The browser should not contain a secret mail API key, so the clean pattern is a small server-side endpoint β€” for example a Cloudflare Worker or Function β€” that validates the submission and asks Resend to send the email.

01⌨FormThe visitor submits ordinary form data only.
02Cloudflare FunctionValidates it server-side. No mail secret in the browser.
03ResendSends the email through the protected server route.
04βœ‰InboxThe request arrives where you want it.

The Resend connection can send transactional email and can also manage account resources such as domains, templates, contacts and webhooks, subject to the approval settings on the Hand. You still want the website to send through a server-side function rather than expose credentials in client-side code.

If all you need is β€œsend this contact request to [email protected],” that is still a small website. You have added one narrow capability, not committed yourself to a large application architecture.

Only add Supabase when the website actually needs to remember things.

Many websites do not need a database. If all content lives in the repository and every asset ships with the site, GitHub and Cloudflare may remain enough for years.

Supabase becomes useful when your site turns into an application: persistent records, user accounts, dynamic content, application logic or larger external storage can justify a separate data layer. The current Hands Supabase connection can find projects, run SQL and manage project lifecycle and Edge Functions. Your website can also be designed to use Supabase services where appropriate, but do not assume every Supabase administration surface is exposed as a Hands action.

  • Six product images? Keep them with the site unless there is a real operational reason not to.
  • Hundreds of customer uploads? External object storage starts to make sense.
  • Profiles, submissions or structured records? A database starts to make sense.
  • Users signing in? You now have an application architecture to design, not just a static website.

A practical setup order

  1. Buy or choose the domain you want to use. Keep ownership and billing under your control.
  2. Create a GitHub repository for the site. Make it the durable source of truth instead of a folder somebody periodically uploads.
  3. Connect GitHub to the Hand that will maintain the website. Give it only the repository authority and review behavior you are comfortable with.
  4. Create or connect the relevant Cloudflare setup. Pages and DNS are the typical foundation; Workers become useful when the site needs server-side behavior.
  5. Build the smallest working version and publish it. Make sure edits can move from GitHub to the live site reliably.
  6. Add one extra service only when a concrete requirement appears. Firecrawl for public migration input, Resend for email, Supabase for persistent application data.
The stack should grow with the request

Do not build an architecture for hypothetical future features. A simple site should stay simple. Your Hand can extend the stack later when the next real requirement arrives.

What each connection is actually for

Keeping the roles explicit makes the whole setup easier to reason about:

GitHubSource code, file changes, branches and pull requests through bounded repository actions.
CloudflarePages, DNS, Workers and selected infrastructure through bounded provider actions.
FirecrawlOptional public-web reading and bounded crawling when the preview is available.
ResendEmail delivery and related mail account resources; use server-side handling for website forms.
SupabaseOptional project/database layer for sites that have become real applications.

The goal is not more connectors. It is a website with a clear home.

The useful end state is boring in the best possible way: your domain points to a site that can be rebuilt from GitHub, Cloudflare knows how to serve it, and every extra service exists because one specific requirement justified it. That gives your Hand a stable environment it can come back to next week, next month or after ten more changes.

Start with the two connections that give your website a source and a way online.

Connect GitHub and Cloudflare to the Hand that will maintain the site. Add the rest only when the work calls for it.

← Back to all Insights