セルフホスト - はじめに

このガイドでは、空のサーバーから、サインインできる実行中のKaneraに移行します。

要件、容量、環境ファイル、スタックの起動、動作の確認など、あらゆるデプロイメントに必要な部分をカバーしています。オプションの部分 (パブリック API、MCP、電子メール、ストレージ、バックアップ) にはそれぞれ独自のページがあり、最後にリンクされています。

要件

必要なものは次のとおりです。

Docker と Docker Compose を備えたサーバー。
サーバーを指すドメイン。
Kanera の前の HTTPS (通常は Caddy、Traefik、nginx、またはクラウドロードバランサー経由)。
Kanera に電子メールを送信させる場合は、SMTP 資格情報。
PostgreSQL データとアップロードされたファイルをバックアップするための計画。

計画能力

Kaneraは小規模なチーム規模では軽量である。その構成ファイルは CPU やメモリのハード制限を設定せず、移行サービスは起動後に終了します。デフォルトのスタックは、PostgreSQL、Valkey、2 つの API レプリカ、ワーカー、パブリック API、MCP、および nginx を実行します。

これらを出発点として使用し、独自の同時アクティビティ、ファイル、統合、およびバックアップウィンドウを測定します。

典型的なチーム	始動容量	ローカルディスク	ノート
個人的または軽度に使用される	1 vCPU、1 GiB RAM	10 GiB	使用する `API_REPLICAS=1` オプションの監視プロファイルはオフのままにします。
アクティブユーザー数 1 ～ 25	1 ～ 2 vCPU、2 GiB RAM	20 GiB	通常のボードアクティビティ、通知、ライトの統合に快適です。
アクティブユーザー数 26 ～ 100	2 ～ 4 vCPU、4 GiB RAM	40 GiB	同時アクティビティ、アップロード、API トラフィック、Webhook、データベースキャッシュのためのヘッドルームを追加します。
100人以上のアクティブユーザー	4 個以上の vCPU、8 個以上の GiB RAM	80 GiB 以上	起動前に代表的なデータを使用して負荷テストを行い、次に API レプリカをスケールし、観察された使用状況に基づいて PostgreSQL を調整します。

これらは計画ベースラインであり、厳しいユーザー制限や測定された容量保証ではありません。登録されたアカウントの数よりも、同時アクティビティの方が重要です。通常、ファイルのボリュームと保存期間は、Kanera 自体よりもディスク要件を大きく左右します。データベースとアップロードされたファイルのバックアップをサーバーのプライマリディスクの外部に保持し、ディスクの増加を警告します。

オプションの Prometheus、Grafana、Loki、Alloy、およびエクスポーター監視プロファイルにより、いくつかのプロセスが追加されます。導入ガイドでは、ログボリュームとダッシュボードの使用状況に応じて、およそ 0.7 ～ 1.5 GiB の追加メモリが必要と見積もっています。個別に予算を設定するか、別のホストで監視を実行します。

各サービスが何を行うのか、どのサービスを公開するのかについては、次を参照してください。サービスとルーティング.

Kaneraをダウンロード

Kanera は、事前に構築された Docker イメージとして出荷されます。それぞれリリースすぐに実行できるものが含まれています docker-compose.yml それらを取得するため、リポジトリの複製やビルドは不要です。

サーバー上で、Kanera 用のディレクトリを作成し、最新リリースから構成ファイルとサンプル環境ファイルをダウンロードします。

mkdir kanera && cd kanera
curl -fsSLo docker-compose.yml https://github.com/happendev/Kanera/releases/latest/download/docker-compose.yml
curl -fsSLo .env https://github.com/happendev/Kanera/releases/latest/download/env.example

作成ファイルはすべてのイメージをそのリリースに固定するため、次の操作を行うまで何も変更されません。更新。 Docker Compose 2.23 以降が必要です (docker compose version).

環境ファイルを設定する

開く .env すべてのプレースホルダーを置き換えます。必要な実稼働値を設定します。

WEB_ORIGIN=https://kanera.example.com
COOKIE_DOMAIN=kanera.example.com
COOKIE_SECURE=true
KANERA_ENVIRONMENT=production

POSTGRES_PASSWORD=<openssl rand -hex 32>
JWT_SECRET=<openssl rand -hex 32>
MCP_INTERNAL_SECRET=<openssl rand -hex 32>
MFA_ENCRYPTION_KEY=<openssl rand -hex 32>
MEDIA_SIGNING_SECRET=<openssl rand -hex 32>
SECRETS_ENCRYPTION_KEY=<openssl rand -hex 32>

これらのシークレットは再デプロイ後も安定した状態に保ちます。変化する JWT_SECRET ユーザーをサインアウトします。変化する MFA_ENCRYPTION_KEY 登録された認証子と MFA チャレンジを無効にします。変化する MEDIA_SIGNING_SECRET 既存の署名付きメディア URL を無効にします。 MCP_INTERNAL_SECRET API に対して MCP サービスを認証します。 SECRETS_ENCRYPTION_KEY 保存された統合秘密を保護するものであり、とは区別する必要があります。 JWT_SECRET.

セルフホストモードがデフォルトです。

KANERA_DEPLOYMENT_MODE=self_hosted

Kanera SaaS スタイルのホスト型展開を実行している場合を除き、ホスト型 Stripe 請求変数を設定しないでください。

参照環境リファレンス本番環境の設定と env.full.example すべてのオプションの調整値とデフォルト。

スタートKanera

docker compose up -d

Docker がイメージをプルし、移行サービスがデータベースを一度セットアップします。 api, worker、そして public-api 始めます。 MCP サービスは、パブリック API ヘルスチェックに合格した後に開始されます。

導入を確認する

ブラウザで Web ドメインを開きます。

https://kanera.example.com

便利なチェック:

docker compose ps
docker compose logs -f api
docker compose logs -f worker
docker compose logs -f public-api
docker compose logs -f mcp

ヘルスチェック:

curl https://kanera.example.com/api/health
curl https://api.kanera.example.com/health
curl https://mcp.kanera.example.com/health

パブリック API および MCP チェックは、それらのサービスが公開されている場合にのみ適用されます。

何かが思い浮かばない場合は、解決してくださいよくある問題症状別ではなく順番に。

必要なものを設定する

サインインしてボードを使用するには、以下のことは必要ありません。必要に応じて各部分を追加します。

ページ	カバー
環境リファレンス	必要なシークレット、パブリック URL、アクセスポリシー、ストレージ、配信、スケーリング、保持、モニタリング、管理設定。
サービスとルーティング	各サービスの機能、推奨ドメイン、公開ポート、およびリバースプロキシの信頼。
電子メールと通知	SMTP、ブラウザプッシュ、個人の ntfy/Gotify/webhook 宛先、およびチャット宛先。
統合とAPI	パブリック API と MCP、AI エージェント用の OAuth、および Trello 添付ファイルのコピーを公開します。
ストレージとバックアップ	ローカルまたは S3 アップロードストレージ、データベースとファイルのバックアップ、および保持する価値のある秘密。
アップデートとスケーリング	新しいリリースへの更新とレプリカの数。

実装に基づいたデプロイメントのリファレンスについては、次を参照してください。 Kanera リポジトリの DEPLOY.md.

要件​

計画能力​

Kaneraをダウンロード​

環境ファイルを設定する​

スタートKanera​

導入を確認する​

必要なものを設定する​

要件