跳到主要内容

部署

要构建网站的静态文件以用于生产环境，请运行：

npm run build

完成后，静态文件将生成在 build 目录中。

备注

Docusaurus 的唯一职责是构建您的站点并在 build 中输出静态文件。

现在轮到您选择如何托管这些静态文件了。

您可以将您的站点部署到静态站点托管服务，例如 Vercel 、 GitHub Pages 、 Netlify 、 Render 和 Surge 。

Docusaurus 站点是静态渲染的，通常无需 JavaScript 即可运行！

配置​

在 docusaurus.config.js 中需要以下参数才能优化路由并从正确的位置提供文件：

名称描述
url您站点的 URL。对于部署在 https://my-org.com/my-project/ 的站点，url 为 https://my-org.com/。
baseUrl项目的基本 URL，带尾部斜杠。对于部署在 https://my-org.com/my-project/ 的站点，baseUrl 为 /my-project/。

本地测试构建​

在将构建部署到生产环境之前，对其进行本地测试非常重要。Docusaurus 提供了一个 docusaurus serve 命令来实现此目的：

npm run serve

默认情况下，这将在 http://localhost:3000/ 加载您的站点。

尾部斜杠配置​

Docusaurus 有一个 trailingSlash 配置 来允许自定义 URL/链接和输出的文件名模式。

默认值通常可以正常工作。不幸的是，每个静态托管提供商都有 不同的行为 ，将完全相同的站点部署到不同的主机可能会导致不同的结果。根据您的主机，更改此配置可能很有用。

提示

使用 slorber/trailing-slash-guide 更好地了解主机的行为并适当地配置 trailingSlash。

使用环境变量​

将潜在的敏感信息放入环境中是一种常见做法。但是，在典型的 Docusaurus 网站中，docusaurus.config.js 文件是 Node.js 环境的唯一接口（参见 我们的架构概述 ），而其他所有内容（MDX 页面、React 组件等）都是客户端，并且无法直接访问 process 全局变量。在这种情况下，您可以考虑使用 customFields 将环境变量传递到客户端。

docusaurus.config.js
// 如果你正在使用 dotenv (https://www.npmjs.com/package/dotenv)
import 'dotenv/config';

export default {
  title: '...',
  url: process.env.URL, // 你也可以使用环境变量来控制网站的细节
  customFields: {
    // 在这里放置您的自定义环境
    teamEmail: process.env.EMAIL,
  },
};
home.jsx
import useDocusaurusContext from '@docusaurus/useDocusaurusContext';

export default function Home() {
  const {
    siteConfig: {customFields},
  } = useDocusaurusContext();
  return <div>联系我们 {customFields.teamEmail}!</div>;
}

选择托管提供商​

有一些常见的托管选项：

  • 使用 Apache2 或 Nginx 等 HTTP 服务器进行 自托管 。
  • Jamstack 提供商（例如 Netlify 和 Vercel ）。我们将使用它们作为参考，但相同的推理也适用于其他提供商。
  • GitHub Pages （根据定义，它也是 Jamstack，但我们单独比较它）。

如果您不确定选择哪个，请提出以下问题：

我愿意投入多少资源（金钱、人时等）？

  • 🔴 自托管需要网络、Linux 和 Web 服务器管理方面的经验。这是最困难的选择，需要花费最多时间才能成功管理。在费用方面，云服务几乎从不免费，购买/部署本地服务器的成本甚至更高。
  • 🟢 Jamstack 提供商可以帮助您几乎立即设置一个有效的网站，并提供易于配置的服务器端重定向等功能。许多提供商即使对于您几乎永远不会超过的免费计划也提供慷慨的构建时间配额。但是，免费计划有限制，一旦达到这些限制，您就需要付费。查看提供商的定价页面了解详细信息。
  • 🟡 GitHub Pages 部署工作流程可能难以设置。（证据：参见 部署到 GitHub Pages 的长度！）但是，这项服务（包括构建和部署）对于公共存储库始终免费，我们提供了详细的说明来帮助您使其工作。
我需要多少服务器端定制？
  • 🟢 使用自托管，您可以访问整个服务器的配置。您可以配置虚拟主机以根据请求 URL 提供不同的内容，您可以进行复杂的服务器端重定向，您可以实现身份验证等等。如果您需要许多服务器端功能，请自行托管您的网站。
  • 🟡 Jamstack 通常提供一些服务器端配置（例如 URL 格式（尾部斜杠）、服务器端重定向等）。
  • 🔴 GitHub Pages 除了强制执行 HTTPS 和设置 CNAME 记录外，不公开服务器端配置。
