Skip to main content
Version: 3.6.1

部署

¥Deployment

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

¥To build the static files of your website for production, run:

npm run build

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

¥Once it finishes, the static files will be generated within the build directory.

注意

Docusaurus 的唯一责任是在 build 中构建你的站点并触发静态文件。

¥The only responsibility of Docusaurus is to build your site and emit static files in build.

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

¥It is now up to you to choose how to host those static files.

你可以将站点部署到静态站点托管服务，例如 Vercel、GitHub 页面、Netlify、渲染 和 Surge。

¥You can deploy your site to static site hosting services such as Vercel, GitHub Pages, Netlify, Render, and Surge.

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

¥A Docusaurus site is statically rendered, and it can generally work without JavaScript!

配置​

¥Configuration

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

¥The following parameters are required in docusaurus.config.js to optimize routing and serve files from the correct location:

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

测试你的本地构建​

¥Testing your Build Locally

在将构建部署到生产环境之前，在本地测试你的构建非常重要。Docusaurus 为此提供了 docusaurus serve 命令：

¥It is important to test your build locally before deploying it for production. Docusaurus provides a docusaurus serve command for that:

npm run serve

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

¥By default, this will load your site at http://localhost:3000/.

尾部斜杠配置​

¥Trailing slash configuration

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

¥Docusaurus has a trailingSlash config to allow customizing URLs/links and emitted filename patterns.

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

¥The default value generally works fine. Unfortunately, each static hosting provider has a different behavior, and deploying the exact same site to various hosts can lead to distinct results. Depending on your host, it can be useful to change this config.

提示

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

¥Use slorber/trailing-slash-guide to understand better the behavior of your host and configure trailingSlash appropriately.

使用环境变量​

¥Using environment variables

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

¥Putting potentially sensitive information in the environment is common practice. However, in a typical Docusaurus website, the docusaurus.config.js file is the only interface to the Node.js environment (see our architecture overview), while everything else (MDX pages, React components, etc.) are client side and do not have direct access to the process global variable. In this case, you can consider using customFields to pass environment variables to the client side.

docusaurus.config.js
// If you are using dotenv (https://www.npmjs.com/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>;
}

选择托管服务提供商​

¥Choosing a hosting provider

有一些常见的托管选项：

¥There are a few common hosting options:

  • 自托管 带有 HTTP 服务器，例如 Apache2 或 Nginx。

    ¥Self hosting with an HTTP server like Apache2 or Nginx.

  • Jamstack 提供商（例如 Netlify 和 Vercel）。我们将使用它们作为参考，但同样的推断也适用于其他提供商。

    ¥Jamstack providers (e.g. Netlify and Vercel). We will use them as references, but the same reasoning can apply to other providers.

  • GitHub 页面（根据定义，它也是 Jamstack，但我们单独比较）。

    ¥GitHub Pages (by definition, it is also Jamstack, but we compare it separately).

如果你不确定选择哪一个，请询问以下问题：

¥If you are unsure of which one to choose, ask the following questions:

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

¥How many resources (money, person-hours, etc.) am I willing to invest in this?

  • 🔴 自托管需要网络以及 Linux 和 Web 服务器管理方面的经验。这是最困难的选择，并且需要最多的时间才能成功管理。从费用角度来看，云服务几乎从来都不是免费的，购买/部署现场服务器的成本可能更高。

    ¥🔴 Self-hosting requires experience in networking as well as Linux and web server administration. It's the most difficult option, and would require the most time to manage successfully. Expense-wise, cloud services are almost never free, and purchasing/deploying an onsite server can be even more costly.

  • 🟢 Jamstack 提供商可以帮助你几乎立即建立一个工作网站，并提供易于配置的服务器端重定向等功能。许多提供商甚至为你几乎永远不会超出的免费计划提供慷慨的构建时间配额。但是，免费计划有限制，一旦达到这些限制，你就需要付费。有关详细信息，请查看提供商的定价页面。

    ¥🟢 Jamstack providers can help you set up a working website in almost no time and offer features like server-side redirects that are easily configurable. Many providers offer generous build-time quotas even for free plans that you would almost never exceed. However, free plans have limits, and you would need to pay once you hit those limits. Check the pricing page of your provider for details.

  • 🟡 GitHub Pages 部署工作流程的设置可能很繁琐。（证据：看 部署到 GitHub Pages 的长度！）但是，此服务（包括构建和部署）对于公共存储库始终免费，并且我们有详细的说明来帮助你使其发挥作用。

    ¥🟡 The GitHub Pages deployment workflow can be tedious to set up. (Evidence: see the length of Deploying to GitHub Pages!) However, this service (including build and deployment) is always free for public repositories, and we have detailed instructions to help you make it work.

