跳到主要内容

部署

要为生产环境构建网站的静态文件,请运行:

npm run build

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

备注

Docusaurus 的唯一职责是构建你的站点并在 build 中生成静态文件。

现在由你来选择如何托管这些静态文件。

你可以将站点部署到静态站点托管服务,如 VercelGitHub PagesNetlifyRenderSurge

Docusaurus 站点是静态渲染的,通常可以在没有 JavaScript 的情况下工作!

配置

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

名称描述
url你的站点的 URL。对于部署在 https://my-org.com/my-project/ 的站点,urlhttps://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 提供商(例如 NetlifyVercel)。我们将以它们为参考,但相同的推理也适用于其他提供商。
  • 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 的基本目录,Netlify 将不会在更新 docs 文件夹时触发构建,你需要配置自定义 ignore 命令

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

默认情况下,Netlify 会为 Docusaurus URL 添加尾随斜杠。

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

请非常小心:全局复选框 禁用资源优化 是损坏的,实际上并不真正禁用 漂亮的 URL 设置。请确保独立取消选中它

如果你想保持 Netlify 的 漂亮的 URL 设置,请适当调整 Docusaurus 的 trailingSlash 配置。

请参考 slorber/trailing-slash-guide 了解更多信息。

部署到 Vercel

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

要使用 Vercel 的 Git 集成部署你的 Docusaurus 项目,请确保它已推送到 Git 仓库。

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

项目导入后,所有后续推送到分支的操作都将生成预览部署,对生产分支(通常是 "main" 或 "master")所做的所有更改都将导致生产部署

部署到 GitHub Pages

Docusaurus 提供了一种简单的方法来发布到 GitHub Pages,每个 GitHub 仓库都有免费的 GitHub Pages 服务。

概述

通常,发布过程涉及两个仓库(至少两个分支):包含源文件的分支和包含要由 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 分支,以及根目录或 /docs 文件夹中获取可部署的文件(docusaurus build 的输出)。你可以通过仓库的 设置 > 页面 进行配置。这个分支将被称为"部署分支"。

我们提供 docusaurus deploy 命令,帮助你从源分支一次性部署站点到部署分支:克隆、构建和提交。

docusaurus.config.js 设置

首先,修改你的 docusaurus.config.js 并添加以下参数:

名称描述
organizationName部署仓库的 GitHub 用户或组织。
projectName部署仓库的名称。
deploymentBranch部署分支的名称。它默认为 'gh-pages' 对于非组织 GitHub Pages 仓库(projectName 不以 .github.io 结尾)。否则,需要明确为配置字段或环境变量。

这些字段也有其环境变量对应项,优先级更高:ORGANIZATION_NAMEPROJECT_NAMEDEPLOYMENT_BRANCH

注意