我需要协作友好的部署工作流程吗？
  • 🟡 自托管服务可以利用 Netlify 等持续部署功能，但需要更多工作。通常，您会指定特定人员来管理部署，并且工作流程与其他两个选项相比不会非常基于 git。
  • 🟢 Netlify 和 Vercel 为每个拉取请求提供部署预览，这对于团队在合并到生产环境之前审查工作非常有用。您还可以管理一个具有不同成员对部署访问权限的团队。
  • 🟡 GitHub Pages 无法以非复杂的方式进行部署预览。一个存储库只能与一个站点部署相关联。另一方面，您可以控制谁有权访问站点的部署。

没有万能的解决方案。您需要权衡您的需求和资源才能做出选择。

自托管​

可以使用 docusaurus serve 自托管 Docusaurus。使用 --port 和 --host 更改端口以更改主机。

npm run serve -- --build --port 80 --host 0.0.0.0
注意

与静态托管提供商/CDN 相比，这不是最佳选择。

注意

在以下部分中，我们将介绍一些常见的托管提供商以及如何配置它们以最有效地部署 Docusaurus 站点。Docusaurus 与任何这些服务无关，此信息仅供方便之用。部分文章由第三方提供，我们这边可能没有反映最新的 API 更改。如果您看到过时的内容，欢迎提交 PR。

因为我们只能尽力提供这些内容，所以我们已停止接受添加新托管选项的 PR。但是，您可以在单独的站点（例如您的博客或提供商的官方网站）上发布您的文章，并要求我们包含指向您的文章的链接。

部署到 Netlify​

要将您的 Docusaurus 站点部署到 Netlify ，首先确保正确配置了以下选项：

docusaurus.config.js
export default {
  url: 'https://docusaurus-2.netlify.app', // 没有尾部斜杠的站点 URL
  baseUrl: '/', // 相对于您的仓库的站点基本目录
  // ...
};

然后， 使用 Netlify 创建您的站点 。

在设置站点时，请按如下方式指定构建命令和目录：

  • 构建命令：npm run build
  • 发布目录：build

如果您没有配置这些构建选项，您仍然可以在创建站点后转到“站点设置”->“构建和部署”。

一旦使用上述选项正确配置，您的站点应该会部署，并在合并到您的部署分支（默认为 main）时自动重新部署。

注意

一些 Docusaurus 站点将 docs 文件夹放在 website 文件夹之外（很可能是以前的 Docusaurus v1 站点）：

repo           # git 根目录
├── docs       # MD 文件
└── website    # Docusaurus 根目录

如果您决定将 website 文件夹用作 Netlify 的基本目录，则当您更新 docs 文件夹时，Netlify 将不会触发构建，您需要配置一个 自定义 ignore 命令 ：

website/netlify.toml
[build]
  ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF . ../docs/"
注意

默认情况下，Netlify 会向 Docusaurus URL 添加尾部斜杠。

建议禁用 Netlify 设置“后处理 > 资源优化 > 漂亮 URL”，以防止小写 URL、不必要的重定向和 404 错误。

请务必小心 ：禁用资源优化 全局复选框已损坏，实际上并没有禁用“漂亮 URL”设置。请确保 单独取消选中它。

如果您想保留 漂亮 URL Netlify 设置，请相应地调整 trailingSlash Docusaurus 配置。

有关更多信息，请参阅 slorber/trailing-slash-guide 。

部署到 Vercel​

将您的 Docusaurus 项目部署到 Vercel 将在性能和易用性方面为您提供 各种优势 。

要使用 Vercel for Git 集成 部署您的 Docusaurus 项目，请确保它已推送到 Git 存储库。

使用 导入流程 将项目导入 Vercel。在导入过程中，您会发现所有相关的选项都已为您预先配置；但是，您可以选择更改任何这些 选项 。

项目导入后，所有后续对分支的推送都将生成 预览部署 ，并且对 生产分支 （通常为“main”或“master”）所做的所有更改都将导致 生产部署 。

部署到 GitHub Pages​

Docusaurus 提供了一种简单的方法来发布到 GitHub Pages ，每个 GitHub 存储库都免费提供。

概述​