How much server-side customization do I need?

  • 🟢 通过自托管，你可以访问整个服务器的配置。你可以将虚拟主机配置为根据请求 URL 提供不同的内容，可以执行复杂的服务器端重定向，可以实现身份验证等等。如果你需要大量服务器端功能，请自行托管你的网站。

    ¥🟢 With self-hosting, you have access to the entire server's configuration. You can configure the virtual host to serve different content based on the request URL, you can do complicated server-side redirects, you can implement authentication, and so on. If you need a lot of server-side features, self-host your website.

  • 🟡 Jamstack 通常提供一些服务器端配置（例如 URL 格式（尾部斜杠）、服务器端重定向等）。

    ¥🟡 Jamstack usually offers some server-side configuration (e.g. URL formatting (trailing slashes), server-side redirects, etc.).

  • 🔴 除了强制执行 HTTPS 和设置 CNAME 记录外，GitHub Pages 不会公开服务器端配置。

    ¥🔴 GitHub Pages doesn't expose server-side configuration besides enforcing HTTPS and setting CNAME records.

Do I need collaboration-friendly deployment workflows?

  • 🟡 自托管服务可以利用 Netlify 等持续部署功能，但涉及的工作量更大。通常，你会指定一个特定的人来管理部署，并且与其他两个选项相比，工作流程不会非常基于 git。

    ¥🟡 Self-hosted services can leverage continuous deployment functionality like Netlify, but more heavy-lifting is involved. Usually, you would designate a specific person to manage the deployment, and the workflow wouldn't be very git-based as opposed to the other two options.

  • 🟢 Netlify 和 Vercel 为每个拉取请求提供部署预览，这对于团队在合并到生产之前审查工作很有用。你还可以管理具有不同成员对部署的访问权限的团队。

    ¥🟢 Netlify and Vercel have deploy previews for every pull request, which is useful for a team to review work before merging to production. You can also manage a team with different member access to the deployment.

  • 🟡 GitHub Pages 无法以非复杂方式进行部署预览。一个存储库只能与一个站点部署关联。另一方面，你可以控制谁对站点部署具有写入权限。

    ¥🟡 GitHub Pages cannot do deploy previews in a non-convoluted way. One repo can only be associated with one site deployment. On the other hand, you can control who has write access to the site's deployment.

没有灵丹妙药。在做出选择之前，你需要权衡你的需求和资源。

¥There isn't a silver bullet. You need to weigh your needs and resources before making a choice.

自托管​

¥Self-Hosting

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

¥Docusaurus can be self-hosted using docusaurus serve. Change port using --port and --host to change host.

npm run serve -- --build --port 80 --host 0.0.0.0
警告

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

¥It is not the best option, compared to a static hosting provider / CDN.

警告

在以下部分中，我们将介绍一些常见的托管提供商以及如何配置它们以最有效地部署 Docusaurus 站点。Docusaurus 不隶属于任何这些服务，提供此信息仅为了方便起见。一些文章是由第三方提供的，最近的 API 更改可能不会反映在我们这边。如果你看到过时的内容，欢迎 PR。

¥In the following sections, we will introduce a few common hosting providers and how they should be configured to deploy Docusaurus sites most efficiently. Docusaurus is not affiliated with any of these services, and this information is provided for convenience only. Some of the write-ups are provided by third-parties, and recent API changes may not be reflected on our side. If you see outdated content, PRs are welcome.

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

