Busabase

Busabase のセルフホスト

どのエディションが必要か、各デプロイ形態の運用コスト、そして実測したハードウェア要件 — 何かをダウンロードする前に判断できるように。

Busabase を自分で運用する理由は、たいてい 2 つのどちらかです。データを社外に出せないか、チームがこれを完全に自分たちのものにしたいか。どちらも正当な理由ですが、行き着くエディションは違います。

どのエディションか

オープンソース版PremiumEnterprise
価格無料(MIT)$19 / シート / 月お問い合わせ
承認エンジン、全ノードタイプ
REST API・MCP・エージェント連携
ログインとユーザーアカウント
組織・スペース・メンバーのロール
システム管理コンソール、監査ログ出力
API キーと Vault シークレット
SSO / LDAP
SLA と専任サポートエンジニア

オープンソース版は機能を削った Premium ではありません。同じエンジンで、ユーザー管理が最初から存在しないだけです — 1 台、1 人、ログイン画面なし。それで十分な人は実際に多く、あなたもそうなら、それを使ってここで読むのをやめて構いません。

2 人目がログインする必要が出た瞬間に必要になるのが Premium です。追加されるものはすべて、複数人が同じサーバーを共有することに関わります: アカウント、ロール、誰が何を変えたか、そしてそれらを管理する画面。

Premium はシート単位のライセンスで、席数 = このインスタンスにログインできるメンバー数です。ライセンスが期限切れになっても締め出されることはありません — インスタンスが読み取り専用になり、データは読めるしエクスポートもできます。ライセンスを参照。

どのデプロイ形態か

オールインワンComposeKubernetes
プロセスコンテナ 1 つ4 サービスHelm chart
Postgresコンテナ内独立サービス自前 or クラスタ内
オブジェクトストレージコンテナ内SeaweedFS サービス自前 or クラスタ内
向いている用途試用、20 人以下本番大規模・規制の厳しい環境
アップグレードpull して再起動pull して compose up -dhelm upgrade
状況利用可能利用可能利用可能

まずオールインワンから。docker run 1 回で済み、Busabase が本当に合うかを判断する最短ルートです。後から Compose へ移るのは「バックアップから新しいデプロイへリストアする」作業であって、移行プロジェクトではありません。

オールインワンイメージは Postgres をコンテナ内で動かします。組み込みの代替品ではなく本物の Postgres ですが、すべてが 1 つのコンテナのライフサイクルを共有します — named volume なしで docker rm すると、データベースも一緒に消えます。必ず -v busabase-data:/data を付けてください。

サーバーに必要なもの

空のボリュームでのコールドスタート実測値(2026-09-05、Docker 29.6):

最小実測値
CPU2 vCPU
メモリ2 GBアイドル時 548 MiB
ディスク10 GB初回起動後の /data は 50 MB
開放ポート3000/tcp8333/tcpアプリ + オブジェクトストレージ
起動時間docker run から /api/health 正常まで 24 秒

「最小」は実測のアイドル値をそのまま要件にするのではなく、余裕を上乗せした値です。アイドル 548 MiB というのが、メモリを 1 GB ではなく 2 GB としている理由です: その数字には同時アップロード、マイグレーション実行、負荷時の Postgres 自身の作業メモリの余地がありません。

Postgres がコンテナ外に公開されることはありません。オブジェクトストレージは公開が必要です: アップロードは presigned PUT、ダウンロードはリダイレクトで、ブラウザがストレージへ直接アクセスします(Busabase Cloud で S3 に対して行うのと同じ形)。両方を公開し、両方の前段に TLS 付きリバースプロキシを置いてください — Compose での本番構成を参照。

次に読むもの

On this page