通常，发布过程中涉及两个存储库（至少两个分支）：包含源文件的分支和包含将与 GitHub Pages 一起提供的构建输出的分支。在以下教程中，它们将分别称为 “源” 和 “部署” 。 每个 GitHub 存储库都与一个 GitHub Pages 服务相关联。如果部署存储库名为 my-org/my-project（其中 my-org 是组织名称或用户名），则部署的站点将显示在 https://my-org.github.io/my-project/。如果部署存储库名为 my-org/my-org.github.io（组织 GitHub Pages 存储库），则站点将显示在 https://my-org.github.io/。

信息

如果您想为 GitHub Pages 使用自定义域名，请在 static 目录中创建一个 CNAME 文件。static 目录中的任何内容都将复制到 build 目录的根目录以进行部署。使用自定义域名时，您应该能够从 baseUrl: '/projectName/' 返回到 baseUrl: '/'，并将其 url 设置为您的自定义域名。

您可以参考 GitHub Pages 的文档 用户、组织和项目页面 了解更多详细信息。

GitHub Pages 从默认分支（master / main，通常）或 gh-pages 分支中获取部署就绪文件（来自 docusaurus build 的输出），以及来自根目录或 /docs 文件夹。您可以通过存储库中的“设置 > Pages”进行配置。此分支将被称为“部署分支”。

我们提供了一个 docusaurus deploy 命令，它可以帮助您通过一个命令将站点从源分支部署到部署分支：克隆、构建和提交。

docusaurus.config.js 设置​

首先，修改您的 docusaurus.config.js 并添加以下参数：

名称描述
organizationName拥有部署存储库的 GitHub 用户或组织。
projectName部署存储库的名称。
deploymentBranch部署分支的名称。对于非组织 GitHub Pages 存储库（projectName 不以 .github.io 结尾），它默认为 'gh-pages'。否则，它需要作为配置字段或环境变量明确指定。

这些字段也有其环境变量对应项，它们具有更高的优先级：ORGANIZATION_NAME、PROJECT_NAME 和 DEPLOYMENT_BRANCH。

注意

GitHub Pages 默认情况下会向 Docusaurus URL 添加尾部斜杠。建议设置 trailingSlash 配置（true 或 false，而不是 undefined）。

示例：

docusaurus.config.js
export default {
  // ...
  url: 'https://endiliey.github.io', // 您的网站 URL
  baseUrl: '/',
  projectName: 'endiliey.github.io',
  organizationName: 'endiliey',
  trailingSlash: false,
  // ...
};
注意

默认情况下，GitHub Pages 会通过 Jekyll 运行已发布的文件。由于 Jekyll 会丢弃任何以 _ 开头的文件，因此建议您通过在 static 目录中添加一个名为 .nojekyll 的空文件来禁用 Jekyll。

环境设置​

名称描述
USE_SSH设置为 true 以使用 SSH 代替默认的 HTTPS 连接到 GitHub 存储库。如果源存储库 URL 是 SSH URL（例如 git@github.com:facebook/docusaurus.git），则 USE_SSH 被推断为 true。
GIT_USER具有对部署存储库的推送访问权限 的 GitHub 帐户的用户名。对于您自己的存储库，这通常是您的 GitHub 用户名。如果不使用 SSH，则需要此项，否则将被忽略。
GIT_PASSgit 用户（由 GIT_USER 指定）的个人访问令牌，用于促进非交互式部署（例如持续部署）
CURRENT_BRANCH源分支。通常，分支将是 main 或 master，但它可以是除 gh-pages 之外的任何分支。如果未为此变量设置任何内容，则将使用调用 docusaurus deploy 的当前分支。
GIT_USER_NAME推送到部署存储库时使用的 git config user.name 值
GIT_USER_EMAIL推送到部署存储库时使用的 git config user.email 值

GitHub 企业版安装应该与 github.com 以相同的方式工作；您只需要将组织的 GitHub 企业版主机设置为环境变量：

名称描述
GITHUB_HOST您 GitHub 企业版站点的域名。
GITHUB_PORT您 GitHub 企业版站点的端口。

部署​

最后，要将您的站点部署到 GitHub Pages，请运行：

GIT_USER=<GITHUB_USERNAME> yarn deploy
注意

从 2021 年 8 月开始，GitHub 要求每个命令行登录都使用 个人访问令牌 而不是密码。当 GitHub 提示您输入密码时，请改输入 PAT。有关更多信息，请参见 GitHub 文档 。

