WES custom hosting

WCH Publishing

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, then Deployments in the project sidebar.
  • Staging visibility, the root directory, and 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 writes sitemap.xml and robots.txt. If your Webflow site has an llms.txt file, WCH copies it too.
  2. Deploy to a destination. WCH packages the staging output and sends it to the destinations you have configured: AWS S3, Azure Blob Storage, Aliyun OSS, SFTP, or GitHub.

Only one publish runs at a time per project.

Staging visibility

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

  • Public: accessible to anyone with the URL.
  • Private: requires a WCH login to view.
  • Off: staging is not accessible and the Publish all pages button is hidden. You can still deploy to destinations. When you promote with staging off, WCH refreshes the build first.

Switching to or from Public deletes your staging build and your archives. WCH stores public and private sites separately, so the switch removes the current build and every archive on the Archives page. Run Publish all pages again after changing this setting, and download any archive you want to keep first.

Setting up destinations

Go to Extensions, then 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. If your team has saved deployment templates, you can pick one instead of entering credentials.

GitHub works differently: on the Deployments page, click 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 active. See GitHub: Basic Implementation.

What each destination receives

  • AWS S3 and Azure Blob Storage receive the whole site as a single zip archive, named project.zip by default.
  • Aliyun OSS and SFTP receive 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. If nothing changed since the last publish, WCH skips the push.

No destination deletes files. Pages and assets you remove from your site stay at the destination until you clean them up. For S3, see Removing Dead Files During an S3 Publish.

Renaming the archive

For S3 and Azure destinations, the File Name field sets the name of the uploaded zip. Tick Use project name to name the file after your project instead. Spaces in the project name become hyphens.

Pre-production and production destinations

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. A project can have one production destination per type. GitHub and SFTP destinations have no production flag.

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 reviewed on pre-production, byte for byte. If an archive was already promoted, WCH warns you before sending it again.

If the production destination is the only destination of its type, there is no earlier archive to promote, so the Promote button runs a full publish instead.

You can also promote any earlier build from the Archives page with Promote to Production. WCH keeps the 10 most recent archives per project.

Publishing automatically from Webflow

You can have WCH publish whenever you publish in Webflow. In Settings, under Publishing webhooks, click Add publishing 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. See Webhooks for details.

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 leaves stale files behind. Files already deployed under the old path are not removed. After changing it, clear the previously deployed files at your destination so visitors cannot reach an outdated copy of the site.