Budibaseとは：OSSの社内アプリ基盤をDocker Composeで建てる手順とデータ接続の設計

Budibaseは、社内のデータベースやAPIにつないだ申請・在庫・顧客管理などの業務アプリを、画面部品の配置と自動化の設定で組み立てるオープンソースの開発基盤です。専用のデータベースを用意しなくても、内蔵のBudibase DBにCSVを取り込めばテーブルと画面ができます。この記事では2026年10月29日時点の公式情報をもとに、データの置き場所とライセンスの分かれ方、アクション数で上限が決まる料金、公式のdocker-compose.yamlで自社サーバに建てる手順を順に確認する記事です。既存のPostgreSQLへの接続とPublic APIのリクエスト例を示したうえで、AppsmithやRetoolとの選び分けを言い切ります。

まとめ：Budibaseは内蔵DBと既存DBの両方で社内アプリを組むGPLv3の基盤

Budibaseが向くのは、Excelや紙で回している社内業務を、専用のデータベースから用意せずにアプリへ移したい案件です。内蔵のBudibase DBでテーブルを作り、画面と承認の自動化まで1つの管理画面で完結します。セルフホストのOpen source版は無料で、作る人も使う人も人数の上限がありません。ただしワークスペースは1つに限られ、監査ログやバックアップの機能は有償のEnterpriseに残っています。

自社サーバに建てるときは、公式のComposeファイルをそのまま起動しないでください。秘密情報の既定値が「budibase」や「testsecret」のままで、AI機能用に同梱されたLiteLLMの4000番ポートもホストに公開される設定です。秘密情報の入れ替え、ポートの閉鎖、版の固定の3点を済ませてから使い始めます。社外の顧客に使わせるアプリや、作り込んだ画面を長く保守する前提の案件は、コードで作る方式と比べてから決めるべきです。

Budibaseの定義と内蔵のBudibase DB・外部データで画面を組む仕組み

Budibaseでは、データの置き場所を選ぶ、画面に部品を置いてデータを結びつける、行の追加や定時の処理をきっかけに自動化を動かす、の3段で業務アプリを作ります。最初に決めるのはデータの置き場所です。

内蔵のBudibase DBと外部SQL・REST APIを使い分けるデータの置き場所

公式のBudibase DBの説明によると、内蔵DBに入れたデータはBudibaseのインスタンスに直接保存され、同じワークスペースのアプリと自動化から使えます。中身はCouchDBで、行の作成時や更新時に値を自動で埋める列も持てます。新しい業務をゼロから載せるなら、この内蔵DBが最短です。

既に業務データがあるなら、外部のデータソースを登録します。SQLの接続ページが挙げる中核の接続先は、SQL Server、MySQL/MariaDB、Oracle、PostgreSQLの4種です。ほかにREST API、Google Sheets、Firestoreなどにもつなげます。外部DBのテーブルを取り込むと、Budibase側の型へ自動で対応づけられます。基幹システムのデータを内蔵DBへ写すと二重管理になるため、正本が外にあるデータは外部接続で扱うのが原則です。

GPLv3の本体・BSLの有償機能・MPL 2.0のアプリで分かれるライセンス

リポジトリのLICENSEファイルは、Budibase全体をGPLv3と考えてよいとしたうえで、パッケージごとに条件を分けています。有償機能はpackages/proにあり、ソースを読めても商用利用の制限を外して本番で動かすことを禁じるBSLです。作ったアプリに組み込まれる部品はMPL 2.0で、アプリそのものをオープンソースにする義務はありません。

社内で使う限り、GPLv3の公開義務が問題になる場面はまずありません。注意したいのは、Budibase本体を改変して顧客に配布する、または有償機能のライセンス確認を外して運用する、という2つの使い方です。前者はGPLv3の公開義務が、後者はBSL違反が問題になります。GitHubのリポジトリのスター数は、2026年10月29日時点で28,368件でした。

Budibaseの料金体系とアクション数の上限・セルフホスト無料版の範囲

Budibaseの課金は、作る人（Creator）と使う人（End user）の人数に、月あたりのアクション数の上限を組み合わせた形です。クラウド版とセルフホスト版で考え方が大きく違います。

Cloud版Pro・Premium・Businessの月額とアクション数のハード上限

公式の料金ページで2026年10月29日に確認したクラウド版の値です。FAQによれば、月払いの額は年払いの額に20%を上乗せして計算されます。

どのプランも、使う人は1人あたり月$5、作る人の追加は1人あたり月$50の追加料金です。アクションには、自動化の各手順の実行、行の保存と削除、AIエージェントのツール呼び出しが数えられ、カスタムSQLのクエリとAPIリクエストは数えません。上限は月ごとのハードリミットで、達すると上位プランへの切り替えが必要です。行の一括取り込みや夜間の大量更新を自動化で回す業務は、先にアクション数を試算してください。