或者，您可以使用 SSH (USE_SSH=true) 登录。

使用 GitHub Actions 触发部署​

GitHub Actions 允许您直接在存储库中自动化、自定义和执行软件开发工作流。

下面的工作流示例假定您的网站源位于存储库的 main 分支中（源分支 为 main），并且您的 发布源 已配置为 使用自定义 GitHub Actions 工作流进行发布 。

我们的目标是：

  1. 当向 main 发出新的拉取请求时，有一个操作可以确保站点成功构建，而无需实际部署。此作业将被称为 test-deploy。
  2. 当拉取请求合并到 main 分支或有人直接推送到 main 分支时，它将被构建并部署到 GitHub Pages。此作业将被称为 deploy。

以下有两种使用 GitHub Actions 部署文档的方法。根据部署存储库的位置，选择下面的相关选项卡：

  • 源存储库和部署存储库是 同一个 存储库。
  • 部署存储库是 远程 存储库，与源存储库不同。此方案的说明假设 发布源 是 gh-pages 分支。

虽然您可以在同一个工作流文件中定义这两个作业，但原始的 deploy 工作流将始终在 PR 检查套件状态中列为已跳过，这并不表示实际状态，并且对审查过程没有任何价值。因此，我们建议将它们作为单独的工作流来管理。

GitHub action 文件

添加这两个工作流文件：

微调您的设置参数

这些文件假定您使用的是 Yarn。如果您使用 npm，请相应地将 cache: yarn、yarn install --frozen-lockfile、yarn build 更改为 cache: npm、npm ci、npm run build。

如果您的 Docusaurus 项目不在存储库的根目录下，则可能需要配置 默认工作目录 ，并相应地调整路径。

.github/workflows/deploy.yml
name: Deploy to GitHub Pages

on:
  push:
    branches:
      - main
    # Review gh actions docs if you want to further define triggers, paths, etc
    # https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on

jobs:
  build:
    name: Build Docusaurus
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn

      - name: Install dependencies
        run: yarn install --frozen-lockfile
      - name: Build website
        run: yarn build

      - name: Upload Build Artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: build

  deploy:
    name: Deploy to GitHub Pages
    needs: build

    # Grant GITHUB_TOKEN the permissions required to make a Pages deployment
    permissions:
      pages: write # to deploy to Pages
      id-token: write # to verify the deployment originates from an appropriate source

    # Deploy to the github-pages environment
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

    runs-on: ubuntu-latest
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4
.github/workflows/test-deploy.yml
name: Test deployment

on:
  pull_request:
    branches:
      - main
    # Review gh actions docs if you want to further define triggers, paths, etc
    # https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on

jobs:
  test-deploy:
    name: Test deployment
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn

      - name: Install dependencies
        run: yarn install --frozen-lockfile
      - name: Test build website
        run: yarn build
站点未正确部署？

推送到 main 分支后，如果您没有在所需位置看到您的站点已发布（例如，它显示“此处没有 GitHub Pages 站点”，或者它显示您的 repo 的 README.md 文件），请尝试以下操作：

  • 等待大约三分钟然后刷新。GitHub Pages 可能需要几分钟时间才能获取新文件。
  • 检查您的 repo 的登录页面，查看上次提交标题旁边的绿色勾号，指示 CI 已通过。如果您看到一个叉号，则表示构建或部署失败，您应该检查日志以获取更多调试信息。
  • 单击勾号，确保您看到一个“部署到 GitHub Pages”工作流。诸如“pages 构建和部署/部署”之类的名称是 GitHub 的默认工作流，表明您的自定义部署工作流根本没有被触发。确保 YAML 文件位于 .github/workflows 文件夹下，并且触发条件已正确设置（例如，如果您的默认分支是“master”而不是“main”，则需要更改 on.push 属性）。
  • 在您的 repo 的设置 > Pages 下，确保“源”（这是_部署_文件的源，而不是我们术语中的“源”）设置为“gh-pages”+“/ (root)” ，因为我们使用 gh-pages 作为部署分支。

如果您使用的是自定义域名：

  • 如果您使用的是自定义域名，请验证您是否已设置正确的 DNS 记录。请参阅 GitHub Pages 关于配置自定义域的文档 。此外，请注意，DNS 更改可能需要长达 24 小时才能在互联网上传播。

使用 Travis CI 触发部署​