¥Because we can only provide this content on a best-effort basis only, we have stopped accepting PRs adding new hosting options. You can, however, publish your writeup on a separate site (e.g. your blog, or the provider's official website), and ask us to include a link to your writeup.

部署到 Netlify​

¥Deploying to Netlify

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

¥To deploy your Docusaurus sites to Netlify, first make sure the following options are properly configured:

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 创建你的网站。

¥Then, create your site with Netlify.

设置站点时，请指定构建命令和目录，如下所示：

¥While you set up the site, specify the build commands and directories as follows:

  • 构建命令：npm run build

    ¥build command: npm run build

  • 发布目录：build

    ¥publish directory: build

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

¥If you did not configure these build options, you may still go to "Site settings" -> "Build & deploy" after your site is created.

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

¥Once properly configured with the above options, your site should deploy and automatically redeploy upon merging to your deploy branch, which defaults to main.

警告

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

¥Some Docusaurus sites put the docs folder outside of website (most likely former Docusaurus v1 sites):

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

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

¥If you decide to use the website folder as Netlify's base directory, Netlify will not trigger builds when you update the docs folder, and you need to configure a custom ignore command:

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

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

¥By default, Netlify adds trailing slashes to Docusaurus URLs.

建议禁用 Netlify 设置 Post Processing > Asset Optimization > Pretty Urls 以防止小写 URL、不必要的重定向和 404 错误。

¥It is recommended to disable the Netlify setting Post Processing > Asset Optimization > Pretty Urls to prevent lowercase URLs, unnecessary redirects, and 404 errors.

要特别小心：Disable asset optimization 全局复选框已损坏，实际上并没有真正禁用 Pretty URLs 设置。请务必单独取消选中它。

¥Be very careful: the Disable asset optimization global checkbox is broken and does not really disable the Pretty URLs setting in practice. Please make sure to uncheck it independently.

如果你想保持 Pretty Urls Netlify 设置为打开状态，请适当调整 trailingSlash Docusaurus 配置。

¥If you want to keep the Pretty Urls Netlify setting on, adjust the trailingSlash Docusaurus config appropriately.

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

¥Refer to slorber/trailing-slash-guide for more information.

部署到 Vercel​

¥Deploying to Vercel

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

¥Deploying your Docusaurus project to Vercel will provide you with various benefits in the areas of performance and ease of use.

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

¥To deploy your Docusaurus project with a Vercel for Git Integration, make sure it has been pushed to a Git repository.

使用 导入 Flow 将项目导入 Vercel。在导入过程中，你将发现为你预先配置的所有相关选项；但是，你可以选择更改这些 options 中的任何一个。

¥Import the project into Vercel using the Import Flow. During the import, you will find all relevant options preconfigured for you; however, you can choose to change any of these options.

导入项目后，所有后续推送到分支将生成 预览部署，对 生产分支（通常是 "main" 或 "master"）所做的所有更改将生成 生产部署。

¥After your project has been imported, all subsequent pushes to branches will generate Preview Deployments, and all changes made to the Production Branch (usually "main" or "master") will result in a Production Deployment.

部署到 GitHub Pages​

¥Deploying to GitHub Pages

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

¥Docusaurus provides an easy way to publish to GitHub Pages, which comes free with every GitHub repository.

概述​

¥Overview

通常，发布过程涉及两个存储库（至少两个分支）：包含源文件的分支，以及包含要通过 GitHub Pages 提供的构建输出的分支。在下面的教程中，它们将分别称为 "source" 和 "deployment"。

¥Usually, there are two repositories (at least two branches) involved in a publishing process: the branch containing the source files, and the branch containing the build output to be served with GitHub Pages. In the following tutorial, they will be referred to as "source" and "deployment", respectively.

每个 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/。

¥Each GitHub repository is associated with a GitHub Pages service. If the deployment repository is called my-org/my-project (where my-org is the organization name or username), the deployed site will appear at https://my-org.github.io/my-project/. If the deployment repository is called my-org/my-org.github.io (the organization GitHub Pages repo), the site will appear at https://my-org.github.io/.

信息

如果你想将自定义域用于 GitHub Pages，请在 static 目录中创建 CNAME 文件。static 目录中的所有内容都将复制到 build 目录的根目录中进行部署。使用自定义域时，你应该能够从 baseUrl: '/projectName/' 移回到 baseUrl: '/'，并将 url 设置为自定义域。

¥In case you want to use your custom domain for GitHub Pages, create a CNAME file in the static directory. Anything within the static directory will be copied to the root of the build directory for deployment. When using a custom domain, you should be able to move back from baseUrl: '/projectName/' to baseUrl: '/', and also set your url to your custom domain.

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

¥You may refer to GitHub Pages' documentation User, Organization, and Project Pages for more details.

GitHub Pages 从默认分支（通常是 master / main）或 gh-pages 分支以及从根或 /docs 文件夹中获取部署就绪文件（docusaurus build 的输出）。你可以通过存储库中的 Settings > Pages 进行配置。该分支将被称为 "部署分支"。

¥GitHub Pages picks up deploy-ready files (the output from docusaurus build) from the default branch (master / main, usually) or the gh-pages branch, and either from the root or the /docs folder. You can configure that through Settings > Pages in your repository. This branch will be called the "deployment branch".

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

¥We provide a docusaurus deploy command that helps you deploy your site from the source branch to the deployment branch in one command: clone, build, and commit.

docusaurus.config.js 设置​

¥docusaurus.config.js settings

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

¥First, modify your docusaurus.config.js and add the following params:

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

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

¥These fields also have their environment variable counterparts which have a higher priority: ORGANIZATION_NAME, PROJECT_NAME, and DEPLOYMENT_BRANCH.

警告

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

¥GitHub Pages adds a trailing slash to Docusaurus URLs by default. It is recommended to set a trailingSlash config (true or false, not undefined).

示例：

¥Example:

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 会丢弃所有以 _ 开头的文件，因此建议你通过将名为 .nojekyll 文件的空文件添加到 static 目录来禁用 Jekyll。

¥By default, GitHub Pages runs published files through Jekyll. Since Jekyll will discard any files that begin with _, it is recommended that you disable Jekyll by adding an empty file named .nojekyll file to your static directory.

环境设置​

¥Environment settings

名称描述
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 Enterprise 主机设置为环境变量：

¥GitHub enterprise installations should work in the same manner as github.com; you only need to set the organization's GitHub Enterprise host as an environment variable:

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

部署​

¥Deploy

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

¥Finally, to deploy your site to GitHub Pages, run:

GIT_USER=<GITHUB_USERNAME> yarn deploy
警告

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

¥Beginning in August 2021, GitHub requires every command-line sign-in to use the personal access token instead of the password. When GitHub prompts for your password, enter the PAT instead. See the GitHub documentation for more information.

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

¥Alternatively, you can use SSH (USE_SSH=true) to log in.

使用 GitHub Actions 触发部署​

¥Triggering deployment with GitHub Actions

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

¥GitHub Actions allow you to automate, customize, and execute your software development workflows right in your repository.

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

¥The workflow examples below assume your website source resides in the main branch of your repository (the source branch is main), and your publishing source is configured for publishing with a custom GitHub Actions Workflow.

我们的目标是：

¥Our goal is that:

  1. 当向 main 发送新的拉取请求时，会采取一项操作来确保站点成功构建，而无需实际部署。这份工作将被称为 test-deploy。

    ¥When a new pull request is made to main, there's an action that ensures the site builds successfully, without actually deploying. This job will be called test-deploy.

  2. 当拉取请求合并到 main 分支或有人直接推送到 main 分支时，它将被构建并部署到 GitHub Pages。这份工作将被称为 deploy。

    ¥When a pull request is merged to the main branch or someone pushes to the main branch directly, it will be built and deployed to GitHub Pages. This job will be called deploy.

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

¥Here are two approaches to deploying your docs with GitHub Actions. Based on the location of your deployment repository, choose the relevant tab below:

  • 源存储库和部署存储库是同一存储库。

    ¥Source repo and deployment repo are the same repository.

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

    ¥The deployment repo is a remote repository, different from the source. Instructions for this scenario assume publishing source is the gh-pages branch.

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

¥While you can have both jobs defined in the same workflow file, the original deploy workflow will always be listed as skipped in the PR check suite status, which is not indicative of the actual status and provides no value to the review process. We therefore propose to manage them as separate workflows instead.

GitHub action files

添加这两个工作流程文件：

¥Add these two workflow files:

调整你的设置参数

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

¥These files assume you are using Yarn. If you use npm, change cache: yarn, yarn install --frozen-lockfile, yarn build to cache: npm, npm ci, npm run build accordingly.

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

¥If your Docusaurus project is not at the root of your repo, you may need to configure a default working directory, and adjust the paths accordingly.

.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
Site not deployed properly?

推送到主目录后，如果你没有看到你的网站在所需位置发布（例如，显示 "这里没有 GitHub Pages 网站"，或者显示你的存储库的 README.md 文件），请尝试以下操作：

¥After pushing to main, if you don't see your site published at the desired location (for example, it says "There isn't a GitHub Pages site here", or it's showing your repo's README.md file), try the following:

  • 等待大约三分钟并刷新。GitHub 页面可能需要几分钟时间才能获取新文件。

    ¥Wait about three minutes and refresh. It may take a few minutes for GitHub pages to pick up the new files.

  • 检查你的存储库的登陆页面，看看最后一次提交的标题旁边是否有一个绿色的小勾号，表明 CI 已通过。如果看到十字，则意味着构建或部署失败，你应该检查日志以获取更多调试信息。

    ¥Check your repo's landing page for a little green tick next to the last commit's title, indicating the CI has passed. If you see a cross, it means the build or deployment failed, and you should check the log for more debugging information.

  • 单击勾号并确保你看到 "部署到 GitHub 页面" 工作流程。像 "页面构建和部署/部署" 这样的名称是 GitHub 的默认工作流程，表明你的自定义部署工作流程根本无法触发。确保 YAML 文件放置在 .github/workflows 文件夹下，并且触发条件设置正确（例如，如果你的默认分支是 "master" 而不是 "main"，则需要更改 on.push 属性）。

    ¥Click on the tick and make sure you see a "Deploy to GitHub Pages" workflow. Names like "pages build and deployment / deploy" are GitHub's default workflows, indicating your custom deployment workflow failed to be triggered at all. Make sure the YAML files are placed under the .github/workflows folder, and that the trigger condition is set correctly (e.g., if your default branch is "master" instead of "main", you need to change the on.push property).

  • 在存储库的“设置”>“页面”下，确保 "来源"（这是部署文件的源，而不是我们术语中的 "source"）设置为 "gh-pages" + "/ （根）"，因为我们使用 gh-pages 作为部署分支。

    ¥Under your repo's Settings > Pages, make sure the "Source" (which is the source for the deployment files, not "source" as in our terminology) is set to "gh-pages" + "/ (root)", since we are using gh-pages as the deployment branch.

如果你使用自定义域：

¥If you are using a custom domain:

使用 Travis CI 触发部署​

¥Triggering deployment with Travis CI

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

¥Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to npm, and deploying changes to your website. All you need to do to automate the deployment of your website is to invoke the yarn deploy script whenever your website is updated. The following section covers how to do just that using Travis CI, a popular continuous integration service provider.

  1. 转到 https://github.com/settings/tokens 并生成新的 个人访问令牌。创建令牌时，授予其 repo 范围，以便其拥有所需的权限。

    ¥Go to https://github.com/settings/tokens and generate a new personal access token. When creating the token, grant it the repo scope so that it has the permissions it needs.

  2. 使用你的 GitHub 账户，添加 Travis CI 应用 到你要激活的存储库。

    ¥Using your GitHub account, add the Travis CI app to the repository you want to activate.

  3. 打开 Travis CI 仪表板。URL 看起来像 https://travis-ci.com/USERNAME/REPO，导航到存储库的 More options > Setting > Environment Variables 部分。

    ¥Open your Travis CI dashboard. The URL looks like https://travis-ci.com/USERNAME/REPO, and navigate to the More options > Setting > Environment Variables section of your repository.

  4. 创建一个名为 GH_TOKEN 的新环境变量，将新生成的令牌作为其值，然后创建 GH_EMAIL（你的电子邮件地址）和 GH_NAME（你的 GitHub 用户名）。

    ¥Create a new environment variable named GH_TOKEN with your newly generated token as its value, then GH_EMAIL (your email address) and GH_NAME (your GitHub username).

  5. 使用以下内容在存储库的根目录上创建 .travis.yml：

    ¥Create a .travis.yml on the root of your repository with the following:

.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 脚本进行部署。

¥Now, whenever a new commit lands in main, Travis CI will run your suite of tests and if everything passes, your website will be deployed via the yarn deploy script.

与 Buddy 触发部署​

¥Triggering deployment with Buddy

伙伴 是一个易于使用的 CI/CD 工具，可让你自动将门户部署到不同的环境，包括 GitHub Pages。

¥Buddy is an easy-to-use CI/CD tool that allows you to automate the deployment of your portal to different environments, including GitHub Pages.

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

¥Follow these steps to create a pipeline that automatically deploys a new version of your website whenever you push changes to the selected branch of your project:

  1. 转到 https://github.com/settings/tokens 并生成新的 个人访问令牌。创建令牌时，授予其 repo 范围，以便其拥有所需的权限。

    ¥Go to https://github.com/settings/tokens and generate a new personal access token. When creating the token, grant it the repo scope so that it has the permissions it needs.

  2. 登录你的好友账户并创建一个新项目。

    ¥Sign in to your Buddy account and create a new project.

  3. 选择 GitHub 作为你的 git 托管提供商，然后选择包含你网站代码的存储库。

    ¥Choose GitHub as your git hosting provider and select the repository with the code of your website.

  4. 使用左侧导航面板切换到 Pipelines 视图。

    ¥Using the left navigation panel, switch to the Pipelines view.

  5. 创建新管道。定义其名称，设置触发模式为 On push，选择触发管道执行的分支。

    ¥Create a new pipeline. Define its name, set the trigger mode to On push, and select the branch that triggers the pipeline execution.

  6. 添加 Node.js 操作。

    ¥Add a Node.js action.

  7. 在操作的终端中添加以下命令：

    ¥Add these commands in the action's terminal:

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 管道的更多信息。

¥After creating this simple pipeline, each new commit pushed to the branch you selected deploys your website to GitHub Pages using yarn deploy. Read this guide to learn more about setting up a CI/CD pipeline for Docusaurus.

使用 Azure 管道​

¥Using Azure Pipelines

  1. 如果你还没有注册，请在 Azure 管道 注册。

    ¥Sign Up at Azure Pipelines if you haven't already.

  2. 创建一个组织。在组织内，创建一个项目并从 GitHub 连接你的存储库。

    ¥Create an organization. Within the organization, create a project and connect your repository from GitHub.

  3. 转到 https://github.com/settings/tokens 并生成具有 repo 范围的新 个人访问令牌。

    ¥Go to https://github.com/settings/tokens and generate a new personal access token with the repo scope.

  4. 在项目页面（看起来像 https://dev.azure.com/ORG_NAME/REPO_NAME/_build）中，使用以下文本创建一个新管道。另外，单击“编辑”并添加一个名为 GH_TOKEN 的新环境变量，其中包含新生成的令牌作为其值，然后是 GH_EMAIL（你的电子邮件地址）和 GH_NAME（你的 GitHub 用户名）。确保将它们标记为秘密。或者，你也可以在存储库根目录中添加名为 azure-pipelines.yml 的文件。

    ¥In the project page (which looks like https://dev.azure.com/ORG_NAME/REPO_NAME/_build), create a new pipeline with the following text. Also, click on edit and add a new environment variable named GH_TOKEN with your newly generated token as its value, then GH_EMAIL (your email address) and GH_NAME (your GitHub username). Make sure to mark them as secret. Alternatively, you can also add a file named azure-pipelines.yml at your repository root.

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​

¥Using Drone

  1. 创建一个新的 SSH 密钥，该密钥将成为你项目的 部署密钥。

    ¥Create a new SSH key that will be the deploy key for your project.

  2. 指定你的私钥和公钥，使其不会覆盖你的其他 SSH 密钥。

    ¥Name your private and public keys to be specific and so that it does not overwrite your other SSH keys.

  3. 转到 https://github.com/USERNAME/REPO/settings/keys 并通过粘贴你刚刚生成的公钥来添加新的部署密钥。

    ¥Go to https://github.com/USERNAME/REPO/settings/keys and add a new deploy key by pasting in the public key you just generated.

  4. 打开 Drone.io 仪表板并登录。该 URL 看起来像 https://cloud.drone.io/USERNAME/REPO。

    ¥Open your Drone.io dashboard and log in. The URL looks like https://cloud.drone.io/USERNAME/REPO.

  5. 单击存储库，单击激活存储库，然后使用你刚刚生成的私钥值添加一个名为 git_deploy_private_key 的秘密。

    ¥Click on the repository, click on activate repository, and add a secret called git_deploy_private_key with your private key value that you just generated.

  6. 使用以下文本在存储库的根目录中创建 .drone.yml。

    ¥Create a .drone.yml on the root of your repository with the below text.

.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 时，此触发器都会启动无人机 CI 作业来发布你的网站。

¥Now, whenever you push a new tag to GitHub, this trigger will start the drone CI job to publish your website.

部署到 Flightcontrol​

¥Deploying to Flightcontrol

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

¥Flightcontrol is a service that automatically builds and deploys your web apps to AWS Fargate directly from your Git repository. It gives you full access to inspect and make infrastructure changes without the limitations of a traditional PaaS.

请按照 Flightcontrol 的 Docusaurus 分步指南 开始操作。

¥Get started by following Flightcontrol's step-by-step Docusaurus guide.

部署到 Koyeb​

¥Deploying to Koyeb

Koyeb 是一个开发者友好的无服务器平台，用于在全球范围内部署应用。该平台可让你通过基于 git 的部署、原生自动缩放、全球边缘网络以及内置服务网格和发现来无缝运行 Docker 容器、Web 应用和 API。查看 Koyeb 的 Docusaurus 部署指南 以开始使用。

¥Koyeb is a developer-friendly serverless platform to deploy apps globally. The platform lets you seamlessly run Docker containers, web apps, and APIs with git-based deployment, native autoscaling, a global edge network, and built-in service mesh and discovery. Check out the Koyeb's Docusaurus deployment guide to get started.

部署到 Render​

¥Deploying to Render

渲染 为 免费静态网站托管 提供完全托管的 SSL、自定义域、全球 CDN 以及从 Git 存储库的持续自动部署。按照 Docusaurus 的渲染部署指南 操作，只需几分钟即可开始使用。

¥Render offers free static site hosting with fully managed SSL, custom domains, a global CDN, and continuous auto-deploy from your Git repo. Get started in just a few minutes by following Render's guide to deploying Docusaurus.

部署到 Qovery​

¥Deploying to Qovery

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

¥Qovery is a fully-managed cloud platform that runs on your AWS, Digital Ocean, and Scaleway account where you can host static sites, backend APIs, databases, cron jobs, and all your other apps in one place.

  1. 创建一个 Qovery 账户。如果你还没有账户，请访问 Qovery 仪表板 创建一个账户。

    ¥Create a Qovery account. Visit the Qovery dashboard to create an account if you don't already have one.

  2. 创建一个项目。

    ¥Create a project.

    • 单击“创建项目”并为你的项目命名。

      ¥Click on Create project and give a name to your project.

    • 单击“下一步”。

      ¥Click on Next.

  3. 创造新环境。

    ¥Create a new environment.

    • 单击“创建环境”并指定名称（例如暂存、生产）。

      ¥Click on Create environment and give a name (e.g. staging, production).

  4. 添加应用。

    ¥Add an application.

    • 单击创建应用，输入名称并选择 Docusaurus 应用所在的 GitHub 或 GitLab 存储库。

      ¥Click on Create an application, give a name and select your GitHub or GitLab repository where your Docusaurus app is located.

    • 定义主分支名称和根应用路径。

      ¥Define the main branch name and the root application path.

    • 单击“创建”。创建应用后：

      ¥Click on Create. After the application is created:

    • 导航至你的应用设置

      ¥Navigate to your application Settings

    • 选择端口

      ¥Select Port

    • 添加 Docusaurus 应用使用的端口

      ¥Add port used by your Docusaurus application

  5. 部署

    ¥Deploy

    • 你现在所要做的就是导航到你的应用并单击“部署”。

      ¥All you have to do now is to navigate to your application and click on Deploy.

Deploy the app

就是这样。观察状态并等待应用部署。要在浏览器中打开应用，请单击应用概述中的“操作”和“打开”。

¥That's it. Watch the status and wait till the app is deployed. To open the application in your browser, click on Action and Open in your application overview.

部署到 Hostman​

¥Deploying to Hostman

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

¥Hostman allows you to host static websites for free. Hostman automates everything, you just need to connect your repository and follow these easy steps:

  1. 创建服务。

    ¥Create a service.

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

      ¥To deploy a Docusaurus static website, click Create in the top-left corner of your Dashboard and choose Front-end app or static website.

  2. 选择要部署的项目。

    ¥Select the project to deploy.

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

      ¥If you are logged in to Hostman with your GitHub, GitLab, or Bitbucket account, you will see the repository with your projects, including the private ones.

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

      ¥Choose the project you want to deploy. It must contain the directory with the project's files (e.g. website).

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

      ¥To access a different repository, click Connect another repository.

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

      ¥If you didn't use your Git account credentials to log in, you'll be able to access the necessary account now, and then select the project.

  3. 配置构建设置。

    ¥Configure the build settings.

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

      ¥Next, the Website customization window will appear. Choose the Static website option from the list of frameworks.

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

      ¥The Directory with app points at the directory that will contain the project's files after the build. If you selected the repository with the contents of the website (or my_website) directory during Step 2, you can leave it empty.

    • Docusaurus 的标准构建命令是：

      ¥The standard build command for Docusaurus is:

      npm run build

    • 如果需要，你可以修改构建命令。你可以输入多个命令，以 && 分隔。

      ¥You can modify the build command if needed. You can enter multiple commands separated by &&.

  4. 部署。

    ¥Deploy.

    • 单击“部署”开始构建过程。

      ¥Click Deploy to start the build process.

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

      ¥Once it starts, you will enter the deployment log. If there are any issues with the code, you will get warning or error messages in the log specifying the cause of the problem. Usually, the log contains all the debugging data you'll need.

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

      ¥When the deployment is complete, you will receive an email notification and also see a log entry. All done! Your project is up and ready.

部署到 Surge​

¥Deploying to Surge

Surge 是 静态网络托管平台，你可以使用它在几秒钟内从命令行部署 Docusaurus 项目。将你的项目部署到 Surge 既简单又免费（包括自定义域和 SSL 证书）。

¥Surge is a static web hosting platform that you can use to deploy your Docusaurus project from the command line in seconds. Deploying your project to Surge is easy and free (including custom domains and SSL certs).

使用 Surge 在几秒钟内部署你的应用，步骤如下：

¥Deploy your app in a matter of seconds using Surge with the following steps:

  1. 首先，通过运行以下命令使用 npm 安装 Surge：

    ¥First, install Surge using npm by running the following command:

    npm install -g surge

  2. 要在项目的根目录中构建用于生产的站点的静态文件，请运行：

    ¥To build the static files of your site for production in the root directory of your project, run:

    npm run build

  3. 然后，在项目的根目录中运行以下命令：

    ¥Then, run this command inside the root directory of your project:

    surge build/

Surge 的首次用户将被提示从命令行创建账户（仅发生一次）。

¥First-time users of Surge would be prompted to create an account from the command line (which happens only once).

确认你要发布的站点位于 build 目录中。始终给出随机生成的子域 *.surge.sh subdomain（可以编辑）。

¥Confirm that the site you want to publish is in the build directory. A randomly generated subdomain *.surge.sh subdomain is always given (which can be edited).

使用你的域名​

¥Using your domain

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

¥If you have a domain name you can deploy your site using the command:

surge build/ your-domain.com

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

¥Your site is now deployed for free at subdomain.surge.sh or your-domain.com depending on the method you chose.

设置 CNAME 文件​

¥Setting up CNAME file

使用以下命令将你的域存储在 CNAME 文件中以供将来部署：

¥Store your domain in a CNAME file for future deployments with the following command:

echo subdomain.surge.sh > CNAME

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

¥You can deploy any other changes in the future with the command surge.

部署到 Stormkit​

¥Deploying to Stormkit

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

¥You can deploy your Docusaurus project to Stormkit, a deployment platform for static websites, single-page applications (SPAs), and serverless functions. For detailed instructions, refer to this guide.

部署到 QuantCDN​

¥Deploying to QuantCDN

  1. 安装 Quant CLI

    ¥Install Quant CLI

  2. 通过 报名 创建 QuantCDN 账户

    ¥Create a QuantCDN account by signing up

  3. 使用 quant init 初始化你的项目并填写你的凭据：

    ¥Initialize your project with quant init and fill in your credentials:

    quant init

  4. 部署你的网站。

    ¥Deploy your site.

    quant deploy

有关部署到 QuantCDN 的更多示例和用例，请参阅 docs 和 blog。

¥See docs and blog for more examples and use cases for deploying to QuantCDN.

部署到 Layer0​

¥Deploying to Layer0

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

¥Layer0 is an all-in-one platform to develop, deploy, preview, experiment on, monitor, and run your headless frontend. It is focused on large, dynamic websites and best-in-class performance through EdgeJS (a JavaScript-based Content Delivery Network), predictive prefetching, and performance monitoring. Layer0 offers a free tier. Get started in just a few minutes by following Layer0's guide to deploying Docusaurus.

部署到 Cloudflare 页面​

¥Deploying to Cloudflare Pages

Cloudflare 页面 是一个 Jamstack 平台，供前端开发者协作和部署网站。按照 本文 在几分钟内开始使用。

¥Cloudflare Pages is a Jamstack platform for frontend developers to collaborate and deploy websites. Get started within a few minutes by following this article.

部署到 Azure 静态 Web 应用​

¥Deploying to Azure Static Web Apps

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

¥Azure Static Web Apps is a service that automatically builds and deploys full-stack web apps to Azure directly from the code repository, simplifying the developer experience for CI/CD. Static Web Apps separates the web application's static assets from its dynamic (API) endpoints. Static assets are served from globally-distributed content servers, making it faster for clients to retrieve files using servers nearby. Dynamic APIs are scaled with serverless architectures using an event-driven functions-based approach that is more cost-effective and scales on demand. Get started in a few minutes by following this step-by-step guide.

部署到 Kinsta​

¥Deploying to Kinsta

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

¥Kinsta Static Site Hosting lets you deploy up to 100 static sites for free, custom domains with SSL, 100 GB monthly bandwidth, and 260+ Cloudflare CDN locations.

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

¥Get started in just a few clicks by following our Docusaurus on Kinsta article.