セルフホストのOpen source版で使える範囲とEnterpriseに残る機能

セルフホストのOpen source版は無料で、アクション数、作る人、使う人、行数のいずれにも上限がありません。SSOも含まれます。人数で費用が増えないため、全社員に配る申請アプリのような使い方ではクラウド版より有利です。

制約はワークスペースが1つに限られる点です。部署ごとにワークスペースを分けて作る人を切り分けたい場合や、監査ログ、バックアップと復元、ユーザーグループが必要な場合は、Self-hostのEnterpriseに上げることになります。監査ログが要件に入る業務なら、無料版での本番運用は最初から候補から外すべきです。サポートもコミュニティのみです。

公式docker-compose.yamlでBudibaseを自社サーバに建てる手順

セルフホストには、1つのコンテナに全部入りの単体イメージと、部品ごとにコンテナを分けるDocker Compose版があります。単体イメージは2コア・メモリ6GBで多くの用途に足りるとされ、試用には手軽です。本番では部品ごとに更新と監視ができるCompose版を使い、公式もLinuxのホストを推奨しています。

8つのサービスで構成される公式Composeと.envの秘密情報を入れ替える手順

公式のdocker-compose.yamlは、画面とAPIのapp-service、裏の処理を受け持つworker-service、ファイル置き場のMinIO、入口のNginx、内蔵DBのCouchDB、Redis、AI機能のLiteLLMとその保存先のPostgreSQL 16、の8サービスで構成されます。ファイル置き場のMinIOについてはMinIOとはで確認できる内容です。次の手順で3つのファイルを取り、秘密情報を入れ替えてから起動します。

# 公式の3ファイルを取得する（.env の元は hosting.properties）
mkdir budibase && cd budibase
BASE=https://raw.githubusercontent.com/Budibase/budibase/master/hosting
curl -fsSL -o docker-compose.yaml "$BASE/docker-compose.yaml"
curl -fsSL -o .env "$BASE/hosting.properties"
curl -fsSL -o litellm_config.yaml "$BASE/litellm_config.yaml"

# 既定値のままの秘密情報をランダムな値に置き換える
for k in API_ENCRYPTION_KEY JWT_SECRET MINIO_ACCESS_KEY MINIO_SECRET_KEY \
         COUCH_DB_PASSWORD REDIS_PASSWORD INTERNAL_API_KEY \
         LITELLM_SALT_KEY LITELLM_DB_PASSWORD; do
  sed -i "s|^${k}=.*|${k}=$(uuidgen)|" .env
done
sed -i "s|^LITELLM_MASTER_KEY=.*|LITELLM_MASTER_KEY=sk-$(uuidgen)|" .env

# LiteLLM のポートをホストの外へ出さない（下の h3 で説明）
echo "LITELLM_PORT=127.0.0.1:4000" >> .env

docker compose up -d

取得直後のhosting.propertiesでは、JWT_SECRETとAPI_ENCRYPTION_KEYがtestsecret、CouchDBやRedisのパスワードがbudibaseです。このまま公開すると、誰でも推測できる値で内部の部品に入れてしまいます。単体イメージのページによれば、JWT_SECRETを後から変えると既存のログインはすべて無効になります。起動前に1回で決めておくのが安全です。起動後はhttp://<サーバのIP>:10000で最初の管理者を登録します。

LiteLLMの4000番ポートを閉じる設定とv1.83.10固定版の確認

公式のComposeは、LiteLLMのポートを${LITELLM_PORT:-4000}:4000でホストに公開しています。何も指定しないと、Budibaseの入口の10000番とは別に、4000番からLiteLLMの管理APIに直接届く状態です。上の手順でLITELLM_PORTを127.0.0.1:4000にしたのは、この公開先をサーバ自身に限るためです。BudibaseからLiteLLMへの通信はコンテナ間のネットワークを通るため、この変更で動作は変わりません。

同梱されるイメージはlitellm/litellm:main-v1.83.10-stable.patch.3に固定されています。GitHubの勧告データベースでは、MCPのOAuth2転送で認証を回避できるCVE-2026-59822の影響版が1.84.0未満、権限外のルートに届くキーを発行できるCVE-2026-47101が1.83.14未満です。この固定版に修正が取り込まれているかは、2026年10月29日時点で公式に記載がありません。ポートを外へ出さないことを前提にし、ほかのCVEと修正版はLiteLLM 脆弱性で確認してください。また同梱のlitellm_config.yamlはstore_prompts_in_spend_logs: trueで、AI機能に送った文面がPostgreSQLの利用記録に残ります。LiteLLM自体の設定はLiteLLMとはにまとめています。

