DOCUMENTATION

200stack ドキュメント

プロジェクト作成からサイト公開、ルーティング設定まで、200stack の使い方をまとめています。 初めて設定するときは上から順に、特定の機能だけ確認したいときは目次から移動してください。

QUICK START

はじめる

最初はプロジェクトを作り、公開したいものに合わせてアプリを選びます。 その後の設定は dashboard 上で進められます。

  1. 01

    プロジェクトを作成する

    dashboard にログインし、個人または組織のプロジェクトを作成します。

    プロジェクトはアプリ、メンバー、請求、ドメインなどをまとめる単位です。個人で試す場合は個人プロジェクト、制作チームや顧客と共同で管理する場合は組織プロジェクトを使います。

    あとから GitHub 連携や独自ドメインなどを追加できるため、最初は名前と用途が分かる状態にしておけば十分です。

  2. 02

    アプリの種類を選ぶ

    静的サイトを公開するためのアプリを作成します。

    静的サイトアプリは、GitHub のリポジトリを元にビルドして CDN から配信する用途です。Astro、Next.js の静的出力、Vite など、成果物を静的ファイルとして出せる構成に向いています。

    公開したいサイトごとにアプリを分けると、リポジトリ、ブランチ、ドメイン、デプロイ履歴を管理しやすくなります。

  3. 03

    公開に必要な設定を入れる

    GitHub リポジトリ、ビルド設定、ドメインなどを用途に合わせて設定します。

    静的サイトでは、対象リポジトリ、ブランチ、ビルドコマンド、出力ディレクトリ、環境変数の有無を確認します。初回デプロイに失敗した場合は、この設定とビルドログを見直します。

    独自ドメインを使う場合は、公開前に DNS 設定と dashboard 側のドメイン設定を確認します。preview と production を分ける場合は、ブランチとドメインの対応も整理してください。

  4. 04

    公開後の状態を確認する

    デプロイ履歴、独自ドメイン、請求を dashboard で確認します。

    公開後は、最新デプロイが成功しているか、期待したドメインで表示できるかを順番に確認します。

    デプロイ履歴には成功、失敗、対象 commit などが残るため、公開状態の確認や切り戻し判断に使えます。

DEPLOY

サイトを公開する

静的サイトは GitHub App と連携して公開します。push を起点に 200stack が変更を受け取り、ビルドと配信更新を行います。

GitHub App 連携

プロジェクトの Git 連携画面から GitHub App を追加し、200stack が参照できるリポジトリを選びます。

GitHub 側のインストール画面で、対象アカウントとリポジトリの範囲を選択します。後からリポジトリを追加したい場合は、GitHub 側の App 設定で構成を変更できます。

200stack には必要なリポジトリ権限だけを渡す運用にしてください。組織リポジトリを扱う場合は、GitHub 側の権限を持つメンバーが連携を行います。

リポジトリとブランチを選択

静的サイトアプリで対象リポジトリを選び、公開に使うブランチとビルド設定を確認します。

アプリごとに、どのリポジトリのどのブランチを公開対象にするかを決めます。preview 用と production 用で運用を分ける場合は、ブランチや環境変数の対応も整理しておきます。

ビルドコマンドと出力ディレクトリは、ローカルで成功しているコマンドに合わせます。例として `npm run build` と `dist`、`out` などの組み合わせを確認します。

push でデプロイ

対象ブランチに push すると、200stack が webhook を受け取り、ビルドと配信更新を開始します。

push 直後は、dashboard のデプロイ履歴で状態を確認します。ビルド中、成功、失敗などの状態が残るため、どの commit が公開されたかを後から追跡できます。

Webhook の URL や署名 secret は 200stack 側で管理します。利用者が手動で secret を公開ページやクライアントコードに置く必要はありません。

履歴とロールバック

デプロイ履歴からステータスやログを確認し、必要に応じて過去のデプロイへ戻します。

失敗時はまずログを開き、依存関係のインストール、環境変数、ビルドコマンド、出力ディレクトリのどこで止まったかを確認します。

過去の安定版に戻したい場合は、直近で成功しているデプロイを基準にします。戻した後も、ドメイン表示と主要ページの確認を行ってください。

GitHub webhook の URL、secret、署名検証などの内部情報は 200stack 側で管理します。利用者は GitHub App の連携状態と対象リポジトリを確認してください。

ROUTING

ルーティングを設定する

ルーティング機能では、公開中のサイトに対してリダイレクト、内部フォワード、404 フォールバックを設定できます。 URL 変更後の案内、SPA の直接アクセス対応、パス構造の整理に使います。

