docs: new essay

1 files changed, 10 insertions, 3 deletions

diff --git a/content/essays/如何优雅地部署一个静态网站.md b/content/essays/如何优雅地部署一个静态网站.md
index 44195a2c..817ab3c6 100644
--- a/content/essays/如何优雅地部署一个静态网站.md
+++ b/content/essays/如何优雅地部署一个静态网站.md
@@ -1,8 +1,9 @@
 +++
 title = '如何优雅地部署一个静态网站？'
+tags = ['DevOps', 'Geek', 'Web']
 slug = 'deploying-static-sites'
-date = 2026-01-27 22:40:11
-draft = true
+date = 2026-01-28 18:07:29
+draft = false
 toc = true
 +++
 
@@ -204,6 +205,12 @@ hooks.example.com {
 
 ## 对比三种方案
 
-对于缺少经验的人来说，使用 PaaS 是最简单的，几乎去掉了维护一个网站所需要的所有运维技能，只需要关注写代码。不过，似乎大部分 PaaS 都只支持从 GitHub 和 GitLab 和拉取代码，或者自己手动上传代码，不支持和自托管的 Gitea 或者 Forgejo 实例集成。
+对于缺少经验的人来说，使用 PaaS 是最简单的，几乎去掉了维护一个网站所需要的所有运维技能，只需要关注写代码。不过，似乎大部分 PaaS 都只支持从 GitHub 和 GitLab 和拉取代码，或者自己手动上传代码，不支持和自托管的 Gitea 或者 Forgejo 实例集成。个人感觉，==使用 PaaS 就像是在和恶魔交易，出卖自己的灵魂以换取便捷，代价是会被科技公司锁死在他们的平台上==。
+
+GitHub Actions 类的自动化工作流，想必是有用武之地的，但我认为并不适合用来部署网站。如果只是运行自动化测试或拉取数据这种操作，把工作流脚本和代码放在一个仓库里大概是合适的。如果某些操作需要大量的依赖项才能运行，那么自动化工作流的效率就会因为需要安装大量依赖而被拉低。
+
+目前实践下来，个人认为最优雅的方案就是在服务器上直接构建，通过 Webhook 触发，这样就省去了部署的步骤。不过，如果没有一台 Web 服务器，也就用不了这个方法了。
+
+印象中还有人会在本地构建，将构建产物使用 `rclone` 同步到储存桶，或者使用 `rsync` 同步到服务器上，我没有实践过这种做法，就不评价了。
 
 [^1]: 其实我更喜欢使用 `pnpm`，但如果要在自动化工作流里使用，还要额外安装，所以这里就直接用 `npm` 了。