持续集成 (CI) 服务通常用于在将新的提交检入到源代码管理时执行例行任务。这些任务可以是运行单元测试和集成测试、自动化构建、将包发布到 npm 以及将更改部署到您的网站的任何组合。您只需在更新网站时调用 yarn deploy 脚本即可自动化网站的部署。以下部分介绍了如何使用流行的持续集成服务提供商 Travis CI 来做到这一点。

  1. 前往 https://github.com/settings/tokens 并生成新的 个人访问令牌 。创建令牌时，请授予其 repo 范围，以便它拥有所需的权限。
  2. 使用您的 GitHub 帐户，将 Travis CI 应用 添加到您要激活的存储库。
  3. 打开您的 Travis CI 仪表板。URL 看起来像 https://travis-ci.com/USERNAME/REPO，然后导航到存储库的“更多选项 > 设置 > 环境变量”部分。
  4. 创建一个名为 GH_TOKEN 的新环境变量，其值为新生成的令牌，然后是 GH_EMAIL（您的电子邮件地址）和 GH_NAME（您的 GitHub 用户名）。
  5. 在存储库的根目录中创建一个 .travis.yml，内容如下：
.travis.yml
language: node_js
node_js:
  - 18
branches:
  only:
    - main
cache:
  yarn: true
script:
  - git config --global user.name "${GH_NAME}"
  - git config --global user.email "${GH_EMAIL}"
  - echo "machine github.com login ${GH_NAME} password ${GH_TOKEN}" > ~/.netrc
  - yarn install
  - GIT_USER="${GH_NAME}" yarn deploy

现在，每当新的提交进入 main 时，Travis CI 都会运行您的测试套件，如果一切顺利，您的网站将通过 yarn deploy 脚本进行部署。

使用 Buddy 触发部署​

Buddy 是一款易于使用的 CI/CD 工具，允许您将门户自动部署到不同的环境，包括 GitHub Pages。

按照以下步骤创建管道，以便每当您将更改推送到项目的选定分支时，它都会自动部署网站的新版本：

  1. 前往 https://github.com/settings/tokens 并生成新的 个人访问令牌 。创建令牌时，请授予其 repo 范围，以便它拥有所需的权限。
  2. 登录您的 Buddy 帐户并创建一个新项目。
  3. 选择 GitHub 作为您的 git 托管提供商，然后选择包含网站代码的存储库。
  4. 使用左侧导航面板，切换到“管道”视图。
  5. 创建一个新的管道。定义其名称，将触发模式设置为“推送时”，然后选择触发管道执行的分支。
  6. 添加一个“Node.js”操作。
  7. 在操作的终端中添加以下命令：
GIT_USER=<GH_PERSONAL_ACCESS_TOKEN>
git config --global user.email "<YOUR_GH_EMAIL>"
git config --global user.name "<YOUR_GH_USERNAME>"
yarn deploy

创建此简单的管道后，推送到您选择的分支的每个新提交都会使用 yarn deploy 将您的网站部署到 GitHub Pages。阅读 本指南 了解有关为 Docusaurus 设置 CI/CD 管道的更多信息。

使用 Azure Pipelines​

  1. 如果你还没有，请在 Azure Pipelines 注册。
  2. 创建一个组织。在组织内，创建一个项目并从 GitHub 连接您的存储库。
  3. 前往 https://github.com/settings/tokens 并使用 repo 范围生成新的 个人访问令牌 。
  4. 在项目页面（看起来像 https://dev.azure.com/ORG_NAME/REPO_NAME/_build）中，使用以下文本创建一个新管道。此外，单击“编辑”并添加一个名为 GH_TOKEN 的新环境变量，其值为新生成的令牌，然后是 GH_EMAIL（您的电子邮件地址）和 GH_NAME（您的 GitHub 用户名）。确保将它们标记为机密。或者，您也可以在存储库根目录添加一个名为 azure-pipelines.yml 的文件。
azure-pipelines.yml
trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - checkout: self
    persistCredentials: true

  - task: NodeTool@0
    inputs:
      versionSpec: '18'
    displayName: 安装 Node.js

  - script: |
      git config --global user.name "${GH_NAME}"
      git config --global user.email "${GH_EMAIL}"
      git checkout -b main
      echo "machine github.com login ${GH_NAME} password ${GH_TOKEN}" > ~/.netrc
      yarn install
      GIT_USER="${GH_NAME}" yarn deploy
    env:
      GH_NAME: $(GH_NAME)
      GH_EMAIL: $(GH_EMAIL)
      GH_TOKEN: $(GH_TOKEN)
    displayName: 安装和构建