開始方法

  1. 1

    設定ファイルを用意する

    ルーティング設定はリポジトリルート直下の `routing-config.jsonc` で管理します。

  2. 2

    設定を編集する

    `rules` にリダイレクトや内部フォワードを追加し、必要に応じて `notFound` を設定します。

  3. 3

    push してデプロイする

    設定ファイルを含む変更を push すると、デプロイ時にルーティング設定が反映されます。反映後は対象ドメインでリダイレクト、内部フォワード、存在しない HTML パスを確認します。

設定ファイルの例

まず、実際に配置する設定ファイルの形を確認します。設定は JSONC 形式で記述します。 コメントと末尾カンマを使えますが、キーはダブルクォートで書きます。`$schema` を指定すると、対応エディタで入力補完や検証を使いやすくなります。

{
  // エディタ補完と検証に使うスキーマです
  "$schema": "https://www.200stack.com/schemas/routing-config.schema.json",

  // ルーティング設定のバージョンです。現在は "1" 固定です
  "version": "1",

  // この設定を適用するホストを限定します
  "scope": {
    "hosts": ["example.com"]
  },

  // 上から順に評価され、最初に一致した 1 件だけが適用されます
  "rules": [
    {
      // 古い記事 URL を新しい記事 URL へ恒久リダイレクトします
      "id": "legacy-post",
      "type": "redirect",
      "source": "/blog/:year(\\d{4})/:slug",
      "destination": "/posts/{year}/{slug}",
      "status": 301
    },
    {
      // 表示 URL は変えず、/docs 配下のファイルを返します
      "id": "docs-forward",
      "type": "forward",
      "source": "/guide/:path*",
      "destination": "/docs/{path}",
      "query": "preserve"
    },
    {
      // 外部サイトへ移動させる場合は https と許可ホストを明示します
      "id": "status-page",
      "type": "redirect",
      "source": "/status",
      "destination": "https://status.example.com/",
      "status": 302,
      "allowExternal": true,
      "allowlistHosts": ["status.example.com"]
    }
  ],

  // SPA などで、存在しない HTML パスを /index.html に寄せます
  "notFound": {
    "destination": "/index.html",
    "status": 200,
    "htmlOnly": true
  }
}

設定ファイルのルール

設定ファイルは、適用範囲、ルール一覧、404 時の扱いで構成されます。どの項目が必須で、どの項目が用途別に変わるかを確認できます。

type RoutingConfig = {
  // 設定フォーマットのバージョンです。現在は "1" を指定します。
  version: "1"

  // 設定を適用するホストを限定したい場合に使います。
  scope?: {
    hosts?: string[]
  }

  // 上から順に評価されるルール一覧です。
  // 最初に一致した 1 件だけが適用されます。
  rules: RoutingRule[]

  // どのルールにも一致しなかった HTML リクエストの扱いです。
  notFound?: {
    destination: string
    status?: 200 | 404
    htmlOnly?: boolean
  }
}

type RoutingRule = RedirectRule | ForwardRule

type RedirectRule = {
  // ルールを見分けるための ID です。
  // 移行元や用途が分かる名前にします。
  id: string

  // redirect はブラウザの URL を変更します。
  type: "redirect"

  // どの URL に一致させるかを書きます。
  // :name は名前付きパラメータで、name の部分は任意の名前にできます。
  // :year(\\d{4}) は year という名前の値を 4 桁の数字に限定する例です。
  source: string

  // 遷移先です。source で付けた名前は {year} / {slug} のように埋め込めます。
  destination: string

  // 恒久移転は 301 / 308、一時移転は 302 / 307 を使います。
  status?: 301 | 302 | 307 | 308

  // path は既定です。regex では JavaScript RegExp に近い書き方を使います。
  patternSyntax?: "path" | "regex" | "glob"

  // クエリ文字列を引き継ぐ場合は preserve、捨てる場合は drop を指定します。
  query?: "preserve" | "drop" | "replace" | QueryConfig

  // 外部サイトへ redirect する場合だけ true にします。
  allowExternal?: boolean

  // 外部 redirect を許可するホストを明示します。
  allowlistHosts?: string[]
}

type ForwardRule = {
  // ルールを見分けるための ID です。
  id: string

  // forward は URL を変えずに、別の内部パスを返します。
  type: "forward"

  // どの URL に一致させるかを書きます。
  source: string

  // 同一サイト内の相対パスだけを指定できます。
  destination: string

  // path は既定です。regex では $1 / $2 の番号参照を使えます。
  patternSyntax?: "path" | "regex" | "glob"

  // クエリ文字列をどう扱うかを指定します。
  query?: "preserve" | "drop" | "replace" | QueryConfig
}

