WES custom hosting

WCH Publishing

Publishing turns your Webflow site into a static website that WCH hosts on a staging URL and delivers to your own hosting, such as an S3 bucket, an Azure container, or a GitHub repository.

Where to find it

  • Publish and promote from your project's Dashboard. The Rendering column has the Publish all pages button, and the Deployment column lists your configured destinations.
  • Set up destinations under Extensions > Deployments in the project sidebar.
  • Staging visibility, the root directory, and Webflow webhooks live under Settings.

How it works

Publishing happens in two stages:

  1. Publish to staging. WCH fetches every page from your Webflow project (the Source), rewrites pages and assets into a self-contained static site, and hosts the result at your staging URL. It also generates sitemap.xml, robots.txt, and llms.txt for the site.
  2. Deploy to a destination. WCH packages the staging output and sends it to the destinations you've configured: AWS S3, Azure Blob Storage, Aliyun OSS, SFTP, or GitHub.

Only one publish runs at a time.

Staging visibility

In Settings, the Staging visibility setting controls who can see your staging site:

  • Public staging: accessible to anyone with the URL.
  • Private staging: requires a WCH login to view.
  • Off: staging is not accessible. You can still deploy to destinations; when you promote with staging off, WCH refreshes the build first.

Changing visibility to or from Public clears your published staging files. WCH stores public and private sites separately, so the switch removes the current build. Run Publish all pages again after changing this setting.

Setting up destinations

Go to Extensions > Deployments and click + Add Deployment. Choose a Deployment Type: AWS S3, Azure Blob Storage, Aliyun OSS, or SFTP, then fill in the credentials for that provider (bucket and keys for S3 and Aliyun, storage account and container for Azure, host and SSH keys for SFTP).

GitHub works a little differently: on the Deployments page, use Connect GitHub to authorize your account, then Link Repository to pick a repository and branch. You can link more than one repository and mark one as the active repository.

What each destination receives

  • AWS S3, Azure Blob Storage receive the whole site as a single zip archive, named project.zip by default.

  • Aliyun OSS and SFTP receives individual files, uploaded into the Folder you set (for example /public_html).

  • GitHub receives individual files committed to the linked branch. Each publish creates one commit and a matching tag, so your repository history doubles as a publish history. If nothing changed since the last publish, WCH skips the push.

Renaming the archive

For S3 and Azure destinations, the File Name field in the destination's configuration sets the name of the uploaded zip. Check Use project name to name the file after your project instead (spaces become hyphens). The .zip extension is always added for you.

Pre-production and production workflows

You can add several destinations of the same type, for example a pre-production bucket and a production bucket. In each destination's configuration, the Is Production? toggle marks it as your production target. Only one destination of each type can be production at a time.

On the Dashboard, each configured destination gets its own button:

  • Publish (non-production destinations) builds a fresh archive from your current staging content and sends it.
  • Promote (production destinations) sends the most recent archive that was already built, without rebuilding it. Production receives exactly the files you already published and reviewed on pre-production, byte for byte.

Publishing automatically from Webflow

You can have WCH publish whenever you publish in Webflow. In Settings, open Configure Webflow webhook and choose:

  • Trigger: On Staging publish or On Production publish, which Webflow publish action starts a build.
  • Destination: a Non-production destination for staging builds, or a Production destination for live builds.

With two webhooks, a Webflow staging publish can feed your pre-production destination while a Webflow production publish feeds your live one.

Root directory (advanced)

The Root directory field in Settings nests your entire site inside a subfolder of the archive and the deployed output. For example, setting it to marketing-site means the zip contains marketing-site/index.html, marketing-site/wesfiles/…, and so on, instead of files at the top level. The generated sitemap.xml and robots.txt land inside that folder too.

Use it when the destination hosts more than just this project: serving the site from a subdirectory of a bucket, or deploying several WCH projects into one bucket or repository without overwriting each other.

Changing the root directory can leave stale files behind. Files already deployed under the old path are not removed automatically. After changing it, clear the previously deployed files at your destination so visitors can't reach an outdated copy of the site.