メインコンテンツまでスキップ

デプロイ

本番用にウェブサイトの静的ファイルをビルドするには、次のコマンドを実行します。

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 provides a docusaurus serve command for that:

npm run serve

初期設定では、http://localhost:3000/でサイトを起動します。

末尾スラッシュの設定​

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

一般的には初期設定値で問題なく動作します。 残念ながら、静的ホスティングプロバイダによって動作が異なるため、まったく同じサイトをさまざまなホストに展開すると、異なる結果になることがあります。 ホストによっては、この設定を変更することが有効な場合があります。

ヒント

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

環境変数の利用​

潜在的な機密情報を環境に置くことは、一般的に行われていることです。 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>;
}

ホスティングプロバイダーの選択​

一般的なホスティングオプションは以下に示す通りいくつかあります。

  • Self-hosting with an HTTP server like Apache2 or Nginx.
  • Static hosting providers (e.g. Netlify and Vercel). ここではこれらを基準にしますが、他のプロバイダーでも同じ理屈が通用します。
  • GitHub Pages (by definition, it is also static hosting provider, but we compare it separately).

どれを選ぶか迷ったら、以下の質問をしてみてください。

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

  • 🔴 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.
  • 🟢 Static hosting 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. 詳しくは、プロバイダーの価格ページをご覧ください。
  • 🟡 GitHub Pages のデプロイワークフローは、設定に手間がかかることがあります。 (Evidence: see the length of Deploying to GitHub Pages!) しかし、このサービス（ビルドとデプロイを含む）は公開リポジトリでは常に無料であり、私たちはそれをうまく機能させるための詳しい手順を用意しています。
サーバーサイドのカスタマイズはどの程度必要だろうか？
  • 🟢 セルフホストでは、サーバー全体の設定にアクセスすることができます。 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. 多くのサーバーサイドの機能が必要な場合は、ウェブサイトをセルフホストしてください。
  • 🟡 Static hosting providers usually offers some server-side configuration (e.g. URL formatting (trailing slashes), server-side redirects, etc.).
  • 🔴 GitHub Pages doesn't expose server-side configuration besides enforcing HTTPS and setting CNAME records.
共同作業に適したデプロイワークフローは必要だろうか？
  • 🟡 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 には、すべてのプルリクエストに対してデプロイプレビューがあり、本番環境にマージする前にチームが作業を確認するのに便利です。 また、デプロイに対して異なるメンバーのアクセス権でチームを管理することもできます。
  • 🟡 GitHub Pages では、デプロイプレビューを非連続的に行うことはできません。 1つのリポジトリは1つのサイトのデプロイにしか関連付けることができません。 一方、サイトのデプロイへの書き込みアクセス権を持つ人を制御することができます。

銀の弾丸は存在しません。 自分のニーズとリソースを天秤にかけて、選択する必要があります。

セルフホスト​

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と比較すると、最良の選択肢とは言えません。

Hosting provider guides​

Here's a list of popular hosting providers and how they should be configured to deploy Docusaurus sites most efficiently. Docusaurusははこれらのサービスとは一切関係なく、これらの情報はあくまで便宜上のために提供しているものです。

Other hosting solutions

We can only officially document a small subset of hosting providers.

However, a Docusaurus site is just static files, and almost any hosting provider able to serve static websites can deploy it.

Check our Deployment Platforms GitHub Discussions category: the community shares its experience with other platforms there, and hosting providers are welcome to explain how to deploy Docusaurus on their service.