跳至主要内容
版本:3.5.2

部署

要构建网站的静态文件以供生产环境使用,请运行

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
// If you are using dotenv (https://npmjs.net.cn/package/dotenv)
import 'dotenv/config';

export default {
title: '...',
url: process.env.URL, // You can use environment variables to control site specifics as well
customFields: {
// Put your custom environment here
teamEmail: process.env.EMAIL,
},
};
home.jsx
import useDocusaurusContext from '@docusaurus/useDocusaurusContext';

export default function Home() {
const {
siteConfig: {customFields},
} = useDocusaurusContext();
return <div>Contact us through {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 to your site with no trailing slash
baseUrl: '/', // Base directory of your site relative to your repo
// ...
};

然后,使用 Netlify 创建您的站点

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

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

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

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

警告

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

repo           # git root
├── docs # MD files
└── website # Docusaurus root

如果您决定将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设置。请确保单独取消选中它

如果您想保留美观 URL Netlify 设置,请相应地调整trailingSlash Docusaurus 配置。

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

部署到 Vercel

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

要使用Vercel 的 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分支,以及从根目录或/docs文件夹中获取可部署的文件(docusaurus build的输出)。您可以通过存储库中的设置 > 页面进行配置。此分支将被称为“部署分支”。

我们提供了一个docusaurus deploy命令,可帮助您使用一个命令将站点从源分支部署到部署分支:克隆、构建和提交。

docusaurus.config.js 设置

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

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

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

警告

GitHub Pages 默认会为 Docusaurus URL 添加尾部斜杠。建议设置trailingSlash配置(truefalse,而不是undefined)。

示例

docusaurus.config.js
export default {
// ...
url: 'https://endiliey.github.io', // Your website 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(例如[email protected]:facebook/docusaurus.git),则USE_SSH将推断为true
GIT_USER具有对部署存储库的推送访问权限的 GitHub 帐户的用户名。对于您自己的存储库,这通常是您的 GitHub 用户名。如果未使用 SSH,则需要此项,否则将被忽略。
GIT_PASSgit 用户(由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 企业主机设置为环境变量即可

名称描述
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: yarnyarn install --frozen-lockfileyarn build更改为cache: npmnpm cinpm 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://githubdocs.cn/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://githubdocs.cn/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 站点”,或显示您的仓库的 README.md 文件),请尝试以下操作

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

如果您正在使用自定义域名

使用 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.cn/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: 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 是一项服务,可将您的 Web 应用从您的 Git 仓库自动构建并部署到 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. 部署
    • 现在您需要做的就是导航到您的应用程序并点击**部署**。

Deploy the app

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

部署到Hostman

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

  1. 创建一个服务。

    • 要部署 Docusaurus 静态网站,请点击 仪表盘 左上角的**创建**,然后选择**前端应用或静态网站**。
  2. 选择要部署的项目。

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

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

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

    • 如果您没有使用您的 Git 帐户凭据登录,您现在将能够访问必要的帐户,然后选择项目。

  3. 配置构建设置。

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

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

    • Docusaurus 的标准构建命令为

      npm run build
    • 如果需要,您可以修改构建命令。您可以输入多个命令,并用&&分隔。

  4. 部署。

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

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

    • 部署完成后,您将收到一封电子邮件通知,并且还会看到日志条目。全部完成!您的项目已准备就绪。

部署到Surge

Surge 是一个静态网页托管平台,您可以使用它在几秒钟内从命令行部署您的 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,这是一个用于静态网站、单页应用程序 (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文章,只需点击几下即可开始使用。