type QueryConfig = {
  mode?: "preserve" | "drop" | "merge" | "replace"
  params?: Record<string, string>
  encode?: "component" | "none"
}

パターン記法の読み方

既定の `patternSyntax` は `path` です。これは path-to-regexp 系でよく使われる `:name`、`:name*`、`:name(正規表現)` のようなパスパラメータ記法に寄せた 200stack のルールです。 実装ではこの記法を 200stack 側で解釈し、取り出した値を `destination` や `query.params` に展開します。

:slug

1 セグメントだけを受け取る名前付きパラメータ

`/blog/:slug` は `/blog/hello` に一致し、`slug=hello` を取り出します。`/blog/2026/hello` のようにスラッシュをまたぐ値には一致しません。

:path*

複数階層をまとめて受け取るワイルドカード

`/guide/:path*` は `/guide/a/b/c` に一致し、`path=a/b/c` を取り出します。ドキュメント配下など、複数階層の URL をまとめて別パスへ移すときに使います。

:name(正規表現)

任意の名前付きパラメータに条件を付ける

`:` の後ろは任意のパラメータ名です。`:year(\\d{4})` なら `year` という名前の値を 4 桁の数字に限定し、`:id(\\d+)` なら `id` を 1 桁以上の数字に限定します。`year` だけが特別に使えるわけではありません。

{path}

取り出した値を destination へ埋め込むテンプレート

`source` で `:path*` として取り出した値は、`destination` 側で `{path}` として使えます。例: `/guide/intro/setup` を `/docs/intro/setup` に内部フォワードできます。

$1 / $2

regex 構文で使う番号参照

`patternSyntax: "regex"` を使う場合は、JavaScript の `RegExp` に近い書き方になります。`source: "^/items/(\\d+)-(\\w+)$"` のように括弧で取った値は、`destination` で `$1`、`$2` として参照します。

`patternSyntax: "regex"` を指定した場合は、`source` は JavaScript の `RegExp` として評価されます。 その場合、名前付きの {slug} 展開ではなく、括弧でキャプチャした順番に応じて $1$2 のような番号参照を使います。

ルールは上から順に 1 件だけ適用される

`priority` がある場合は数値が小さい順、同じ優先度では配列順に評価されます。最初に一致したルールだけが適用されます。

パスパラメータを destination に展開できる

`/old/:slug` の `:slug` は `{slug}` として destination へ渡せます。正規表現ルールでは `$1`、`$2` のような番号参照も使えます。

クエリ文字列は preserve / drop / merge / replace で扱う

既定では元のクエリを維持します。不要な場合は `drop`、固定値を足したい場合は `merge` を使います。

外部リダイレクトは明示的な許可が必要

外部 URL へ飛ばす場合は `https://`、`allowExternal: true`、`allowlistHosts` が必要です。意図しないオープンリダイレクトを防ぐためです。

`forward` は同一サイト内の相対パスだけを指定できます。外部サイトへ移動させる場合は `redirect` を使い、`allowExternal` と `allowlistHosts` で明示的に許可してください。

TROUBLESHOOTING

困ったとき

まず dashboard の状態表示とログを確認します。解決しない場合は、該当画面と確認済みの内容を添えてお問い合わせください。

デプロイが始まらない

GitHub App の連携状態、対象リポジトリ、対象ブランチ、最新 push の有無を確認します。

  • プロジェクトの Git 連携画面で GitHub App がインストールされているか確認します。
  • GitHub 側で対象リポジトリが App の許可対象に含まれているか確認します。
  • アプリの設定ブランチと実際に push したブランチが一致しているか確認します。
ビルドに失敗する

dashboard のデプロイログ、ビルドコマンド、依存関係、環境変数を確認します。

  • まずログの最初の失敗箇所を見ます。依存関係のインストール、型チェック、ビルド、出力ディレクトリのどこで止まったかを切り分けます。
  • ローカルで同じ Node.js / package manager / build command を実行し、同じ失敗が再現するか確認します。
  • 秘密情報が必要な build では、dashboard に必要な環境変数が登録されているか確認します。
ルーティングが反映されない

対象ホスト、source の書き方、priority、enabled、redirect / forward の違いを確認します。

  • `scope.hosts` やルールごとの `hosts` が、実際にアクセスしているホストと一致しているか確認します。
  • `source` は既定でパス構文として評価されます。正規表現を使う場合は `patternSyntax: "regex"` を指定してください。
  • 複数のルールが一致しそうな場合は、先に適用されるルールだけが実行されます。`priority` と配列順を見直してください。