尧图网页设计 
Zola 静态站点部署全攻略Docker、GitHub Pages、Netlify、Vercel 与云厂商实战【免费下载链接】zolaA fast static site generator in a single binary with everything built-in. https://www.getzola.org项目地址: https://gitcode.com/GitHub_Trending/zo/zolaZola 构建出的网站是纯静态文件无需数据库、无需后端运行时这使它可以被托管在几乎所有静态站点平台上。本文以 Zola 官方部署文档docs/content/documentation/deployment/为主线完整讲解 Docker 镜像、GitHub Pages、GitLab Pages、Netlify、Vercel、Cloudflare、AWS S3、Fly.io 等十余种部署方案包含可直接复制的构建命令与 CI 配置文件并结合作者仓库源码说明base_url、public输出目录等关键机制的底层实现。读完本文你将能够根据自己的托管偏好在任意主流平台上自动化构建与发布 Zola 站点。版本说明本文引用的部署示例中出现0.13.0、0.17.2、0.21.0、0.22.1等版本号均为官方文档写作时的示例当前仓库源码对应的 Zola 版本为0.23.3见 Cargo.toml。实际使用时可替换为你需要的任意已发布版本。Zola 的部署模型为什么托管如此简单官方部署总览overview.md开宗明义Zola 只输出纯文件不需要数据库这使得在众多托管商上部署变得非常简单。这意味着你不需要配置数据库连接内容全部在构建期被处理为 HTML部署应用服务器没有运行时依赖、没有动态接口担心构建环境与运行环境的差异构建产物就是可直接托管的静态文件。从源码看zola build命令把整个站点渲染到输出目录默认是项目根目录下的public文件夹见 src/cli.rs 中-o, --output-dir参数说明“Outputs the generated site in the given path (by default public dir in project root)”。因此几乎所有平台的部署流程都可以抽象为三步安装 Zola → 运行zola build→ 把public/目录发布出去。后续所有方案都是这个三步流程在不同平台上的自动化变体你可以按需选择想要完全掌控构建环境 → Docker 多阶段构建代码托管在 GitHub → GitHub Actions GitHub Pages希望零配置自动构建 → Netlify / Vercel / Cloudflare Pages / Zeabur 等 PaaS已有云厂商账号AWS / Azure / Fly.io→ 在其对象存储或容器平台上部署。部署前的关键概念base_url与zola build命令几乎所有部署方案都会提到base_url它是 Zola 站点能否正确渲染资源路径的核心配置。base_url是配置文件中站点的基础 URL官方文档站自身的示例见 docs/config.toml其完整配置说明可参考 configuration.md。命令行覆盖base_url由于站点的最终访问域名往往要到部署时才确定尤其是平台的预览 URLZola 提供了命令行覆盖能力。从 src/cli.rs 可以看到zola build的完整参数zola build [-u base_url] [-o output_dir] [-f] [--drafts] [--minify]-u, --base-url强制使用指定的 base URL默认使用配置文件中的值-o, --output-dir指定输出目录默认是项目根下的public-f, --force即使输出目录非空也强制构建--drafts构建时包含草稿页面--minify压缩生成的 HTML 文件。本文后续的 Netlify 预览部署、Cloudflare Pages 预览部署、GitLab Pages 部署本质都是“用平台分配的真实 URL 通过--base-url覆盖配置”。为什么预览 URL 会破坏资源加载若站点配置中写死了base_url https://example.com而平台给分支/PR 分配了不同的预览域名如https://your-branch.your-project.pages.dev那么页面中所有基于base_url生成的资源链接都会指向错误域名导致样式、图片、JS 全部 404。解决方案就是在 CI 构建命令里根据环境动态设置--base-url各平台的具体做法见下文对应小节。Docker 多阶段构建一次构建随处运行如果你需要以 Docker 镜像形式分发 Zola 站点例如部署到自建服务器、Kubernetes、或私有容器平台多阶段构建是最优雅的方式原文见 docker-image.md。第一阶段使用官方 Zola 镜像完成站点构建第二阶段仅保留静态产物交给一个轻量静态服务器提供服务FROM ghcr.io/getzola/zola:v0.22.1 AS zola COPY . /project WORKDIR /project RUN [zola, build] FROM ghcr.io/static-web-server/static-web-server:2 WORKDIR / COPY --fromzola /project/public /public其中static-web-server是一个用 Rust 编写的极简静态 Web 服务器官方文档即推荐此方案你当然也可以把第二阶段替换为 Nginx、Apache 等任何静态服务器。构建与验证docker build -t my_website:latest .运行并访问 http://localhost:8000docker run --rm -p 8000:80 my_website:latest重要提示如果你希望同一镜像能在多个位置多个域名使用必须将配置中的base_url设为/相对路径否则站点资源会指向构建时的域名。延伸Fly.io 的容器化部署Fly.io 方案与 Docker 多阶段构建思路一致只是运行时改由 Fly.io 平台提供。创建DockerfileFROM ghcr.io/getzola/zola:v0.17.2 AS builder WORKDIR /app COPY . . RUN [zola, build] FROM joseluisq/static-web-server:2 COPY --frombuilder /app/public /public ENV SERVER_PORT 8080然后依次执行fly launch检测到Dockerfile后会完成大部分自动配置。填写必要信息时对“启动数据库”和“立即部署”都选择no记下平台分配的应用主机名把zola.toml中的base_url改为该主机名或你绑定的域名base_url https://white-snow-9922.fly.dev执行flyctl deploy发布站点。若需要从 GitHub 持续部署按 Fly.io 官方“GitHub Actions 持续部署”指南的步骤 4–8 配置即可之后每次代码变更都会自动推送上线。GitHub Pages官方 Action 与分支发布GitHub Pages 提供两种部署路径原文见 github-pages.mdPages Artifacts推荐通过 GitHub Actions 构建站点并把构建产物作为部署 artifact 发布到 Pages分支发布把生成的静态文件提交到gh-pages之类的独立分支由 Pages 直接服务该分支。若需自定义域名需按 GitHub 官方“自定义域名与 GitHub Pages”文档完成 DNS 与仓库设置。方式一Pages ArtifactsZola 官方维护了一个 GitHub Actions位于getzola/github-pages按其 README 配置即可。要点在仓库 Settings 中把 Pages 的发布来源切换为GitHub Actions在仓库根目录创建.github/workflows工作流引用官方 action 构建并上传 artifact推送后 CI 会自动构建并发布站点。方式二分支发布社区维护的zola-deploy-actionshalzz/zola-deploy-action面向“将构建产物提交到gh-pages分支”的模式。其工作方式大致为在 Actions 中安装 Zola →zola build→ 将public/内容推送至gh-pages分支。两种方式二选一即可如果你需要自己的自定义域名则两种方式都需要按 GitHub 文档额外配置。GitLab Pages基于 GitLab CI/CD 的自动部署GitLab Pages 方案原文见 gitlab-pages.md依托 GitLab Runner 与 CI/CD 管道可运行在 GitLab SaaSgitlab.com或自托管实例上。仓库与主题配置建议单独建一个只包含 Zola 项目的仓库且让 Zola 标准目录结构位于仓库根目录。如果使用了主题最好用submodule引入并确保使用https形式的 URLgit submodule add https://github.com/getzola/hyde.git themes/hyde.gitlab-ci.yml模板在仓库根目录创建.gitlab-ci.yml并务必在ZOLA_VERSION变量中指定 Zola 版本semver 格式如0.17.2stages: - deploy default: image: debian:stable-slim variables: # 设为 recursiveRunner 才能拉取 submodule 形式的主题 GIT_SUBMODULE_STRATEGY: recursive # 在此指定 Zola 版本semver 格式如 0.17.2 或 0.18.0 ZOLA_VERSION: description: The version of Zola used to build the site. value: pages: stage: deploy script: - | apt-get update DEBIAN_FRONTENDnoninteractive apt-get install --assume-yes --no-install-recommends wget ca-certificates zola_urlhttps://github.com/getzola/zola/releases/download/v${ZOLA_VERSION}/zola-v${ZOLA_VERSION}-x86_64-unknown-linux-gnu.tar.gz if ! wget --quiet --spider $zola_url; then echo A Zola release with the specified version could not be found. exit 1 fi wget $zola_url tar -xzf *.tar.gz ./zola build --base-url $CI_PAGES_URL artifacts: paths: # 该目录内容将被发布到 GitLab Pages 服务器GitLab Pages 默认要求此名称 - public rules: # 仅在推送到默认分支master/main时发布与更新站点 - if: $CI_COMMIT_BRANCH $CI_DEFAULT_BRANCH要点说明该模板假设 Runner 使用Docker executor脚本先从 GitHub Releases 下载指定版本的 Zola 二进制再用--base-url $CI_PAGES_URL构建——$CI_PAGES_URL是 GitLab 提供的站点最终 URL因此无需手工配置base_url推送到默认分支后流水线会自动发布在 GitLab 左侧边栏Deploy Pages的 “Access pages” 中可找到站点 URL。Codeberg Pages Woodpecker CI从提交到发布的完整管道Codeberg 是面向自由软件的开源托管平台其 Pages 服务配合 Codeberg 托管的 Woodpecker CI 即可实现全自动部署原文见 codeberg-pages.md。主题使用 submodule与 GitLab 相同建议用 submodule 引入主题git submodule add https://github.com/getzola/hyde.git themes/hyde.woodpecker.yaml管道在项目根目录放置以下 Woodpecker 配置# 排除在 pages 分支上运行管道 when: branch: exclude: pages # 递归克隆以完整拉取作为 Git submodule 的主题 clone: git: image: woodpeckerci/plugin-git settings: recursive: true steps: # 构建 Zola 静态文件 build: image: alpine:edge commands: - apk add zola - zola build when: event: [push, pull_request] publish: image: bitnami/git environment: CBMAIL: from_secret: mail CBTOKEN: from_secret: codeberg_token commands: # 配置 Git - git config --global user.email $${CBMAIL} - git config --global user.name Woodpecker CI # 克隆输出分支 - git clone --branch pages https://$${CBTOKEN}codeberg.org/$CI_REPO.git $CI_REPO_NAME # 进入输出分支 - cd $CI_REPO_NAME # 删除旧文件 - git rm -r * || true # 无内容可删时不要失败 # 复制构建步骤的输出 - cp -ar ../public/. . # 提交并推送所有静态文件附带源码提交哈希 - git add --all - git commit -m Woodpecker CI ${CI_COMMIT_SHA} [SKIP CI] --allow-empty - git push when: event: [push]然后在 Woodpecker 中配置两个 secretmail你的 Codeberg 注册邮箱codeberg_token具有write:repository权限的 Codeberg 访问令牌。之后每次推送都会触发构建站点产物被提交到pages分支并发布在https://user.codeberg.page/repository。如需自定义域名在./static/目录下创建.domains文件构建时会被复制进产物并按 Codeberg Pages 官方文档配置 DNS。Sourcehut Pages.build.yml清单驱动Sourcehut 的 Pages 部署极其简洁原文见 sourcehut.md只需在仓库根目录创建.build.yml构建清单并推送即可。image: alpine/edge packages: - hut - zola oauth: pages.sr.ht/PAGES:RW environment: site: your_username.srht.site sources: - https://git.sr.ht/~your_username/my-website tasks: - build: | cd my-website zola build - package: | cd my-website tar -C public -cvz . ../site.tar.gz - upload: | hut pages publish -d $site site.tar.gz需要修改两处site改为承载站点的域名默认可使用your_username.srht.site子域sources改为你的 Sourcehut git/hg 公开仓库 URL示例中my-website是仓库名。清单会自动克隆源码、构建站点并通过hut命令行工具上传产物——hut会自动生成认证令牌无需额外配置。推送后 Sourcehut 会返回构建页链接可在其中查看进度$ git push Enumerating objects: 5, done. ... remote: Build started: remote: https://builds.sr.ht/~your_username/job/430625 [.build.yml]若使用自定义域名如blog.mydomain.org需要按 Sourcehut Pages 官方说明配置 DNS 记录指向 Sourcehut 服务器。Netlify自动部署、PR 预览与手动上传Netlify 支持从 Git 仓库自动构建也支持完全手动上传原文见 netlify.md。自动部署在 Netlify 管理后台“Add a site”选择 Git 提供商GitHub/GitLab/Bitbucket然后在部署设置中配置Build commandzola buildPublish directorypublic目录的路径Image selection使用最新镜像Environment variables添加ZOLA_VERSION例如0.13.0。ZOLA_VERSION可填任何已打 tag 的发布版本Netlify 会自动拉取对应版本完成构建。此后每次推送到 master 分支都会自动部署。使用netlify.toml启用 PR 预览若希望每个 PR 都能生成临时预览站点可在仓库中添加netlify.toml并在后台移除已填写的 build command / publish directory[build] # 以下假设 Zola 站点位于 docs 目录若不在子目录 # 则无需 base 变量但 publish 与 command 变量必须有。 base docs publish docs/public command zola build [build.environment] # 设置所需版本Netlify 会自动使用该版本构建。 ZOLA_VERSION 0.13.0 # PR 预览的关键用 Netlify 分配给预览站点的 URL 覆盖 base_url。 # Netlify 环境变量 $DEPLOY_PRIME_URL 保存该 URL。 [context.deploy-preview] command zola build --base-url $DEPLOY_PRIME_URL这里的原理正是前文所述的预览站点使用临时域名必须通过zola build --base-url $DEPLOY_PRIME_URL动态覆盖base_url该参数的定义见 src/cli.rs否则静态资源会全部指向错误域名。手动部署如果你使用非 tag 版本例如从源码自行修改构建的 Zola则需要手动上传public目录在 Netlify 账号设置中生成Personal Access Token注意不是 OAuth Application执行zola build构建站点将public目录打包为 zip运行以下命令替换三个占位值PERSONAL_ACCESS_TOKEN_FROM_STEP_1、FILE_NAME.zip、SITE_NAMEcurl -H Content-Type: application/zip \ -H Authorization: Bearer PERSONAL_ACCESS_TOKEN_FROM_STEP_1 \ --data-binary FILE_NAME.zip \ https://api.netlify.com/api/v1/sites/SITE_NAME.netlify.com/deploysVercel内置预设、GLIBC 排障与自定义二进制Vercel前身 Zeit与 Netlify 类似推送即部署原文见 vercel.md。自动部署导入 Git 仓库后Vercel 会自动探测框架若未自动识别为 Zola则将Framework Preset设为Zola。默认输出目录是public若使用其他目录需在 “Build and Output Settings” 中指定。指定 Zola 版本同样通过项目设置中的ZOLA_VERSION环境变量例如0.17.2。排障GLIBC_X.XXnot foundVercel 构建镜像自带的glibc版本可能低于 Zola 二进制的要求。Vercel 为不同 Node.js 版本提供不同的构建镜像尽管 Zola 与 Node.js 毫无关系因此可以将项目设置中的 Node.js 版本提升到较新的镜像环境。若项目创建于默认 Node.js20.x时期将其提升到22.x即可让 Zola0.19.2含之前的版本无需额外配置正常工作从 Zola0.21.0起官方发布了静态链接的musl二进制对 glibc 不足的系统如 Vercel 构建镜像兼容性最好。要使用 musl 版本需让 Vercel不使用内置的 Zola 预设改为自行提供二进制见下文。vercel.json进阶配置开启尾斜杠重定向访问无尾斜杠路径如/about时部分场景可能破坏相对路径。创建仓库根目录下的vercel.json{ trailingSlash: true }带文件扩展名的静态文件如favicon.ico不受影响。偏好干净 URL让 HTML 文件以无扩展名路径访问about/index.html→/about{ cleanUrls: true }使用自定义 Zola 二进制若想完全掌控构建工具将 Framework Preset 设为OtherVercel 将不再自动消费ZOLA_VERSION然后把Install Command设置为v${ZOLA_VERSION:tags/v$ZOLA_VERSION};curl -fsSL https://api.github.com/repos/getzola/zola/releases/${v:-latest}|grep -o browser_download_url: *[^]*x86_64-unknown-linux-${ZOLA_LIBC:-musl}\.tar\.gz|cut -d -f4|xargs curl -fsSL|tar -xz该命令通过 GitHub API 获取 Zola 发布信息并下载解压保留ZOLA_VERSION变量以固定版本不设置则始终拉取最新版默认拉取musl二进制无需再担心 Vercel 构建镜像的 glibc 问题仅支持x86_64架构Vercel 构建镜像即该架构若使用0.21.0之前的旧版本无 musl 二进制需新增环境变量ZOLA_LIBC并设为gnu。同时把Build Command设置为./zola build使用本地下载的二进制构建。也可以改用vercel.json会覆盖后台选项{ framework: null, installCommand: v${ZOLA_VERSION:tags/v$ZOLA_VERSION};curl -fsSL https://api.github.com/repos/getzola/zola/releases/${v:-latest}|grep -o \browser_download_url\: *\[^\]*x86_64-unknown-linux-${ZOLA_LIBC:-musl}\\.tar\\.gz\|cut -d\ -f4|xargs curl -fsSL|tar -xz, buildCommand: ./zola build, outputDirectory: public }如果你使用自己的 fork 及自行发布的二进制可按需修改命令。Cloudflare Pages框架预设与动态base_urlCloudflare Pages 依托 Cloudflare 的全球 CDN 网络支持连接 GitHub 仓库并随 PR 自动构建原文见 cloudflare-pages.md。部署步骤登录/注册 Cloudflare 账号在右侧导航选择Pages点击Create a project选择包含 Zola 站点的 GitHub 仓库并连接点击Begin setup填写项目名若使用默认pages.dev域名项目名即站点 URL 的yourprojectname.pages.dev部分并选择生产分支在Build settings中Framework preset 选择Zola构建命令与输出目录会被自动填充展开Environment variables添加ZOLA_VERSION变量值为0.17.2或任意所需版本保存并部署。此后站点构建并发布到 Cloudflare 网络可在 Pages 控制台添加自定义域名或修改设置。处理预览部署预览部署默认使用分支专属 URL如https://your-branch-name.your-project.pages.dev。若zola.toml中写死了base_url预览页面的资源加载会出错。解决办法是把 Cloudflare Pages 的构建命令改为按环境动态设置if [ $CF_PAGES_BRANCH main ]; then zola build; else zola build --base-url $CF_PAGES_URL; fi从 main 分支构建时使用zola.toml中的base_url其他分支使用 Cloudflare Pages 自动提供的$CF_PAGES_URL作为 base URL。Cloudflare WorkersWrangler 构建钩子若更偏好 Workers 形态Cloudflare 同样支持连接 Git 仓库自动部署原文见 cloudflare-workers.md核心是在仓库中准备构建脚本与 Wrangler 配置让默认命令npx wrangler deploy触发构建。创建构建脚本build.shCloudflare 克隆仓库时不会递归拉取 submodule因此脚本需自行处理子模块更新例如主题。在仓库根目录添加#!/usr/bin/env bash main() { ZOLA_VERSION0.22.1 curl -sLJO https://github.com/getzola/zola/releases/download/v${ZOLA_VERSION}/zola-v${ZOLA_VERSION}-x86_64-unknown-linux-gnu.tar.gz tar -xf zola-v${ZOLA_VERSION}-x86_64-unknown-linux-gnu.tar.gz git submodule update --init --recursive ./zola build } set -euo pipefail添加wrangler.toml在项目根目录创建wrangler.toml指向构建脚本与产物目录。name与compatibility_date是 Wrangler 的必填项分别使用你的站点名与当前日期name blog compatibility_date 2026-01-22 [build] command bash ./build.sh [assets] directory ./public创建 Worker登录 Cloudflare在导航栏选择Workers and Pages点击Create a project选择包含 Zola 站点的 GitHub 或 GitLab 仓库并连接保持默认设置点击Deploy。站点即被构建并部署到 Cloudflare 网络之后可在 Workers 控制台添加自定义域名或修改设置。AWS S3 CloudFront对象存储托管与 CDN 加速Amazon S3 是提供静态网站托管能力的对象存储服务。下面是在 GitHub Actions 中构建并部署 Zola 站点到 S3 的完整流程原文见 aws-s3.md若配合 CloudFront 还可获得全局 CDN 加速与自定义域名。AWS 侧准备创建存储桶并开启静态网站托管按 AWS 官方入门指南创建 bucket 并正确配置静态网站托管创建最小权限 IAM 策略在 AWS 控制台进入IAM Policies Create policy切换到JSON视图并粘贴以下内容注意把Bucket-Name替换为你的 bucket 名{ Version: 2012-10-17, Statement: [ { Sid: AccessToWebsiteBuckets, Effect: Allow, Action: [ s3:PutBucketWebsite, s3:PutObject, s3:PutObjectAcl, s3:GetObject, s3:ListBucket, s3:DeleteObject ], Resource: [ arn:aws:s3:::Bucket-Name, arn:aws:s3:::Bucket-Name/* ] }, { Sid: AccessToCloudfront, Effect: Allow, Action: [cloudfront:GetInvalidation, cloudfront:CreateInvalidation], Resource: * } ] }AccessToCloudfront部分仅在需要 CloudFront 加速时才需要否则可删除。创建 IAM 用户进入IAM Users创建用户如命名github-actions-user在Set permissions步骤选择Attach policies directly并勾选刚才创建的策略生成访问密钥在用户列表点击该用户打开Security Credentials标签在Access keys下选择Create access key用途选择Command Line Interface (CLI)记录Access key ID与Secret access key。在 GitHub 中配置 Secrets在仓库Settings Secrets and variables Actions中添加 Repository secretsAWS_ACCESS_KEY_ID上一步的 Access key IDAWS_SECRET_ACCESS_KEY上一步的 Secret access keyS3_BUCKETbucket 名称CLOUDFRONT_DISTRIBUTION_ID若创建了 CloudFront 分发包则添加。GitHub Actions 工作流在仓库创建.github/workflows/publish.ymlname: Build and Publish to AWS on: push: branches: - main jobs: run: runs-on: ubuntu-latest timeout-minutes: 10 steps: - uses: actions/checkoutv3 - uses: taiki-e/install-actionv2 with: tool: zola0.17.2 - name: Build run: zola build - uses: reggionick/s3-deployv4 env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} with: folder: public bucket: ${{ secrets.S3_BUCKET }} private: true bucket-region: us-east-1 # 仅当创建了 CloudFront 分发包时使用以下两项 dist-id: ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} invalidation: /*若希望在其他分支触发或其他行为可修改on.push.branches中的分支名。Azure Static Web Apps托管服务 GitHub ActionsAzure Static Web Apps 是 Azure 的托管服务可从 GitHub 或 Azure DevOps 仓库的变更自动部署静态站点原文见 azure-static-webapps.md。在 Azure 门户创建应用按 Azure 官方文档在门户中创建 Static Web App选择GitHub作为代码托管平台唯一需要注意的是Build Details部分将App location设置为./public这是zola build默认输出目录其余留空。创建完成后记下 Azure 自动分配的域名并把仓库zola.toml中的base_url更新为该 URL。配置 GitHub ActionsAzure 会在仓库中自动生成.github/workflows下的 YAML 工作流并配置部署 secrets。需要做的只是补充“安装 Zola 并构建”的步骤# .github/workflows/azure-static-web-apps-web-app-name name: Azure Static Web Apps CI/CD on: push: branches: - main pull_request: types: [opened, synchronize, reopened, closed] branches: - main jobs: build_and_deploy_job: if: github.event_name push || (github.event_name pull_request github.event.action ! closed) runs-on: ubuntu-latest name: Build and Deploy Job steps: - uses: actions/checkoutv3 with: submodules: true lfs: false - uses: taiki-e/install-actionv2 with: tool: zola0.21.0 - name: Build Static Site run: zola build - name: Build And Deploy id: builddeploy uses: Azure/static-web-apps-deployv1 with: azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_WEB_APP_NAME }} repo_token: ${{ secrets.GITHUB_TOKEN }} # 用于 GitHub 集成如 PR 评论 action: upload # 仓库/构建配置 app_location: ./public # App 源码路径 api_location: # API 源码路径 - 可选 output_location: # 构建产物目录 - 可选 close_pull_request_job: if: github.event_name pull_request github.event.action closed runs-on: ubuntu-latest name: Close Pull Request Job steps: - name: Close Pull Request id: closepullrequest uses: Azure/static-web-apps-deployv1 with: azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKENWEB_APP_NAME }} action: close推送 YAML 变更后GitHub 会自动触发工作流部署站点。工作流中的close_pull_request_job负责在 PR 关闭时清理预览环境。EdgioCLI 一键部署Edgio原 Layer0提供基于 CLI 的极简部署流程原文见 edgio.md。# 1. 安装 Edgio CLI npm i -g edgio/cli # 2. 在项目根目录创建 package.json npm init -y # 3. 初始化项目 edgio initedgio init会生成routes.js将其内容改为托管public目录// This file was added by edgio init. // You should commit this file to source control. import { Router } from edgio/core/router export default new Router().static(public)然后构建并部署zola build edgio deployZeabur零配置的托管式部署Zeabur 提供自动 SSL 证书与全球边缘网络分发部署 Zola 站点几乎无需任何配置原文见 zeabur.md。前置条件本地已有 Zola 站点项目GitHub 账号与托管站点的仓库Zeabur 账号。创建项目登录 Zeabur 控制台点击Create Project按提示完成设置推送代码在项目目录初始化 Git 并推送到 GitHubgit init git add . git commit -m Initial commit git remote add origin your-github-repo-url git branch -M main git push -u origin main创建服务在控制台点击Create Service选择git选项连接 GitHub 仓库选择仓库从列表中选择存放 Zola 项目的仓库自动部署Zeabur 会自动识别 Zola 项目并完成部署无需额外配置。如需指定版本在项目设置的环境变量中添加ZOLA_VERSION如0.17.2绑定域名部署完成后为服务绑定域名可使用免费的.zeabur.app子域名或自定义域名Zeabur 会自动为域名签发免费 SSL 证书站点上线访问绑定的域名即可看到部署结果。部署方案速览与选择建议平台构建方式输出目录约定版本控制预览/PR 支持要点Docker多阶段镜像public复制进镜像镜像 tag无base_url需设为/才能多环境复用GitHub PagesActions artifact 或gh-pages分支publicGitHub Action随分支需在设置中启用 Actions 发布源GitLab PagesGitLab CI/CDpublicartifactZOLA_VERSION随分支/PR用$CI_PAGES_URL覆盖base_urlCodeberg PagesWoodpecker CIpublic→pages分支环境变量随分支需write:repository令牌Sourcehut Pages.build.yml清单public打包上传hut工具随推送oauth: pages.sr.ht/PAGES:RWNetlify平台自动构建publicZOLA_VERSION$DEPLOY_PRIME_URL支持纯手动curl上传Vercel平台自动构建publicZOLA_VERSION随分支glibc 问题可用 musl 二进制解决Cloudflare Pages平台自动构建预设自动填充ZOLA_VERSION$CF_PAGES_URL构建命令可做分支判断Cloudflare Workersbuild.sh Wranglerpublicassets脚本内ZOLA_VERSION随分支需自建构建钩子AWS S3GitHub Actionspubliczola版本无IAM 最小权限 可选 CloudFrontAzure Static Web AppsGitHub Actions./publicApp locationzola版本PR 自动预览/关闭Azure 自动生成工作流Fly.io容器构建public复制进镜像镜像 tag无flyctl deploy发布EdgioCLIpublic路由静态目录edgio init随分支edgio deploy一键上线Zeabur平台自动识别publicZOLA_VERSION随分支免费 SSL、边缘网络选择建议代码已托管在 GitHub/GitLab 且想少维护 CI→ 优先 Netlify、Vercel、Cloudflare Pages、Zeabur 等 PaaS 平台对 CI 过程有强控制需求→ GitHub Pages / GitLab Pages 的分支发布模式或自写 GitHub ActionsAWS S3 / Azure 方案需要容器化、Kubernetes 部署或离线分发→ Docker 多阶段构建方案已有特定云厂商预算/合规要求→ 按厂商方案AWS S3、Azure Static Web Apps、Fly.io、Cloudflare Workers选择。延伸阅读部署总览纯静态输出模型的官方说明目录结构构建前应了解的 Zola 标准目录布局配置参考base_url等核心配置项的完整说明命令行用法zola build/zola serve的日常使用src/cli.rsbuild/serve子命令全部参数--base-url、--output-dir、--force、--drafts、--minify等的源码定义【免费下载链接】zolaA fast static site generator in a single binary with everything built-in. https://www.getzola.org项目地址: https://gitcode.com/GitHub_Trending/zo/zola创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zola 静态站点部署全攻略：Docker、GitHub Pages、Netlify、Vercel 与云厂商实战
Zola 静态站点部署全攻略Docker、GitHub Pages、Netlify、Vercel 与云厂商实战【免费下载链接】zolaA fast static site generator in a single binary with everything built-in. https://www.getzola.org项目地址: https://gitcode.com/GitHub_Trending/zo/zolaZola 构建出的网站是纯静态文件无需数据库、无需后端运行时这使它可以被托管在几乎所有静态站点平台上。本文以 Zola 官方部署文档docs/content/documentation/deployment/为主线完整讲解 Docker 镜像、GitHub Pages、GitLab Pages、Netlify、Vercel、Cloudflare、AWS S3、Fly.io 等十余种部署方案包含可直接复制的构建命令与 CI 配置文件并结合作者仓库源码说明base_url、public输出目录等关键机制的底层实现。读完本文你将能够根据自己的托管偏好在任意主流平台上自动化构建与发布 Zola 站点。版本说明本文引用的部署示例中出现0.13.0、0.17.2、0.21.0、0.22.1等版本号均为官方文档写作时的示例当前仓库源码对应的 Zola 版本为0.23.3见 Cargo.toml。实际使用时可替换为你需要的任意已发布版本。Zola 的部署模型为什么托管如此简单官方部署总览overview.md开宗明义Zola 只输出纯文件不需要数据库这使得在众多托管商上部署变得非常简单。这意味着你不需要配置数据库连接内容全部在构建期被处理为 HTML部署应用服务器没有运行时依赖、没有动态接口担心构建环境与运行环境的差异构建产物就是可直接托管的静态文件。从源码看zola build命令把整个站点渲染到输出目录默认是项目根目录下的public文件夹见 src/cli.rs 中-o, --output-dir参数说明“Outputs the generated site in the given path (by default public dir in project root)”。因此几乎所有平台的部署流程都可以抽象为三步安装 Zola → 运行zola build→ 把public/目录发布出去。后续所有方案都是这个三步流程在不同平台上的自动化变体你可以按需选择想要完全掌控构建环境 → Docker 多阶段构建代码托管在 GitHub → GitHub Actions GitHub Pages希望零配置自动构建 → Netlify / Vercel / Cloudflare Pages / Zeabur 等 PaaS已有云厂商账号AWS / Azure / Fly.io→ 在其对象存储或容器平台上部署。部署前的关键概念base_url与zola build命令几乎所有部署方案都会提到base_url它是 Zola 站点能否正确渲染资源路径的核心配置。base_url是配置文件中站点的基础 URL官方文档站自身的示例见 docs/config.toml其完整配置说明可参考 configuration.md。命令行覆盖base_url由于站点的最终访问域名往往要到部署时才确定尤其是平台的预览 URLZola 提供了命令行覆盖能力。从 src/cli.rs 可以看到zola build的完整参数zola build [-u base_url] [-o output_dir] [-f] [--drafts] [--minify]-u, --base-url强制使用指定的 base URL默认使用配置文件中的值-o, --output-dir指定输出目录默认是项目根下的public-f, --force即使输出目录非空也强制构建--drafts构建时包含草稿页面--minify压缩生成的 HTML 文件。本文后续的 Netlify 预览部署、Cloudflare Pages 预览部署、GitLab Pages 部署本质都是“用平台分配的真实 URL 通过--base-url覆盖配置”。为什么预览 URL 会破坏资源加载若站点配置中写死了base_url https://example.com而平台给分支/PR 分配了不同的预览域名如https://your-branch.your-project.pages.dev那么页面中所有基于base_url生成的资源链接都会指向错误域名导致样式、图片、JS 全部 404。解决方案就是在 CI 构建命令里根据环境动态设置--base-url各平台的具体做法见下文对应小节。Docker 多阶段构建一次构建随处运行如果你需要以 Docker 镜像形式分发 Zola 站点例如部署到自建服务器、Kubernetes、或私有容器平台多阶段构建是最优雅的方式原文见 docker-image.md。第一阶段使用官方 Zola 镜像完成站点构建第二阶段仅保留静态产物交给一个轻量静态服务器提供服务FROM ghcr.io/getzola/zola:v0.22.1 AS zola COPY . /project WORKDIR /project RUN [zola, build] FROM ghcr.io/static-web-server/static-web-server:2 WORKDIR / COPY --fromzola /project/public /public其中static-web-server是一个用 Rust 编写的极简静态 Web 服务器官方文档即推荐此方案你当然也可以把第二阶段替换为 Nginx、Apache 等任何静态服务器。构建与验证docker build -t my_website:latest .运行并访问 http://localhost:8000docker run --rm -p 8000:80 my_website:latest重要提示如果你希望同一镜像能在多个位置多个域名使用必须将配置中的base_url设为/相对路径否则站点资源会指向构建时的域名。延伸Fly.io 的容器化部署Fly.io 方案与 Docker 多阶段构建思路一致只是运行时改由 Fly.io 平台提供。创建DockerfileFROM ghcr.io/getzola/zola:v0.17.2 AS builder WORKDIR /app COPY . . RUN [zola, build] FROM joseluisq/static-web-server:2 COPY --frombuilder /app/public /public ENV SERVER_PORT 8080然后依次执行fly launch检测到Dockerfile后会完成大部分自动配置。填写必要信息时对“启动数据库”和“立即部署”都选择no记下平台分配的应用主机名把zola.toml中的base_url改为该主机名或你绑定的域名base_url https://white-snow-9922.fly.dev执行flyctl deploy发布站点。若需要从 GitHub 持续部署按 Fly.io 官方“GitHub Actions 持续部署”指南的步骤 4–8 配置即可之后每次代码变更都会自动推送上线。GitHub Pages官方 Action 与分支发布GitHub Pages 提供两种部署路径原文见 github-pages.mdPages Artifacts推荐通过 GitHub Actions 构建站点并把构建产物作为部署 artifact 发布到 Pages分支发布把生成的静态文件提交到gh-pages之类的独立分支由 Pages 直接服务该分支。若需自定义域名需按 GitHub 官方“自定义域名与 GitHub Pages”文档完成 DNS 与仓库设置。方式一Pages ArtifactsZola 官方维护了一个 GitHub Actions位于getzola/github-pages按其 README 配置即可。要点在仓库 Settings 中把 Pages 的发布来源切换为GitHub Actions在仓库根目录创建.github/workflows工作流引用官方 action 构建并上传 artifact推送后 CI 会自动构建并发布站点。方式二分支发布社区维护的zola-deploy-actionshalzz/zola-deploy-action面向“将构建产物提交到gh-pages分支”的模式。其工作方式大致为在 Actions 中安装 Zola →zola build→ 将public/内容推送至gh-pages分支。两种方式二选一即可如果你需要自己的自定义域名则两种方式都需要按 GitHub 文档额外配置。GitLab Pages基于 GitLab CI/CD 的自动部署GitLab Pages 方案原文见 gitlab-pages.md依托 GitLab Runner 与 CI/CD 管道可运行在 GitLab SaaSgitlab.com或自托管实例上。仓库与主题配置建议单独建一个只包含 Zola 项目的仓库且让 Zola 标准目录结构位于仓库根目录。如果使用了主题最好用submodule引入并确保使用https形式的 URLgit submodule add https://github.com/getzola/hyde.git themes/hyde.gitlab-ci.yml模板在仓库根目录创建.gitlab-ci.yml并务必在ZOLA_VERSION变量中指定 Zola 版本semver 格式如0.17.2stages: - deploy default: image: debian:stable-slim variables: # 设为 recursiveRunner 才能拉取 submodule 形式的主题 GIT_SUBMODULE_STRATEGY: recursive # 在此指定 Zola 版本semver 格式如 0.17.2 或 0.18.0 ZOLA_VERSION: description: The version of Zola used to build the site. value: pages: stage: deploy script: - | apt-get update DEBIAN_FRONTENDnoninteractive apt-get install --assume-yes --no-install-recommends wget ca-certificates zola_urlhttps://github.com/getzola/zola/releases/download/v${ZOLA_VERSION}/zola-v${ZOLA_VERSION}-x86_64-unknown-linux-gnu.tar.gz if ! wget --quiet --spider $zola_url; then echo A Zola release with the specified version could not be found. exit 1 fi wget $zola_url tar -xzf *.tar.gz ./zola build --base-url $CI_PAGES_URL artifacts: paths: # 该目录内容将被发布到 GitLab Pages 服务器GitLab Pages 默认要求此名称 - public rules: # 仅在推送到默认分支master/main时发布与更新站点 - if: $CI_COMMIT_BRANCH $CI_DEFAULT_BRANCH要点说明该模板假设 Runner 使用Docker executor脚本先从 GitHub Releases 下载指定版本的 Zola 二进制再用--base-url $CI_PAGES_URL构建——$CI_PAGES_URL是 GitLab 提供的站点最终 URL因此无需手工配置base_url推送到默认分支后流水线会自动发布在 GitLab 左侧边栏Deploy Pages的 “Access pages” 中可找到站点 URL。Codeberg Pages Woodpecker CI从提交到发布的完整管道Codeberg 是面向自由软件的开源托管平台其 Pages 服务配合 Codeberg 托管的 Woodpecker CI 即可实现全自动部署原文见 codeberg-pages.md。主题使用 submodule与 GitLab 相同建议用 submodule 引入主题git submodule add https://github.com/getzola/hyde.git themes/hyde.woodpecker.yaml管道在项目根目录放置以下 Woodpecker 配置# 排除在 pages 分支上运行管道 when: branch: exclude: pages # 递归克隆以完整拉取作为 Git submodule 的主题 clone: git: image: woodpeckerci/plugin-git settings: recursive: true steps: # 构建 Zola 静态文件 build: image: alpine:edge commands: - apk add zola - zola build when: event: [push, pull_request] publish: image: bitnami/git environment: CBMAIL: from_secret: mail CBTOKEN: from_secret: codeberg_token commands: # 配置 Git - git config --global user.email $${CBMAIL} - git config --global user.name Woodpecker CI # 克隆输出分支 - git clone --branch pages https://$${CBTOKEN}codeberg.org/$CI_REPO.git $CI_REPO_NAME # 进入输出分支 - cd $CI_REPO_NAME # 删除旧文件 - git rm -r * || true # 无内容可删时不要失败 # 复制构建步骤的输出 - cp -ar ../public/. . # 提交并推送所有静态文件附带源码提交哈希 - git add --all - git commit -m Woodpecker CI ${CI_COMMIT_SHA} [SKIP CI] --allow-empty - git push when: event: [push]然后在 Woodpecker 中配置两个 secretmail你的 Codeberg 注册邮箱codeberg_token具有write:repository权限的 Codeberg 访问令牌。之后每次推送都会触发构建站点产物被提交到pages分支并发布在https://user.codeberg.page/repository。如需自定义域名在./static/目录下创建.domains文件构建时会被复制进产物并按 Codeberg Pages 官方文档配置 DNS。Sourcehut Pages.build.yml清单驱动Sourcehut 的 Pages 部署极其简洁原文见 sourcehut.md只需在仓库根目录创建.build.yml构建清单并推送即可。image: alpine/edge packages: - hut - zola oauth: pages.sr.ht/PAGES:RW environment: site: your_username.srht.site sources: - https://git.sr.ht/~your_username/my-website tasks: - build: | cd my-website zola build - package: | cd my-website tar -C public -cvz . ../site.tar.gz - upload: | hut pages publish -d $site site.tar.gz需要修改两处site改为承载站点的域名默认可使用your_username.srht.site子域sources改为你的 Sourcehut git/hg 公开仓库 URL示例中my-website是仓库名。清单会自动克隆源码、构建站点并通过hut命令行工具上传产物——hut会自动生成认证令牌无需额外配置。推送后 Sourcehut 会返回构建页链接可在其中查看进度$ git push Enumerating objects: 5, done. ... remote: Build started: remote: https://builds.sr.ht/~your_username/job/430625 [.build.yml]若使用自定义域名如blog.mydomain.org需要按 Sourcehut Pages 官方说明配置 DNS 记录指向 Sourcehut 服务器。Netlify自动部署、PR 预览与手动上传Netlify 支持从 Git 仓库自动构建也支持完全手动上传原文见 netlify.md。自动部署在 Netlify 管理后台“Add a site”选择 Git 提供商GitHub/GitLab/Bitbucket然后在部署设置中配置Build commandzola buildPublish directorypublic目录的路径Image selection使用最新镜像Environment variables添加ZOLA_VERSION例如0.13.0。ZOLA_VERSION可填任何已打 tag 的发布版本Netlify 会自动拉取对应版本完成构建。此后每次推送到 master 分支都会自动部署。使用netlify.toml启用 PR 预览若希望每个 PR 都能生成临时预览站点可在仓库中添加netlify.toml并在后台移除已填写的 build command / publish directory[build] # 以下假设 Zola 站点位于 docs 目录若不在子目录 # 则无需 base 变量但 publish 与 command 变量必须有。 base docs publish docs/public command zola build [build.environment] # 设置所需版本Netlify 会自动使用该版本构建。 ZOLA_VERSION 0.13.0 # PR 预览的关键用 Netlify 分配给预览站点的 URL 覆盖 base_url。 # Netlify 环境变量 $DEPLOY_PRIME_URL 保存该 URL。 [context.deploy-preview] command zola build --base-url $DEPLOY_PRIME_URL这里的原理正是前文所述的预览站点使用临时域名必须通过zola build --base-url $DEPLOY_PRIME_URL动态覆盖base_url该参数的定义见 src/cli.rs否则静态资源会全部指向错误域名。手动部署如果你使用非 tag 版本例如从源码自行修改构建的 Zola则需要手动上传public目录在 Netlify 账号设置中生成Personal Access Token注意不是 OAuth Application执行zola build构建站点将public目录打包为 zip运行以下命令替换三个占位值PERSONAL_ACCESS_TOKEN_FROM_STEP_1、FILE_NAME.zip、SITE_NAMEcurl -H Content-Type: application/zip \ -H Authorization: Bearer PERSONAL_ACCESS_TOKEN_FROM_STEP_1 \ --data-binary FILE_NAME.zip \ https://api.netlify.com/api/v1/sites/SITE_NAME.netlify.com/deploysVercel内置预设、GLIBC 排障与自定义二进制Vercel前身 Zeit与 Netlify 类似推送即部署原文见 vercel.md。自动部署导入 Git 仓库后Vercel 会自动探测框架若未自动识别为 Zola则将Framework Preset设为Zola。默认输出目录是public若使用其他目录需在 “Build and Output Settings” 中指定。指定 Zola 版本同样通过项目设置中的ZOLA_VERSION环境变量例如0.17.2。排障GLIBC_X.XXnot foundVercel 构建镜像自带的glibc版本可能低于 Zola 二进制的要求。Vercel 为不同 Node.js 版本提供不同的构建镜像尽管 Zola 与 Node.js 毫无关系因此可以将项目设置中的 Node.js 版本提升到较新的镜像环境。若项目创建于默认 Node.js20.x时期将其提升到22.x即可让 Zola0.19.2含之前的版本无需额外配置正常工作从 Zola0.21.0起官方发布了静态链接的musl二进制对 glibc 不足的系统如 Vercel 构建镜像兼容性最好。要使用 musl 版本需让 Vercel不使用内置的 Zola 预设改为自行提供二进制见下文。vercel.json进阶配置开启尾斜杠重定向访问无尾斜杠路径如/about时部分场景可能破坏相对路径。创建仓库根目录下的vercel.json{ trailingSlash: true }带文件扩展名的静态文件如favicon.ico不受影响。偏好干净 URL让 HTML 文件以无扩展名路径访问about/index.html→/about{ cleanUrls: true }使用自定义 Zola 二进制若想完全掌控构建工具将 Framework Preset 设为OtherVercel 将不再自动消费ZOLA_VERSION然后把Install Command设置为v${ZOLA_VERSION:tags/v$ZOLA_VERSION};curl -fsSL https://api.github.com/repos/getzola/zola/releases/${v:-latest}|grep -o browser_download_url: *[^]*x86_64-unknown-linux-${ZOLA_LIBC:-musl}\.tar\.gz|cut -d -f4|xargs curl -fsSL|tar -xz该命令通过 GitHub API 获取 Zola 发布信息并下载解压保留ZOLA_VERSION变量以固定版本不设置则始终拉取最新版默认拉取musl二进制无需再担心 Vercel 构建镜像的 glibc 问题仅支持x86_64架构Vercel 构建镜像即该架构若使用0.21.0之前的旧版本无 musl 二进制需新增环境变量ZOLA_LIBC并设为gnu。同时把Build Command设置为./zola build使用本地下载的二进制构建。也可以改用vercel.json会覆盖后台选项{ framework: null, installCommand: v${ZOLA_VERSION:tags/v$ZOLA_VERSION};curl -fsSL https://api.github.com/repos/getzola/zola/releases/${v:-latest}|grep -o \browser_download_url\: *\[^\]*x86_64-unknown-linux-${ZOLA_LIBC:-musl}\\.tar\\.gz\|cut -d\ -f4|xargs curl -fsSL|tar -xz, buildCommand: ./zola build, outputDirectory: public }如果你使用自己的 fork 及自行发布的二进制可按需修改命令。Cloudflare Pages框架预设与动态base_urlCloudflare Pages 依托 Cloudflare 的全球 CDN 网络支持连接 GitHub 仓库并随 PR 自动构建原文见 cloudflare-pages.md。部署步骤登录/注册 Cloudflare 账号在右侧导航选择Pages点击Create a project选择包含 Zola 站点的 GitHub 仓库并连接点击Begin setup填写项目名若使用默认pages.dev域名项目名即站点 URL 的yourprojectname.pages.dev部分并选择生产分支在Build settings中Framework preset 选择Zola构建命令与输出目录会被自动填充展开Environment variables添加ZOLA_VERSION变量值为0.17.2或任意所需版本保存并部署。此后站点构建并发布到 Cloudflare 网络可在 Pages 控制台添加自定义域名或修改设置。处理预览部署预览部署默认使用分支专属 URL如https://your-branch-name.your-project.pages.dev。若zola.toml中写死了base_url预览页面的资源加载会出错。解决办法是把 Cloudflare Pages 的构建命令改为按环境动态设置if [ $CF_PAGES_BRANCH main ]; then zola build; else zola build --base-url $CF_PAGES_URL; fi从 main 分支构建时使用zola.toml中的base_url其他分支使用 Cloudflare Pages 自动提供的$CF_PAGES_URL作为 base URL。Cloudflare WorkersWrangler 构建钩子若更偏好 Workers 形态Cloudflare 同样支持连接 Git 仓库自动部署原文见 cloudflare-workers.md核心是在仓库中准备构建脚本与 Wrangler 配置让默认命令npx wrangler deploy触发构建。创建构建脚本build.shCloudflare 克隆仓库时不会递归拉取 submodule因此脚本需自行处理子模块更新例如主题。在仓库根目录添加#!/usr/bin/env bash main() { ZOLA_VERSION0.22.1 curl -sLJO https://github.com/getzola/zola/releases/download/v${ZOLA_VERSION}/zola-v${ZOLA_VERSION}-x86_64-unknown-linux-gnu.tar.gz tar -xf zola-v${ZOLA_VERSION}-x86_64-unknown-linux-gnu.tar.gz git submodule update --init --recursive ./zola build } set -euo pipefail添加wrangler.toml在项目根目录创建wrangler.toml指向构建脚本与产物目录。name与compatibility_date是 Wrangler 的必填项分别使用你的站点名与当前日期name blog compatibility_date 2026-01-22 [build] command bash ./build.sh [assets] directory ./public创建 Worker登录 Cloudflare在导航栏选择Workers and Pages点击Create a project选择包含 Zola 站点的 GitHub 或 GitLab 仓库并连接保持默认设置点击Deploy。站点即被构建并部署到 Cloudflare 网络之后可在 Workers 控制台添加自定义域名或修改设置。AWS S3 CloudFront对象存储托管与 CDN 加速Amazon S3 是提供静态网站托管能力的对象存储服务。下面是在 GitHub Actions 中构建并部署 Zola 站点到 S3 的完整流程原文见 aws-s3.md若配合 CloudFront 还可获得全局 CDN 加速与自定义域名。AWS 侧准备创建存储桶并开启静态网站托管按 AWS 官方入门指南创建 bucket 并正确配置静态网站托管创建最小权限 IAM 策略在 AWS 控制台进入IAM Policies Create policy切换到JSON视图并粘贴以下内容注意把Bucket-Name替换为你的 bucket 名{ Version: 2012-10-17, Statement: [ { Sid: AccessToWebsiteBuckets, Effect: Allow, Action: [ s3:PutBucketWebsite, s3:PutObject, s3:PutObjectAcl, s3:GetObject, s3:ListBucket, s3:DeleteObject ], Resource: [ arn:aws:s3:::Bucket-Name, arn:aws:s3:::Bucket-Name/* ] }, { Sid: AccessToCloudfront, Effect: Allow, Action: [cloudfront:GetInvalidation, cloudfront:CreateInvalidation], Resource: * } ] }AccessToCloudfront部分仅在需要 CloudFront 加速时才需要否则可删除。创建 IAM 用户进入IAM Users创建用户如命名github-actions-user在Set permissions步骤选择Attach policies directly并勾选刚才创建的策略生成访问密钥在用户列表点击该用户打开Security Credentials标签在Access keys下选择Create access key用途选择Command Line Interface (CLI)记录Access key ID与Secret access key。在 GitHub 中配置 Secrets在仓库Settings Secrets and variables Actions中添加 Repository secretsAWS_ACCESS_KEY_ID上一步的 Access key IDAWS_SECRET_ACCESS_KEY上一步的 Secret access keyS3_BUCKETbucket 名称CLOUDFRONT_DISTRIBUTION_ID若创建了 CloudFront 分发包则添加。GitHub Actions 工作流在仓库创建.github/workflows/publish.ymlname: Build and Publish to AWS on: push: branches: - main jobs: run: runs-on: ubuntu-latest timeout-minutes: 10 steps: - uses: actions/checkoutv3 - uses: taiki-e/install-actionv2 with: tool: zola0.17.2 - name: Build run: zola build - uses: reggionick/s3-deployv4 env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} with: folder: public bucket: ${{ secrets.S3_BUCKET }} private: true bucket-region: us-east-1 # 仅当创建了 CloudFront 分发包时使用以下两项 dist-id: ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} invalidation: /*若希望在其他分支触发或其他行为可修改on.push.branches中的分支名。Azure Static Web Apps托管服务 GitHub ActionsAzure Static Web Apps 是 Azure 的托管服务可从 GitHub 或 Azure DevOps 仓库的变更自动部署静态站点原文见 azure-static-webapps.md。在 Azure 门户创建应用按 Azure 官方文档在门户中创建 Static Web App选择GitHub作为代码托管平台唯一需要注意的是Build Details部分将App location设置为./public这是zola build默认输出目录其余留空。创建完成后记下 Azure 自动分配的域名并把仓库zola.toml中的base_url更新为该 URL。配置 GitHub ActionsAzure 会在仓库中自动生成.github/workflows下的 YAML 工作流并配置部署 secrets。需要做的只是补充“安装 Zola 并构建”的步骤# .github/workflows/azure-static-web-apps-web-app-name name: Azure Static Web Apps CI/CD on: push: branches: - main pull_request: types: [opened, synchronize, reopened, closed] branches: - main jobs: build_and_deploy_job: if: github.event_name push || (github.event_name pull_request github.event.action ! closed) runs-on: ubuntu-latest name: Build and Deploy Job steps: - uses: actions/checkoutv3 with: submodules: true lfs: false - uses: taiki-e/install-actionv2 with: tool: zola0.21.0 - name: Build Static Site run: zola build - name: Build And Deploy id: builddeploy uses: Azure/static-web-apps-deployv1 with: azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_WEB_APP_NAME }} repo_token: ${{ secrets.GITHUB_TOKEN }} # 用于 GitHub 集成如 PR 评论 action: upload # 仓库/构建配置 app_location: ./public # App 源码路径 api_location: # API 源码路径 - 可选 output_location: # 构建产物目录 - 可选 close_pull_request_job: if: github.event_name pull_request github.event.action closed runs-on: ubuntu-latest name: Close Pull Request Job steps: - name: Close Pull Request id: closepullrequest uses: Azure/static-web-apps-deployv1 with: azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKENWEB_APP_NAME }} action: close推送 YAML 变更后GitHub 会自动触发工作流部署站点。工作流中的close_pull_request_job负责在 PR 关闭时清理预览环境。EdgioCLI 一键部署Edgio原 Layer0提供基于 CLI 的极简部署流程原文见 edgio.md。# 1. 安装 Edgio CLI npm i -g edgio/cli # 2. 在项目根目录创建 package.json npm init -y # 3. 初始化项目 edgio initedgio init会生成routes.js将其内容改为托管public目录// This file was added by edgio init. // You should commit this file to source control. import { Router } from edgio/core/router export default new Router().static(public)然后构建并部署zola build edgio deployZeabur零配置的托管式部署Zeabur 提供自动 SSL 证书与全球边缘网络分发部署 Zola 站点几乎无需任何配置原文见 zeabur.md。前置条件本地已有 Zola 站点项目GitHub 账号与托管站点的仓库Zeabur 账号。创建项目登录 Zeabur 控制台点击Create Project按提示完成设置推送代码在项目目录初始化 Git 并推送到 GitHubgit init git add . git commit -m Initial commit git remote add origin your-github-repo-url git branch -M main git push -u origin main创建服务在控制台点击Create Service选择git选项连接 GitHub 仓库选择仓库从列表中选择存放 Zola 项目的仓库自动部署Zeabur 会自动识别 Zola 项目并完成部署无需额外配置。如需指定版本在项目设置的环境变量中添加ZOLA_VERSION如0.17.2绑定域名部署完成后为服务绑定域名可使用免费的.zeabur.app子域名或自定义域名Zeabur 会自动为域名签发免费 SSL 证书站点上线访问绑定的域名即可看到部署结果。部署方案速览与选择建议平台构建方式输出目录约定版本控制预览/PR 支持要点Docker多阶段镜像public复制进镜像镜像 tag无base_url需设为/才能多环境复用GitHub PagesActions artifact 或gh-pages分支publicGitHub Action随分支需在设置中启用 Actions 发布源GitLab PagesGitLab CI/CDpublicartifactZOLA_VERSION随分支/PR用$CI_PAGES_URL覆盖base_urlCodeberg PagesWoodpecker CIpublic→pages分支环境变量随分支需write:repository令牌Sourcehut Pages.build.yml清单public打包上传hut工具随推送oauth: pages.sr.ht/PAGES:RWNetlify平台自动构建publicZOLA_VERSION$DEPLOY_PRIME_URL支持纯手动curl上传Vercel平台自动构建publicZOLA_VERSION随分支glibc 问题可用 musl 二进制解决Cloudflare Pages平台自动构建预设自动填充ZOLA_VERSION$CF_PAGES_URL构建命令可做分支判断Cloudflare Workersbuild.sh Wranglerpublicassets脚本内ZOLA_VERSION随分支需自建构建钩子AWS S3GitHub Actionspubliczola版本无IAM 最小权限 可选 CloudFrontAzure Static Web AppsGitHub Actions./publicApp locationzola版本PR 自动预览/关闭Azure 自动生成工作流Fly.io容器构建public复制进镜像镜像 tag无flyctl deploy发布EdgioCLIpublic路由静态目录edgio init随分支edgio deploy一键上线Zeabur平台自动识别publicZOLA_VERSION随分支免费 SSL、边缘网络选择建议代码已托管在 GitHub/GitLab 且想少维护 CI→ 优先 Netlify、Vercel、Cloudflare Pages、Zeabur 等 PaaS 平台对 CI 过程有强控制需求→ GitHub Pages / GitLab Pages 的分支发布模式或自写 GitHub ActionsAWS S3 / Azure 方案需要容器化、Kubernetes 部署或离线分发→ Docker 多阶段构建方案已有特定云厂商预算/合规要求→ 按厂商方案AWS S3、Azure Static Web Apps、Fly.io、Cloudflare Workers选择。延伸阅读部署总览纯静态输出模型的官方说明目录结构构建前应了解的 Zola 标准目录布局配置参考base_url等核心配置项的完整说明命令行用法zola build/zola serve的日常使用src/cli.rsbuild/serve子命令全部参数--base-url、--output-dir、--force、--drafts、--minify等的源码定义【免费下载链接】zolaA fast static site generator in a single binary with everything built-in. https://www.getzola.org项目地址: https://gitcode.com/GitHub_Trending/zo/zola创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考