毎週月曜のマイナー更新に合わせたv3.50.0の版固定と更新手順

GitHubのリリースを見ると、Budibaseの安定版はv3.50.0（10月19日）、v3.49.0（10月12日）、v3.48.0（10月5日）と毎週月曜に出ています。公式Composeのapp・worker・proxyはタグの指定がなく、docker compose pullのたびに最新版へ上がります。検証してから上げたい本番環境では、次の上書きファイルで使用する版を固定する方法が取れますので、設定内容を確認してください。Docker Hubのタグはv付きのv3.50.0で、3.50.0というタグはありません。

# docker-compose.override.yaml：3つのイメージを同じ版に固定する
services:
  app-service:
    image: budibase/apps:v3.50.0
  worker-service:
    image: budibase/worker:v3.50.0
  proxy-service:
    image: budibase/proxy:v3.50.0

公式の更新手順はdocker compose pullのあとdocker compose up -dです。版を上げるときは、上書きファイルの3か所を同じ版に書き換えてから実行します。CouchDBのボリュームcouchdb3_dataに全アプリと内蔵DBのデータが入るため、更新前にボリュームの退避を手順に入れてください。無料版にはバックアップ機能が無いので、ここは自分で持つ運用になります。

既存DBへの接続とPublic APIで業務データを扱う具体的な設定例

内蔵DBで始めた業務も、いずれ既存の業務システムとデータをやり取りします。接続の向きと通り道を先に決めておくと、ファイアウォールの申請で止まりません。

同一ホストのPostgreSQLからテーブルを取り込む接続設定手順

SQLの接続ページによると、Dockerで動くBudibaseから同じマシン上のDBにつなぐときは、ホスト名にhost.docker.internal、Linuxでは172.17.0.1を指定します。localhostと書くとコンテナ自身を指すため、つながりません。接続を登録すると「Fetch tables」で取り込むテーブルを選べ、必要なテーブルだけに絞れます。

接続に使うDBユーザーは、Budibase専用に作り、取り込むテーブルへの必要な権限だけを与えます。管理者のユーザーを登録すると、画面の作り手がSQLで全テーブルに触れる状態になるためです。DBのテーブル構成を変えたら、もう一度「Fetch tables」を実行して列の定義を取り直します。権限設計の考え方はローコード開発のセキュリティリスクと対策でも整理しています。

Cloud版から社内DBへ接続するときの4つの許可IPとデータの通り道

クラウド版のBudibaseから社内のDBへつなぐ場合、接続はBudibaseのサーバからDBへ向かいます。公式の接続元IPのページは、34.246.43.190、34.255.55.113、3.248.69.251、18.203.209.221の4つをDB側のファイアウォールで許可するよう求めています。IPは変わる場合があり、登録利用者には事前に通知するとのことです。

つまりクラウド版では、社内DBをインターネット側へ開け、業務データがBudibaseのサーバを経由して画面に届きます。個人情報を含むDBを外部に開けられない会社では、この時点でセルフホスト一択です。セルフホストなら、BudibaseのサーバとDBを同じ社内ネットワークに置き、DB側ではBudibaseサーバのIPだけを許可します。

x-budibase-api-keyで行を検索するPublic APIのcurl実行例

ほかのシステムからBudibaseのデータを読み書きするときは、Public APIを使います。認証は利用者ごとのAPIキーをx-budibase-api-keyヘッダで送り、対象アプリのIDをx-budibase-app-idヘッダで指定します。次は申請テーブルから「申請中」の行を新しい順に50件取る例です。

# 申請テーブルから status が「申請中」の行を新しい順に取得する
curl -s -X POST \
  "https://budibase.example.co.jp/api/public/v1/tables/ta_xxxxxxxx/rows/search" \
  -H "x-budibase-api-key: ${BB_API_KEY}" \
  -H "x-budibase-app-id: app_xxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"query": {"equal": {"status": "申請中"}},
       "sort": {"column": "created_at", "order": "descending"},
       "paginate": true, "limit": 50}'

応答のdataに行の配列が入り、続きがあればhasNextPageがtrueになるので、bookmarkの値を次の要求に渡します。1回で取れる行数は、内蔵DBで1,000行、SQLのテーブルで5,000行までです。アプリIDのapp_dev_は編集中のアプリを指し、公開済みのデータを扱うときは_dev_を除いたIDを使います。APIキーは発行した利用者の権限で動くため、連携専用の利用者を作ってからキーを発行してください。

Budibaseの採用条件とAppsmith・Retool・コード製管理画面の選び分け

同じG8グループで扱った社内アプリ基盤と並べると、Budibaseの持ち味は内蔵DBと自動化を1つで持つ点にあります。採る場面と見送る場面を分けて示します。

