Oleg Isonen
99371187dc
## Summary - move the complete GitBook documentation tree and assets into Builder under `/docs` - generate the exhaustive MCP page from the local CLI source in the same change - publish GitBook from a release-gated `docs` branch containing the exact successfully released revision - run MCP documentation tests, typechecking, and stale-output checks with the existing generated-docs check - remove links to the Community Discussions repository ## Technical choices - Import the current documentation as a linear snapshot so the branch satisfies Builder's required-linear-history protection. - Keep the Markdown wrapper separate from the TypeScript generator at `scripts/docs/mcp-page.md`. - Generate through `packages/cli/local.js` so CLI guidance and its documentation are reviewed together. - Let `check:generated-docs` reject CLI changes that leave the committed MCP page stale. - After both GitHub release creation and package publication succeed, fast-forward the read-only `docs` branch to the immutable release tag commit. A divergent update fails instead of publishing a different revision. - Configure GitBook to publish `/docs` from the `docs` branch, not directly from `main`. - Exclude `/docs` from the repository-wide `oxfmt` scan so imported GitBook Markdown retains its established formatting; generator tests and stale-output checks still validate the MCP page. - Exclude `transcripts/` and GitHub Discussions from the migration. ## Todo - [x] Import documentation, navigation, includes, and assets under `/docs`. - [x] Generate the MCP page from the local CLI source. - [x] Move MCP generation and validation into Builder. - [x] Require MCP documentation updates alongside CLI changes. - [x] Publish released revisions through a read-only `docs` branch. - [x] Remove Community repository links from Builder and the migrated docs. - [x] Preserve and verify a final Community Git bundle locally. - [ ] Merge this pull request. - [ ] Let the next successful release create or advance the `docs` branch. - [ ] Repoint GitBook Git Sync to `webstudio-is/webstudio`, branch `docs`, root directory `/docs`. - [ ] Verify `docs.webstudio.is`, navigation, assets, anchors, and the MCP page in production. - [ ] Delete `webstudio-is/webstudio-community`. ## Verification - `pnpm check:generated-docs` - `pnpm lint` - `pnpm oxfmt --check` - `git diff --check origin/main...HEAD` - generator regression test demonstrated failing when the GitBook wrapper behavior was removed, then passing after restoration - no fixture inputs or outputs are affected ## Known limitation All documentation merged after the previous release waits for the next successful release before GitBook publishes it. This deliberately keeps the public MCP reference aligned with an installable CLI revision. Ref #5986
3.7 KiB
description
| description |
|---|
| How to deploy your Website Project to Flightcontrol using the Docker template. |
▶️ AWS with Flightcontrol (Docker)
In this tutorial, you will learn how to export your Webstudio Project and use Flightcontrol to deploy it to AWS.
{% hint style="info" %} Flightcontrol is a PaaS that deploys to your AWS account, enabling you to leverage the power and cost of AWS without the complexity. {% endhint %}
{% embed url="https://youtu.be/_YpTBvARxic" %}
Prerequisites
1. Create a GitHub repository
Create a repository where you will add the Webstudio Project code in the following steps.
Be sure to clone the repository to your local machine.
2. Export Webstudio Project
Use the CLI to export your Project and select the “Docker” option.
3. Push to GitHub
Now that the site code is local, push it to GitHub.
{% hint style="info" %} You do not need to install dependencies. {% endhint %}
4. Setup Flightcontrol
-
Follow the prompt to connect AWS, which will direct you to AWS. Then click “Create stack”. It may take a couple of minutes, but once it is done, Flightcontrol will take you to the next step.
-
Connect your GitHub account and select the repository you want to give it permission to.
-
Follow the prompts: Select "Build your own" > Select "Web server" > and select "Dockerfile" in "Build Configuration".
-
Deploy and wait. The initial deployment takes some time. Please allow up to ~15 minutes for the deployment to finish.
-
(Optional) If you are loading images from third-party domains, usually in the case of CMS integrations, you must specify those asset domains in the Environment Variables tab with the key
DOMAINSand a comma-separated list of the third-party domains. It’s best to inspect your HTML/API response to see the exact domain the platform is using.
5. Sync, Build, and push new changes
When you are ready to publish your latest changes again, follow these steps:
- Click “Publish” in the builder (even though you aren’t publishing to the cloud, it’s necessary to generate the latest build data).
- Run
webstudio sync - Run
webstudio build --template docker - Push the changes to GitHub
Now, you should have a website built on Webstudio that is hosted on AWS using Flightcontrol.
Related
- CLI – Export and build your project using the command line
- Digital Ocean with Coolify – Deploy using Coolify on Digital Ocean
- Hetzner with Coolify – Deploy using Coolify on Hetzner
- VPS with Docker – Manual Docker deployment on any VPS
- Publishing and custom domains – Set up custom domains for your site