使用 Drone​

  1. 创建一个新的 SSH 密钥，它将作为项目的 部署密钥 。
  2. 将您的私钥和公钥命名为特定名称，以便它不会覆盖您的其他 SSH 密钥 。
  3. 前往 https://github.com/USERNAME/REPO/settings/keys 并通过粘贴您刚刚生成的公钥来添加新的部署密钥。
  4. 打开您的 Drone.io 仪表板并登录。URL 看起来像 https://cloud.drone.io/USERNAME/REPO。
  5. 单击存储库，单击激活存储库，并使用您刚刚生成的私钥值添加名为 git_deploy_private_key 的密钥。
  6. 在存储库的根目录中创建一个 .drone.yml，内容如下。
.drone.yml
kind: pipeline
type: docker
trigger:
  event:
    - tag
- name: 网站
  image: node
  commands:
    - mkdir -p $HOME/.ssh
    - ssh-keyscan -t rsa github.com >> $HOME/.ssh/known_hosts
    - echo "$GITHUB_PRIVATE_KEY" > "$HOME/.ssh/id_rsa"
    - chmod 0600 $HOME/.ssh/id_rsa
    - cd website
    - yarn install
    - yarn deploy
  environment:
    USE_SSH: true
    GITHUB_PRIVATE_KEY:
      from_secret: git_deploy_private_key

现在，每当您向 GitHub 推送新标签时，此触发器都会启动无人机 CI 作业以发布您的网站。

部署到 Flightcontrol​

Flightcontrol 是一项服务，可直接从您的 Git 存储库自动构建并将您的 Web 应用部署到 AWS Fargate。它让您可以完全访问检查和进行基础设施更改，而不会受到传统 PaaS 的限制。

请按照 Flightcontrol 的分步式 Docusaurus 指南 开始使用。

部署到 Koyeb​

Koyeb 是一个面向开发人员的无服务器平台，用于在全球范围内部署应用程序。该平台使您可以通过基于 git 的部署、本地自动缩放、全球边缘网络以及内置的服务网格和发现来无缝运行 Docker 容器、Web 应用程序和 API。查看 Koyeb 的 Docusaurus 部署指南 以开始使用。

部署到 Render​

Render 提供 免费的静态站点托管 ，具有完全托管的 SSL、自定义域名、全球 CDN 以及来自您的 Git 存储库的持续自动部署。按照 Render 部署 Docusaurus 的指南 只需几分钟即可开始使用。

部署到 Qovery​

Qovery 是一个完全托管的云平台，运行在您的 AWS、Digital Ocean 和 Scaleway 帐户上，您可以在其中在一个地方托管静态站点、后端 API、数据库、cron 作业以及所有其他应用程序。

  1. 创建 Qovery 帐户。如果您还没有帐户，请访问 Qovery 仪表板 创建帐户。
  2. 创建项目。
    • 点击 创建项目 并为您的项目命名。
    • 点击 下一步 。
  3. 创建新的环境。
    • 点击 创建环境 并命名（例如 staging、production）。
  4. 添加应用程序。
    • 点击 创建应用程序 ，命名并选择您的 Docusaurus 应用所在的 GitHub 或 GitLab 存储库。
    • 定义主分支名称和根应用程序路径。
    • 点击 创建 。应用程序创建后：
    • 导航到您的应用程序设置
    • 选择端口
    • 添加您的 Docusaurus 应用程序使用的端口
  5. 部署
    • 您现在只需导航到您的应用程序并点击 部署 即可。

部署应用程序

就是这样。查看状态并等待应用程序部署完成。要在浏览器中打开应用程序，请在应用程序概述中点击 操作 和 打开 。

部署到 Hostman​