内蔵DBで小さく始めて承認フローまで持つならBudibaseを採る判断基準

Budibaseを選ぶのは、次の条件が2つ以上当てはまる案件です。1つ目の条件には、正本のデータベースがまだ無く、Excelや紙の業務をそのままアプリに移したい場合が当てはまります。2つ目は、申請と承認、通知、定時の集計といった自動化を画面と同じ基盤で持ちたい場合です。3つ目は、全社員のように使う人が多く、人数で費用が増えないセルフホストの無料版が効く場合になります。

画面はアプリ内のロールで出し分けます。標準はログイン不要のPublic、一般のApp user、上位のAdminの3段で、上位のロールでは下位のロールの画面もすべて閲覧できる仕様です。部署ごとのカスタムロールも足せるので、申請者と承認者で見える画面を分ける業務は設定だけで組めます。要件の整理から画面の構築、既存システムとの接続までをまとめて任せたい場合は、ノーコード・ローコードアプリ開発として相談いただけます。

社外公開や作り込みの多い画面でBudibaseを見送る場面と代替の比較表

Budibaseを選ばないのは、社外の顧客が使う画面、独自のデザインや複雑な画面遷移を作り込む画面、監査ログが必須なのに有償版を契約できない案件です。代替は次の表で選びます。

既存DBの上に管理画面を載せるだけなら、Apache-2.0のAppsmithも同じ土俵に立ちます。どちらもDocker Composeで自社サーバに建てられるので、内蔵DBと自動化が要るかどうかで決めてください。運用を任せたいならRetool、社外向けや長期の作り込みならReact-adminのようなコードで書く管理画面が合います。

よくある質問：Budibaseの無料範囲・日本語・データの保存先・AI機能

Budibaseの導入検討でよく出る質問に、2026年10月29日時点の公式情報をもとに答えます。

Budibaseは無料で使えますか？

使えます。セルフホストのOpen source版は無料で、作る人、使う人、アクション数、行数に上限がありません。制約はワークスペースが1つであることと、監査ログやバックアップ機能が無いことです。料金ページにクラウド版の無料プランは無く、最小のProが月$19からで、有料プランには14日間の無料トライアルがあります。サーバ代と運用の手間は自社の負担になる点も見込んでください。

Budibaseの画面やドキュメントは日本語に対応していますか？

2026年10月29日時点で、公式ドキュメントは英語で提供されており、日本語版は確認できません。作るアプリの画面に表示する文言やテーブルの列名は日本語で書けるため、使う人にとっては日本語のアプリになります。作る人は英語のドキュメントを読みながら組むことになるので、社内で担当者を決め、つまずいた箇所を手順書にまとめておくと引き継ぎが楽になります。

Budibaseで作ったアプリのデータはどこに保存されますか？

内蔵のBudibase DBに入れたデータは、Budibaseのインスタンスに保存されます。セルフホストなら自社サーバのCouchDB、クラウド版ならBudibase社のサーバです。外部のPostgreSQLなどにつないだデータは元のDBに残り、Budibaseは読み書きの窓口になります。添付ファイルはMinIOに入ります。

BudibaseのAI機能はセルフホストでも使えますか？

使えますが、外への通信が要ります。公式のネットワーク要件によると、セルフホスト版のAI機能はBudibase Cloudへの外向き通信に依存し、通信を遮断すると使えません。有償ライセンスの認証にも、外向きのHTTPSが必要です。閉じたネットワークで動かす場合は、AI機能を使わない前提で設計してください。

BudibaseとNocoBaseはどちらを選べばよいですか？

データの持ち方で選びます。Budibaseは内蔵DBか既存DBの上に画面と自動化を作る基盤で、作れるアプリの形は画面部品の組み合わせで決まります。NocoBaseはデータモデルの定義から始め、プラグインで機能を足す方式です。どちらもDockerで建てられるので、要件の画面を1つずつ試作して比べるのが確実です。

関連記事

• Appsmithとは？OSSの社内アプリビルダーをDockerで建てる手順とRetoolとの選び分け：既存DBの上に管理画面を載せるOSSの比較先です
• Retoolとは？社内管理画面を短期間で作る構成とDB直結の権限設計、内製の限界：クラウドで運用を任せる商用基盤との違いが分かります
• LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順とフォールバック・予算設定【2026年10月】：公式Composeに同梱されるAI中継の設定を確認できます
• ローコードツールとは？用途別の比較と選定基準・スクラッチ開発との使い分けを解説：Budibaseを含むツール選定の前提を整理しています
• ローコード開発のセキュリティリスクと対策｜権限設計・野良アプリ・発注時の確認項目：DB接続ユーザーと野良アプリの管理に役立ちます