Skip to main content
Webentor Studio

Help · Hosting

Where your site is published

Every project is live on the server this Studio runs on from the moment it exists, with no account or credential to set up. Add your own hosting beside it, and every publish sends the same finished site to each destination.

Sign inHow it worksGetting started
All 12 topics on this page

Start here

How it works

Hosting is set up per project. Adding a destination never moves your site; it sends it to one more place.

  1. Open a project’s Settings → Hosting. The server this Studio runs on is already there.
  2. Add a destination and paste its credential. It is stored encrypted and never shown again, and saving one asks you to confirm who you are.
  3. Publish as usual. The same build goes to every destination, and the project’s Publishing tab shows each one as Current once it serves the new build.

Images and files on another host

Once a destination is not this server, the build guard every new project runs stops a publish whose pages still point at /wn/image or /wn/file. Only this server answers those addresses, so the images on those pages would 404 on the other host. The build log names each page.

Choosing

Cloudflare or Cloudflare Pages?

These are two different Cloudflare products, and the difference decides whether your redirects and security headers work.

Cloudflare Pages

Pick this one

Applies the _headers and _redirects files your build writes: the Redirects screen works, and so does your content-security policy.

Token: Cloudflare Pages: Edit

Cloudflare (Workers Static Assets)

Ignores both files. The direct-upload API drops them without an error or a warning, and the site goes out with no redirects and no headers.

Token: Workers Scripts: Edit

Pick Pages unless you want a Worker. A token for one does not work on the other.

Vercel has the same gap, for another reason

It reads vercel.json, which a Webentor build does not write, so _headers and _redirects do nothing there either. Netlify, Cloudflare Pages and the built-in server all honour them.

Included, nothing to set up

The built-in server

The server this Studio is running on. Every project publishes here from the moment it exists, with no account or credential to set up.

Best for: Everything, until you have a reason otherwise. It is the address the dashboard links to and the one previews are built against.

Setting it up

  1. Nothing. It is created with the project and cannot be removed.
  2. Point a custom domain at this server when you want one. The DNS goes to the machine running this Studio, not to a third party, and the certificate is issued once the DNS checks out.

Your own account

Cloudflare Pages

Cloudflare Pages is a different Cloudflare product from Cloudflare Workers. Pages applies the _headers and _redirects files your build emits; Workers drops them without an error.

Best for: Almost anyone on Cloudflare. Pick this over Workers unless you want a Worker.

Before you start

  • A Cloudflare account ID (Workers & Pages → Account details)
  • An API token with Cloudflare Pages: Edit
  • The Pages project name, if it is not your project’s short name

Setting it up

  1. In Cloudflare, open Workers & Pages → Account details and copy the Account ID.
  2. Make an API token (My Profile → API Tokens → Create Token) with the Cloudflare Pages: Edit permission. A Workers token will not work here, and the other way round.
  3. Add the destination. Leave the Pages project empty to use your project’s short name; it is created on the first publish.
  4. If the site is already on Pages, set the Pages project to that exact name. Getting it wrong creates a second project and your domain stays on the first one.
  5. Publish. The site appears at <project>.pages.dev, redirects and headers included.

Your own account

Netlify

Netlify: the built files are uploaded to a site in your own Netlify account. _headers and _redirects are honoured.

Best for: Anyone already on Netlify, or who wants their form and edge features.

Before you start

  • The Site ID (Site configuration → Site information)
  • A personal access token (User settings → Applications → Personal access tokens)

Setting it up

  1. Create the site in Netlify first: an empty one, with no repository connected.
  2. Copy its Site ID from Site configuration → Site information.
  3. Make a personal access token under User settings → Applications.
  4. Add the destination here with both values.
  5. Publish. Netlify prepares the deploy and flips it live in one step.
  6. Add your domain in Netlify under Domain management, then point DNS at them.

Worth knowing

  • Netlify allows 3 deploys per minute and 100 per day. A rate-limited publish is retried rather than failed, and what was already uploaded is kept.

Your own account

Vercel

Vercel: the built files are uploaded to a project in your own Vercel account and served from their edge.

Best for: Anyone already on Vercel, or who wants their preview-per-publish workflow.

Before you start

  • The project name (or prj_… ID)
  • A token from Account Settings → Tokens
  • The Team ID, if the project belongs to a team rather than to you

Setting it up

  1. Create the project in Vercel first: an empty one, with no Git repository connected.
  2. Copy its name from the project’s Settings → General (or the prj_… ID from the same page).
  3. If it belongs to a team, copy the Team ID from Team Settings → General.
  4. Make a token under Account Settings → Tokens, scoped to that team if there is one.
  5. Add the destination here. Leave the environment on Production unless you want a throwaway URL.
  6. Publish. Vercel builds nothing, because the site is already built, and assigns your domains when it is ready.
  7. Attach a custom domain from this screen, then point DNS at Vercel: a CNAME to cname.vercel-dns.com for a subdomain, their A record for an apex.