Hostman 允许您免费托管静态网站。Hostman 自动化所有操作，您只需要连接您的存储库并按照以下简单步骤操作：

  1. 创建服务。

    • 要部署 Docusaurus 静态网站，请点击 仪表板 左上角的 创建 ，然后选择 前端应用或静态网站 。

  2. 选择要部署的项目。

    • 如果你使用 GitHub、GitLab 或 Bitbucket 帐户登录 Hostman，你将看到包含你的项目的存储库，包括私有项目。

    • 选择您要部署的项目。它必须包含包含项目文件的目录（例如 website）。

    • 要访问不同的存储库，请点击 连接另一个存储库 。

    • 如果你没有使用你的 Git 帐户凭据登录，你现在可以访问必要的帐户，然后选择项目。

  3. 配置构建设置。

    • 接下来，将出现 网站自定义 窗口。从框架列表中选择 静态网站 选项。

    • 包含应用程序的目录 指向构建后将包含项目文件的目录。如果您在步骤 2 中选择了包含网站内容（或 my_website 目录）的存储库，则可以将其留空。

    • Docusaurus 的标准构建命令是：

      npm run build

    • 如有必要，您可以修改构建命令。您可以输入多个命令，命令之间用 && 分隔。

  4. 部署。

    • 点击 部署 以启动构建过程。

    • 启动后，您将进入部署日志。如果代码有任何问题，您将在日志中收到警告或错误消息，其中指定问题的根本原因。通常，日志包含您需要的所有调试数据。

    • 部署完成后，您将收到电子邮件通知，还会看到日志条目。全部完成！您的项目已启动并准备就绪。

部署到 Surge​

Surge 是一个 静态 Web 托管平台 ，您可以使用它在几秒钟内从命令行部署 Docusaurus 项目。将您的项目部署到 Surge 很容易且免费（包括自定义域名和 SSL 证书）。

按照以下步骤，使用 Surge 在几秒钟内部署您的应用程序：

  1. 首先，使用 npm 安装 Surge，运行以下命令： 
    npm install -g surge
  2. 要在项目根目录中构建站点的静态文件以用于生产环境，请运行： 
    npm run build
  3. 然后，在项目根目录中运行此命令： 
    surge build/

Surge 的首次使用者将被提示从命令行创建帐户（只发生一次）。

确认您要发布的站点位于 build 目录中。始终会提供随机生成的子域名 *.surge.sh 子域名（可以编辑）。

使用您的域名​

如果您有域名，您可以使用以下命令部署您的站点：

surge build/ your-domain.com

您的站点现在已免费部署在 subdomain.surge.sh 或 your-domain.com 上，具体取决于您选择的方法。

设置 CNAME 文件​

使用以下命令将您的域名存储在 CNAME 文件中，以便将来进行部署：

echo subdomain.surge.sh > CNAME

将来，您可以使用命令 surge 部署任何其他更改。

部署到 Stormkit​

您可以将 Docusaurus 项目部署到 Stormkit ，这是一个用于静态网站、单页应用程序 (SPA) 和无服务器函数的部署平台。有关详细说明，请参阅此 指南 。

部署到 QuantCDN​

  1. 安装Quant CLI
  2. 通过 注册 创建一个 QuantCDN 帐户
  3. 使用 quant init 初始化您的项目并填写您的凭据： 
    quant init
  4. 部署您的站点。 
    quant deploy

有关部署到 QuantCDN 的更多示例和用例，请参阅 文档 和 博客 。

部署到 Layer0​

Layer0 是一个多合一平台，用于开发、部署、预览、实验、监控和运行您的无头前端。它专注于大型动态网站和一流的性能，通过 EdgeJS（基于 JavaScript 的内容交付网络）、预测预取和性能监控来实现。Layer0 提供免费层级。按照 Layer0 部署 Docusaurus 的指南 只需几分钟即可开始使用。

部署到 Cloudflare Pages​

Cloudflare Pages 是一个面向前端开发人员的 Jamstack 平台，用于协作和部署网站。按照 这篇文章 只需几分钟即可开始使用。

部署到 Azure 静态 Web 应用​

Azure 静态 Web 应用 是一项服务，可直接从代码存储库自动构建并将全栈 Web 应用部署到 Azure，从而简化了 CI/CD 的开发人员体验。静态 Web 应用将 Web 应用程序的静态资产与其动态 (API) 端点分开。静态资产从全球分布式内容服务器提供服务，使客户端能够更快地使用附近的服务器检索文件。动态 API 使用基于事件的函数方法通过无服务器架构进行扩展，这种方法更具成本效益，并且可以按需扩展。按照 此分步指南 只需几分钟即可开始使用。

部署到 Kinsta​

Kinsta 静态站点托管 允许您免费部署多达 100 个静态站点，包括带有 SSL 的自定义域名、每月 100 GB 带宽和 260 多个 Cloudflare CDN 位置。

按照我们的 Kinsta 上的 Docusaurus 文章只需点击几下即可开始使用。

编辑此页
最后由 HomeUbuntu 于 更新