Webstead
Sign inCreate account

Deploying from GitHub

Connecting a repository

From Sites → Create site → Deploy from GitHub, you can either connect your GitHub account (recommended — it unlocks a repository picker and private repos) or paste any public owner/repo directly without connecting anything.

Once connected, pick a repository and branch. Branches load live as soon as you choose a repo.

Framework detection

We read your package.json and lockfile and propose build settings automatically:

Your projectBuild outputConfidence
Astrodist/High
Vitedist/High
Create React Appbuild/High
Next.js static exportout/Medium — see note below
Custom build scriptdist/ (adjustable)Low
No package.jsonserved as-is

You can override any of these under Advanced build settings before your first deploy. Your package manager (npm, pnpm, yarn, or bun) is detected from whichever lockfile is committed to the repo.

If the configured output folder turns out to be missing or empty after a build, we automatically look for common alternatives (dist, build, out, public, _site, and a few others) and use whichever one actually contains an index.html — so a mismatched setting doesn't have to mean a broken deploy.

Auto-deploy on push

Once your first deploy succeeds, you can turn on auto-deploy for that site. We register a webhook on the repository, and every push to your chosen branch triggers a fresh build and publish automatically — no need to come back and click deploy again.

Environment variables

Add build-time environment variables on the site's Environment tab. They're encrypted at rest and injected only during the build step. Because asset canisters serve static files with no server process, these variables can't be read at request time — anything your app needs at runtime has to be baked in at build time (this is the same constraint any static host has).

Important: this is static hosting

Webstead publishes to an asset canister — there is no Node.js server behind your site. That means:

  • Next.js must use static export. Set output: "export" in next.config.js and avoid server-only features (API routes, getServerSideProps, ISR, middleware). A build can succeed and still not work at runtime if it relies on a server — we show a warning on the create form when we detect Next.js, precisely because this is easy to miss.
  • Frameworks that assume a persistent server process (Express, Nest, Nuxt SSR, SvelteKit's Node adapter) aren't supported. If your app has a genuinely static or client-rendered build mode, use that instead.

When a build fails

Every failed deploy has a "Diagnose this failure" button that sends the build log to an AI assistant for a plain-language explanation and suggested fix. It's optional and doesn't store anything — click it only if you want the extra help.

Common causes we already detect and explain clearly in the log:

  • The build ran out of memory or timed out (rather than a bare "Command failed").
  • The output directory didn't match what the build actually produced (auto-recovered where possible, as above).
  • The framework needs a server we don't provide (see the static-hosting note above).

Still stuck? Contact us with your site name and we'll take a look.