GitHub Pages 默认情况下为 Docusaurus URL 添加尾随斜杠。建议设置 trailingSlash 配置(truefalse,不是 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 将丢弃任何以 _ 开头的文件,建议你禁用 Jekyll 并添加一个空文件名为 .nojekyll 文件到你的 static 目录。

环境设置

名称描述
USE_SSH设置为 true 以使用 SSH 而不是默认的 HTTPS 连接到 GitHub 仓库。如果源仓库 URL 是 SSH URL(例如 git@github.com:facebook/docusaurus.git),则 USE_SSH 被推断为 true
GIT_USER具有推送访问权限的 GitHub 帐户的 GitHub 用户名。对于你自己的仓库,这通常是你自己的 GitHub 用户名。如果未使用 SSH,则需要。
GIT_PASS用于非交互式部署(例如持续部署)的 git 用户的个人访问令牌(由 GIT_USER 指定)
CURRENT_BRANCH源分支。通常,分支将是 mainmaster,但可以是任何分支,除了 gh-pages。如果未设置此变量,则从调用 docusaurus deploy 的当前分支中使用。
GIT_USER_NAME用于推送部署仓库的 git config user.name
GIT_USER_EMAIL用于推送部署仓库的 git config user.email

GitHub 企业安装应与 github.com 相同;你只需要设置组织 GitHub Enterprise 主机作为环境变量:

名称描述
GITHUB_HOST你的 GitHub Enterprise 站点的域名。
GITHUB_PORT你的 GitHub Enterprise 站点的端口。

部署

最后,要部署你的站点到 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 files

添加这两个工作流文件:

调整参数以适应你的设置

如果 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: npm

- name: Install dependencies
run: npm ci
- name: Build website
run: npm 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: npm

- name: Install dependencies
run: npm ci
- name: Test build website
run: npm build
站点未正确部署?

推送后,如果看不到你的站点发布到所需位置(例如,它说“这里没有 GitHub Pages 站点”,或者它显示你的仓库的 README.md 文件),请尝试以下操作:

  • 等待大约三分钟并刷新。可能需要几分钟才能让 GitHub pages 获取新文件。
  • 检查你的仓库的登录页面,查看最后一个提交标题旁边是否有小绿勾,表示 CI 已通过。如果你看到交叉,则表示构建或部署失败,你应该检查日志以获取更多调试信息。
  • 点击勾并确保你看到一个“部署到 GitHub Pages”工作流。名称如“pages build and deployment / deploy”是 GitHub 的默认工作流,表示你的自定义工作流未触发。确保 YAML 文件放置在 .github/workflows 文件夹中,并且触发条件设置正确(例如,如果默认分支是“master”而不是“main”,你需要更改 on.push 属性)。
  • 在仓库的设置 > 页面下,确保“源”(这是部署文件的源,而不是“源”作为我们的术语)设置为“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. 使用左侧导航面板切换到 Pipelines 视图。
  5. 创建一个新的管道。定义其名称,将触发模式设置为 On push,并选择触发管道执行的分支。
  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. 转到 https://azure.microsoft.com/en-us/services/devops/pipelines/ 并注册,如果你还没有注册。
  2. 创建一个组织。在组织内,创建一个项目并连接你的仓库。
  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: Install 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: Install and build

使用 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: Website
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 进行新标签推送时,此触发将启动 drone CI 作业以发布你的网站。

部署到 Flightcontrol

Flightcontrol 是一个服务,它可以直接从你的 Git 仓库将你的 Web 应用部署到 AWS Fargate,而无需传统的 PaaS。它让你完全访问检查和进行基础设施更改,而无需限制。

按照 Flightcontrol 的 Docusaurus 指南 开始。

部署到 Koyeb

Koyeb 是一个开发者友好的服务器无服务器平台,可以在全球范围内部署应用程序。该平台允许你无缝运行 Docker 容器、Web 应用程序和 API,使用基于 git 的部署、本机自动扩展、全球边缘网络和内置服务网格和发现。查看 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. 添加一个应用程序。
    • 点击 创建应用程序,给应用程序命名并选择你的 GitHub 或 GitLab 仓库,其中包含你的 Docusaurus 应用程序。
    • 定义主分支名称和应用程序路径。
    • 点击 创建。应用程序创建后:
    • 导航到你的应用程序 设置
    • 选择 端口
    • 添加用于你的 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.shyour-domain.com 取决于你选择的方法。

设置 CNAME 文件

将你的域名存储在 CNAME 文件中,以便将来使用:

echo subdomain.surge.sh > CNAME

你可以使用命令 surge 部署任何其他未来的更改。

部署到 Stormkit

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

部署到 QuantCDN

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

查看 文档博客 了解更多示例和使用案例,用于部署到 QuantCDN。

部署到 Cloudflare Pages

Cloudflare Pages 是一个 Jamstack 平台,用于前端开发人员协作和部署网站。只需几分钟即可开始,请按照 此页面 开始。

部署到 Azure Static Web Apps

Azure Static Web Apps 是一个服务,它可以直接从代码仓库将全栈 Web 应用部署到 Azure,简化 CI/CD 开发人员体验。Static Web Apps 将 Web 应用程序的静态资产与动态(API)端点分离。静态资产从全球分布的内容服务器中提供,使客户端能够更快地使用服务器附近的服务器检索文件。动态 API 使用基于事件的函数驱动方法,更高效且按需扩展。只需几分钟即可开始,请按照 此步骤指南 开始。

部署到 Kinsta

Kinsta Static Site Hosting 允许你免费部署最多 100 个静态站点,自定义域名与 SSL、100 GB 每月带宽和 260+ Cloudflare CDN 位置。

只需几次点击即可开始,请按照我们的 Docusaurus 在 Kinsta 文章开始。