サーバーモードPostgres + 中央認証
マルチチーム対応、JWKS 経由で JWT の検証を行います。この Web アプリは、認証サーバーの /api/auth/.well-known/jwks.json.
Docker のクイックスタート
公式画像 arnaudprioul/i18n-dashboardDocker Hub 上の両方の linux/amd64そして linux/arm64. チームの規模に応じて、3つの実施方法があります。
ローカルモードSQLite、認証なし
単一ユーザー、単一チーム向け。翻訳データはDockerボリュームに保存されます。最大約10万件のキーを自社でホストする場合に最適です。これを次のように保存してください docker-compose.ymlそして実行する docker compose up -d:
デフォルトでは
127.0.0.1のみにバインドされます。このマシンからのみ到達可能で、ネットワーク上の他の端末からは到達できません。ローカルモードにはログイン画面がないため、ポートに到達できる人は誰でもすべてのプロジェクトに完全にアクセスできてしまいます — このバインディングを広げるのは、信頼できるファイアウォールやVPNの内側でのみ行ってください。完全なクイックスタート、環境変数、およびトラブルシューティングについては、 Docker Hub の概要.
デスクトップモードタウリ、地域データ
Native macOS / Windows / Linux ビルドで、Nitro サーバーと SQLite が組み込まれています。Docker も、設定が必要なデータベースも不要です。ログインはオンラインアカウントを通じて行われます。
- macOS
- Windows
- Linux
目的別に探す
8つのグループ：はじめに、フレームワークガイド、デプロイ、管理、品質、リファレンス、請求、サポート。
はじめに
フレームワークガイド
展開
管理
品質と連携
参考文献
請求・料金
サポート
環境変数
すべての runtimeConfigこの値は、実行時に NUXT_*prefix — Nitro の標準的な規約。次のような単純な名前（ I18N_DB_HOSTワイヤプロトコル変数として明示的に指定されていない限り、これらは黙って無視されます。
完全な参考文献 （すべての変数、デフォルト値、スコープ、および移行に関する注意事項）は、Docker Hub のページに掲載されており、イメージのすぐそばで確認できます：
Docker Hub で環境変数の完全なリファレンスを開く →最も一般的なノブ
I18N_APP_MODE—local/server/desktop. サーバーモードでは、実際のデータベースと中央認証システムが必要です。NUXT_DB_CLIENT+NUXT_DB_HOST+NUXT_DB_NAME+NUXT_DB_USER+NUXT_DB_PASSWORD— Postgres / SQLite / MySQL への接続。NUXT_SESSION_SECRET— 本番環境では必須です。以下のコマンドで生成してください。openssl rand -hex 32.NUXT_CENTRAL_AUTH_URL+NUXT_PUBLIC_CENTRAL_AUTH_URL— 認証発行者のサーバーサイドおよびブラウザサイドのURL（JWKSに準拠している必要があります）。NUXT_AUTH_JWT_ISSUER+NUXT_AUTH_JWT_AUDIENCE— 予想されるiss/audアクセストークンに対するクレーム。NUXT_INTERNAL_API_SECRET— Webアプリと中央認証サーバー間の通信における共有HMAC。両側で同一でなければならない。NUXT_SMTP_HOST+NUXT_SMTP_PORT+NUXT_SMTP_USER+NUXT_SMTP_PASS+NUXT_SMTP_FROM— ワークフロー通知。メールを無効にするには、ホスト欄を空欄にしてください。NUXT_DASHBOARD_URL— このWebアプリインスタンスの公開URL。トランザクションメールのリンクで使用されます。
30秒でSMTPを設定する
任意のSMTPリレーを選択し、以下の4つの値を指定してください。そうすれば、ワークフローのイベントが発生するたびに、画像がそのリレーを経由してメールを送信します。
ローカル開発やスモークテストを行う場合は、同梱されている Mailpitサービス： NUXT_SMTP_HOST=mailpit, NUXT_SMTP_PORT=1025.
ロールと権限
ロールはインスタンス全体ではなくプロジェクトごとに付与されます — 3つの階層があり、それぞれそのプロジェクトで許可される範囲が広がります。
translator | moderator | admin | super_admin | |
|---|---|---|---|---|
| 翻訳の編集 | 可 | 可 | 可 | 可 |
| 翻訳の承認 | 不可 | 可 | 可 | 可 |
| プロジェクトの管理（設定、スキャン、同期） | 不可 | 不可 | 可 | 可 |
| プロジェクトメンバーの管理 | 不可 | 不可 | 可 | 可 |
プロジェクトのUsersページからロールを割り当てます — メンバーを選び、translator、moderator、admin のいずれかを選択します。あるプロジェクトの admin は、他のプロジェクトにも、それを所有するアカウントにも権限を持ちません。
super_admin フラグ
super_admin はどのプロジェクトロールとも独立しています — 上記のすべてのチェックを、すべてのプロジェクトで無効化するアカウントレベルのフラグです。ローカルのセットアップウィザードを通じてであれ、サーバーモードでの最初のサインインであれ、インスタンス上で最初に作成されたアカウントに自動的に付与され、現在ダッシュボード内から他のアカウントを super_admin に昇格させる方法はありません。
Webhook
Admin → Integrations（super_admin 限定）からプロジェクトごとに設定します。サブスクライブしたイベントがそのプロジェクトで発生するたびに、Webhook がエンドポイントへ送信されます。
イベント
Webhook は次のいずれかのイベントを購読できます。
key.deleted— 1つ以上の翻訳キーが削除されたtranslation.saved— 翻訳値が保存されたscan.completed— 新規または変更されたキーのソースコードスキャンが完了したsync.completed— 設定された翻訳プロバイダーとの同期が完了した
配信の検証
汎用HTTPエンドポイントへのすべての配信には、X-Webhook-Signature（Webhook作成時に一度だけ表示されるシークレットを使ったJSON本文のHMAC-SHA256）と、X-Webhook-Eventが付与されます。SlackとDiscordのエンドポイントURLは自動検出され、代わりにそれぞれのプラットフォーム独自のメッセージ形式で送信されます。この2つはURL自体で認証するため、署名ヘッダーが付くことはありません。
送信先URLの要件
- パブリックなアドレスに解決される必要があります — loopback、プライベート（RFC1918／unique-local）、link-local 宛先は、URLを保存する時点と、配信を試みるたび（各リダイレクトのホップを含む）の両方で拒否されます。これにより、ホスト名がその2つのタイミングで異なる解決結果を返す抜け道を塞いでいます。
- 本番環境では、エンドポイントは
https:を使用する必要があります — 素のHTTPは本番環境以外でのみ許容されます。 - URLに埋め込まれた認証情報（
https://user:pass@host）は拒否されます。 - 配信は10秒でタイムアウトし、リダイレクトは最大5回まで追跡します。
Webhookの横にある▶ボタンを使うと、実際のイベントを待たずに、署名済みのpingイベントをその場で送信できます。
バックアップと復元
super_admin 限定で、Admin → Backup または CLI から実行します。バックアップは、すべてのプロジェクト、翻訳、ユーザー、設定を網羅する単一のJSONエクスポートです。
常に除外されるもの：refresh_tokens, password_reset_tokens, otp_tokens, webhook_deliveries、および各アカウントのパスワードハッシュ。
ダッシュボードから
「Download backup」を押すと、日付付きのJSONファイル（例：i18n-dashboard-backup-2026-07-31.json）が保存されます。
復元では、そのファイルを再度アップロードし、モードを選択します。
- merge（デフォルト）は既存の行を保持し、不足している分だけを挿入します
- replace は各テーブルの既存データを先に削除してからインポートします — 取り消せません
結果には、復元された行数、スキップされた重複、失敗した行が示されます。部分的な復元を黙って成功として扱うことはありません。
CLIから
どちらのコマンドにも権限を昇格させた管理者トークンが必要です — NUXT_CLI_ADMIN_TOKEN（フォールバック先はNUXT_CLI_TOKEN）— --tokenで渡すか、CLIの設定から解決されます。
トラブルシューティング
セルフホスト利用者が最もよく直面する問題を、Dockerイメージ自体のトラブルシューティングガイドからそのまま抜粋しています。
Refusing to start: NUXT_DB_HOST is still the build-time default 'localhost'— 環境がまだ NUXT_* プレフィックス以前の名前を使っています。データベース関連の環境変数（NUXT_DB_HOST、NUXT_DB_USER など）に NUXT_ プレフィックスを付けてください。Webapp returns 401 on every API call— JWKSエンドポイントに到達できません。同じcompose内で両方のサービスが動いている場合はDockerネットワークのホスト名を使い、NUXT_CENTRAL_AUTH_URL がコンテナ内から解決できることを確認してください。JWT verification fails right after a key rotation— JWKSキャッシュは1時間保持され、キーID未一致から30秒後に更新されます。短い猶予期間を設けるか、ローテーション直後にWebアプリを再起動してください。Health check shows "0 keys" despite a non-empty database— おそらく間違ったデータベースに接続しています。取り残されたSQLiteファイルにフォールバックしていないか、NUXT_DB_HOST が実際に設定されているか確認してください。Container starts on port 3000 instead of 6001— Nitro は PORT を直接読み取ります。イメージは I18N_PORT=6001 を設定していますが、PORT を上書きするとバインド先が変わります — ports: のマッピングと一致させてください。Can't reach the dashboard from another machine— デフォルトのCompose設定では想定どおりです — ポートは意図的に 127.0.0.1 にバインドされています。意図的に公開するには、到達可能なアドレスにバインドするか、前段にリバースプロキシを配置してください。