Worth knowing

  • _headers and _redirects are ignored; those are Netlify and Cloudflare Pages conventions. Vercel reads vercel.json, which a Webentor build does not write, so the Redirects screen and a build-time CSP do nothing here.
  • Choosing the Preview environment publishes to a throwaway URL and leaves your live site alone. That is useful on purpose, and it is not what most people want as their only destination.

Your own account

GitHub Pages

GitHub Pages: the built site is committed to a branch of one of your repositories, and GitHub serves it from there.

Best for: A site whose history you want in Git, or a free host you already have an account for.

Before you start

  • A repository, as owner/repo
  • A fine-grained token with Contents: write and Pages: write on it

Setting it up

  1. Create (or pick) the repository the site will live in. It may be the same one your project mirrors to, or a separate one.
  2. Make a fine-grained personal access token: GitHub → Settings → Developer settings → Fine-grained tokens. Give it Contents: write and Pages: write, on that repository only.
  3. Add the destination here with owner/repo and the token. The branch defaults to gh-pages.
  4. In the repository’s Settings → Pages, set the source to “Deploy from a branch” and choose that branch.
  5. Publish. The branch is replaced with the built site and GitHub rebuilds.
  6. Attach a custom domain from this screen. It writes the CNAME file and turns on HTTPS enforcement once the certificate exists.

Worth knowing

  • GitHub rebuilds after each push, so the new version appears a minute or two after the publish reports success rather than instantly.
  • The site is committed over the Git Data API, which this platform bounds at a file count. A very large site is refused with the number in the message. Use Cloudflare Pages or Netlify for one of those.

Your own account

Cloudflare (Workers Static Assets)

Cloudflare Workers Static Assets: the files are uploaded straight to a Worker on your own Cloudflare account and served from their edge.

Best for: A site with no redirects and no custom headers, where you want the Workers platform rather than Pages.

Before you start

  • A Cloudflare account ID (Workers & Pages → Account details)
  • An API token with Workers Scripts: Edit

Setting it up

  1. In Cloudflare, open Workers & Pages → Account details and copy the Account ID.
  2. Make an API token (My Profile → API Tokens → Create Token) with the Workers Scripts: Edit permission.
  3. Add the destination here with both values. The Worker is named after your project’s short name unless you set another.
  4. Publish. The first publish creates the Worker and reports its <project>.<subdomain>.workers.dev address.
  5. Attach a custom domain from this screen, or in Cloudflare under the Worker’s Settings → Domains & Routes.

Worth knowing

  • _headers and _redirects are ignored. The direct-upload API drops both without an error, so the Redirects screen and a build-time CSP do nothing on this provider. That is why Cloudflare Pages is offered separately.

Your own account

S3-compatible storage

Any S3-compatible bucket: AWS, Cloudflare R2, Backblaze B2, Hetzner, Scaleway, MinIO, DigitalOcean Spaces. We write the files; you bring the CDN in front of them.

Best for: Storage you already pay for, or a host nobody else on this list covers.

Before you start

  • A bucket, and its region or endpoint
  • An access key ID and secret access key that may write to it
  • The public URL the bucket is served from, if it is behind a CDN

Setting it up

  1. Create the bucket and make it readable by the public, or put a CDN in front of it.
  2. Create an access key that may write to that bucket and nothing else.
  3. Add the destination here with the bucket, region, endpoint and the key pair.
  4. Set the public URL so the build knows the site’s canonical address.
  5. Publish. New files go up, entry documents are written last, and files no longer in the site are removed.

Worth knowing

  • Object storage has no atomic swap. Files go up one at a time and a visitor can catch a half-updated site during a publish. Every other destination on this list replaces the site in one step.

A server you run

A Node server you run

A plain Node server on a machine you control, serving the built files from a directory with atomic releases and a rollback.

Best for: A box you already own, or a site that must not leave your network.

Before you start

  • A directory the server may write to
  • A free port

Setting it up

  1. Set the hosting root, the directory releases are written into.
  2. Set the public URL so the build knows its own canonical address.
  3. Publish. Each release lands in its own directory and the “current” pointer is flipped when it is complete.

A download

Download as ZIP

A downloadable archive of the finished site. The publish runs as usual and leaves you a .zip instead of uploading it anywhere.

Best for: Handing a site to somebody who will host it themselves, or keeping an offline copy of exactly what went live.

Setting it up

  1. Add it as a destination. There is nothing to fill in.
  2. Publish. The archive appears on the project’s publish history, and the link is good for a while rather than for ever.

When something is wrong

When a publish skips a destination

A destination that is missing a credential or a setting is skipped instead of failing the publish, and your site still goes out to the others.

  • The Hosting settings page marks it Needs … and names the missing piece, and the provider’s own error is kept on the publish record with the next step it suggests.
  • A failure on the network (a dropped connection, or the provider’s own 5xx or 429) is tried twice more, after 5 and then 20 seconds. An answer about the site itself, such as a refused credential, is final at once.