NocoBaseは、データ構造を先に定義し、その上に画面と権限をノーコードで組み立てるオープンソースの業務システム基盤です。2026年11月2日時点の安定版は10月31日公開の2.2.37で、作り直しにあたるNocoBase 3はベータ版として別系統で開発が進んでいます。この記事では、Docker Composeでの起動、APIキーによる外部連携、MCPサーバーとCLIを使ったAIエージェントからの操作、日本語化、ライセンスと価格までを、検証環境で2.2.37を実際に動かして確かめた結果とあわせて整理しました。
まとめ：社内利用に向くNocoBase 2.2系と3系の本番採用条件
NocoBaseで最初に決めるのは画面ではなく、コレクション（テーブル）と項目、ロールごとの権限です。画面は後から何枚でも作れるため、扱うデータが決まっている業務ほど早く形になります。
- 本番で使うのは2.2系の数字タグです。NocoBase 3は公式ドキュメントが「全パッケージがベータでAPIが変わりうる」と明記しており、2系のアプリはそのまま3系へ上げられず作り直しになります。
- 初期状態では誰でもアカウントを新規登録できました。初期パスワードの変更と、新規登録を閉じる設定を最初に済ませます。
APP_KEYを変えると、発行済みのAPIキーだけでなくログイン中のセッションも無効になりました。通常運用では変えず、変えるときはキーの再発行と全員の再ログインを前提にします。- Claude CodeやCodexからは、既定で有効なMCPサーバー（
/api/mcp）か、CLIのnbで操作できます。権限はAPIキーに付けたロールで決まります。 - Community版は無料で商用利用できます。ただし公衆向けのノーコードSaaSとしての提供は禁止で、顧客へ業務アプリを販売する権利が条文で明記されているのはProfessional以上です。
社内向けの業務システムなら有力な選択肢、顧客へ納品・販売する案件ならProfessionalの費用を先に見積もる。これが2026年11月時点の結論です。
NocoBaseの位置づけと、2系・3系が並ぶ版の現況
ノーコードツールは種類が多いため、NocoBaseがどの層を担う製品かと、今どの版を選ぶべきかを先に固定します。
データモデル駆動のノーコード基盤とkintone・Retoolとの違い
NocoBaseは、データ構造と画面を切り離して設計します。1つのコレクションに対して、表、カード、カンバン、フォームといったブロックを必要な数だけ置けます。機能の大半はプラグインとして実装されており、検証環境の2.2.37では98個のプラグインが一覧に並び、ワークフロー、APIキー、MCPサーバー、AI関連のプラグインが最初から有効でした。
kintoneのようなSaaS型との違いは、自社のサーバーに置き、データベースまで自分で持つことです。Retoolのような社内ツール作成サービスとは、既存DBに画面を被せるだけでなく、NocoBase自身がデータ構造と権限を管理する点で異なります。同じOSSの社内ツール基盤では、既存DBへの接続を中心に据えるBudibaseの構築手順とデータ接続の設計や、AppsmithとRetoolの選び分けも比較対象になります。
安定版2.2.37とNocoBase 3ベータ、GitHubとドキュメントの見分け方
GitHubのリリース一覧では、安定版のv2.2.37が2026年10月31日に公開されました。2.2系は10月19日の2.2.28から31日の2.2.37まで、13日間で10回のパッチが出ています。並行して2.3.0-beta.19と2.4.0-alpha.14が10月29日に公開されており、2系だけで安定・ベータ・アルファの3系列があります。
紛らわしいのは、GitHubのnocobase/nocobaseリポジトリの既定ブランチがNocoBase 3のv3-developに切り替わっている点です。トップのREADMEはNocoBase 3の説明で、Node.js 24以上とpnpm 11を前提にSQLiteで動かす手順が載っています。スター数は11月2日時点で約2.5万です。
ドキュメントも分かれました。docs.nocobase.comのトップはNocoBase 3のドキュメントで、2系はnocode.docs.nocobase.comに移っています（日本語版あり）。検索で古いdocs.nocobase.comのURLを開くと2系のページへ転送されますが、トップから辿ると3系の内容になるので、読んでいる版を確かめてから手順を写してください。
Docker ComposeでNocoBase 2.2.37を起動し、初期設定を閉じる手順
インストール方法はDocker、create-nocobase-app、Gitソース、それにCLIのnb initがあります。ノーコード中心で使うならDockerが公式の推奨で、アップグレードもイメージの入れ替えで済みます。
PostgreSQL 16と組むdocker-compose.ymlと起動までの時間
公式のDockerインストール手順は、PostgreSQL 16、MySQL 8、MariaDB 11の構成例を示しています。対応するメインDBの下限は、メインデータソースの対応表でMySQL 8.0.17、PostgreSQL 10、MariaDB 10.9です。版を2.2.37に固定したPostgreSQL版の構成例を示します。
services:
app:
image: nocobase/nocobase:2.2.37
restart: always
depends_on:
- postgres
environment:
- APP_KEY=change-me-to-random-string
- DB_DIALECT=postgres
- DB_HOST=postgres
- DB_PORT=5432
- DB_DATABASE=nocobase
- DB_USER=nocobase
- DB_PASSWORD=change-me
- TZ=Asia/Tokyo
volumes:
- ./storage:/app/nocobase/storage
ports:
- "127.0.0.1:13000:80"
postgres:
image: postgres:16
restart: always
environment:
POSTGRES_USER: nocobase
POSTGRES_DB: nocobase
POSTGRES_PASSWORD: change-me
volumes:
- ./storage/db/postgres:/var/lib/postgresql/datadocker compose pullでイメージを取得し、docker compose up -dで起動、docker compose logs -f appで初期化を待ちます。初回起動では組み込みプラグインのインストールが走ります。検証環境（colima上のDocker）では取得に約1分、起動から約1分でAPIが応答しましたが、時間は回線とマシンで変わるため、ログで初期化の完了を確かめてください。ブラウザでhttp://localhost:13000を開き、初期アカウント[email protected]とパスワードadmin123でログインします。
タグはlatestのほか、画面用Nginxを含まない-no-nginx、追加ツール入りの-full、パッチ更新に追随する2.2があります。本番は2.2.37のような数字タグで固定し、ホスト側のNginxから127.0.0.1:13000へプロキシしてHTTPSをホスト側で処理する構成が公式の推奨です。
初期パスワードの変更と新規登録の無効化
検証環境で起動直後の状態を調べたところ、システム設定のallowSignUpがtrueになっており、ログインしていない状態からauth:signUpでアカウントを作成できました。作られたユーザーにはmemberロールが付き、新しく作ったコレクションの一覧は「No permissions」で拒否されました。ただし、他のデータや操作まで安全と確認したわけではなく、新規登録を開いたまま公開すると第三者がアカウントを作成できます。
初回ログインの直後に、管理者のパスワード変更と、認証設定で新規登録を無効にする操作を済ませてください。初期パスワードadmin123は公開された値なので、変更しないまま公開すれば誰でも管理者としてログインできます。
APP_KEYを変えるとAPIキーもログインも切れる：本番前に決める値
APP_KEYはトークンの署名に使う秘密値で、APIキーの公式ドキュメントは「変更すると以前に追加したすべてのAPIキーが無効になる」と警告しています。検証環境でAPP_KEYだけを書き換えてコンテナを作り直すと、管理者用と連携用のAPIキー、それにブラウザのログイン中トークンまで、すべてがINVALID_TOKENで拒否されました。キーの一覧画面には無効になったキーが残ったままなので、画面を見ても失効に気づけません。
検証環境と本番環境では別の値を使い、本番の値は秘密情報の保管先で管理します。通常運用で不用意に変更せず、漏えい時などに変更が必要な場合は、APIキーの再発行と利用者の再ログインを含めて切り替えます。TZも同じで、日本語版ドキュメントの構成例はAsia/Shanghaiのままです。日付の表示と集計を日本時間で扱うなら、運用開始前にAsia/Tokyoへ変えます。
管理画面を日本語にする設定と日本語ドキュメントの場所
起動直後の有効言語はen-USだけで、画面は英語です。システム設定の「Enabled languages」に日本語（ja-JP）を追加し、既定の言語を日本語にすると切り替わります。検証環境でもja-JPの言語パックが返ることを確認しました。
自分で作ったコレクション名や項目名は自動では訳されません。ローカライゼーション管理のプラグインで翻訳エントリーを同期して訳を入れるか、AI従業員にまとめて翻訳させる機能を使います。日本語のドキュメントは前述のnocode.docs.nocobase.com/ja/配下ですが、英語版より更新が遅れるページもあるため、手順が合わないときは英語版と見比べてください。
コレクション・画面の作成とAPIキーによるデータ連携
起動できたら、データの定義、画面の配置、外部からの読み書きの順に進めます。以下のAPI例では、名前がtodosのコレクションと、名前がtitleの単一行テキスト項目を先に作成してください。更新対象のIDは作成レスポンスで確認し、例の1を実際の値に置き換えます。
コレクションとブロックの関係、Excel台帳から移すときの項目設計
コレクションは業務データの器で、項目の型、必須かどうか、他のコレクションとの関連を管理画面から定義します。画面はページの上にブロックを置き、表示するコレクションを指定して作ります。
Excelの台帳から移す案件では、シートをそのままコレクションにしないことが肝心です。1行に顧客名・担当者名・案件名が混在している台帳は、顧客と案件を別のコレクションに分けて関連項目でつなぎます。分けないまま移すと、同じ顧客の表記揺れが残り、集計前に名寄せが必要になる場合があります。顧客IDで関連付けると、名称変更や表記揺れの影響を抑えられます。
APIキーを発行してtodos:listを呼ぶ手順
APIは{baseURL}/{コレクション名}:{アクション}の形式で、一覧は:listをGET、作成と更新は:createと:updateをPOSTで呼びます。キーは管理画面の設定にあるAPI keysから、名前、ロール、有効期限を指定して発行します。2.2.37の初期状態ではAPIキーのプラグインが有効でしたが、無効になっている環境ではプラグイン管理で有効にしてから進めます。
# 一覧の取得（todos コレクション）
curl 'http://localhost:13000/api/todos:list' \
--header 'Authorization: Bearer <APIキー>'
# レコードの作成
curl --request POST 'http://localhost:13000/api/todos:create' \
--header 'Authorization: Bearer <APIキー>' \
--header 'Content-Type: application/json' \
--data '{"title": "請求書の発行"}'
# 主キー 1 のレコードを更新
curl --request POST 'http://localhost:13000/api/todos:update?filterByTk=1' \
--header 'Authorization: Bearer <APIキー>' \
--header 'Content-Type: application/json' \
--data '{"title": "請求書の発行（済）"}'検証環境では、一覧が{"data":[…],"meta":{"count":1,"page":1,"pageSize":20,"totalPage":1}}の形で返り、既定のページサイズは20件でした。認証ヘッダーを付けずに呼ぶとEMPTY_TOKENで拒否されます。キーの文字列は発行時にしか表示されないため、その場で保管先へ移してください。
連携用ロールで権限を絞る：キーに付けられるのは自分のロールだけ
APIキーの使い方のドキュメントのとおり、要求の権限はキーに割り当てたロールで決まります。検証環境で試すと、管理者が自分の持っていないロールをキーに付けようとした要求は「Role not found」で拒否されました。キーに付けられるのは、発行するユーザー自身が持つロールだけです。
そこで、連携専用のユーザーと、必要なコレクションの必要な操作だけを許したロールを作り、そのユーザーでキーを発行します。todosの閲覧だけを許したロールのキーでは、一覧は取得でき、作成とusers:listは「No permissions」で拒否されました。連携ユーザーが自分でキーを発行するには、そのロールのシステム権限でAPIキー設定（ACLのpm.api-keys.configuration）を許可しておく必要があります。
逆に、管理者アカウントはrootロールで有効期限なしのキーまで発行できてしまいます。連携先に渡すキーを管理者のまま作るのは避けてください。ローコード製品全般の権限設計と野良アプリ化の防ぎ方はローコード開発のセキュリティリスクと対策で扱っています。
AIエージェントからNocoBaseを操作する：MCPサーバー・CLI・Skills
NocoBaseの公式サイトは、Claude Code、Codex、CursorなどのコーディングエージェントにCLIとSkillsを渡し、人はノーコード画面で直す、という分担を前面に出しています。2系で使える入口は、MCPサーバー、CLIのnb、エージェント向けのSkillsの3つです。画面内で動くAI従業員は、LLMサービスの設定でOpenAI、Gemini、Claude、DeepSeek、Qwen、Kimi、Ollamaのローカルモデルを選べます。
MCPサーバー（/api/mcp）とClaude Code・Codexの接続設定
NocoBase MCPのドキュメントによると、MCPサーバーはCommunity版から使える組み込みプラグインで、既定で有効です。アドレスはメインアプリならhttp(s)://<host>:<port>/api/mcp、通信方式はstreamable HTTPで、認証はAPIキーかOAuthです。Claude Codeへは次のように登録します。
# Claude Code（APIキー認証）
claude mcp add --transport http nocobase https://<host>:<port>/api/mcp \
--header "Authorization: Bearer <APIキー>"
# Codex（APIキーを環境変数から渡す）
export NOCOBASE_API_TOKEN=<APIキー>
codex mcp add nocobase --url https://<host>:<port>/api/mcp \
--bearer-token-env-var NOCOBASE_API_TOKEN検証環境の2.2.37に接続すると、サーバー名nocobase-mcp-server（版2.2.37）として応答し、ツールはresource_list、resource_get、resource_create、resource_update、resource_destroy、resource_queryの6つでした。resource_listでtodosを指定すると、REST APIと同じ形のデータが返ります。キーを付けない接続は401で拒否されました。
エージェントができる操作の範囲は、渡したキーのロールそのものです。前章の連携用ロールの考え方をそのまま当て、読み取りだけで足りる用途には作成・削除を許さないロールのキーを渡します。ワークフローやユーザー管理などのAPIまで公開したいときは、リクエストヘッダーx-mcp-packagesで対象のパッケージを指定します。MCPクライアント側の権限の切り方は、Slack MCPサーバーの接続手順と権限設計の事例も参考になります。
NocoBase CLI（nb）による既存アプリへの接続とAPI呼び出し
CLIはnpmの@nocobase/cliで、コマンド名はnbです。11月2日時点のnpmのlatestは2.2.37で、本体と版がそろっています（AI連携のクイックスタートは@alphaを案内しています）。CLIのドキュメントどおり、nb initで新規インストール、既存アプリの管理、リモートのアプリへの接続のいずれかを選びます。既存のNocoBaseにAPIキーで接続する例です。
# 本体と同じ版に固定してインストール
npm install -g @nocobase/[email protected]
# 既存のNocoBaseにAPIキーで接続（環境名 local）
nb init -y -e local --setup-mode connect-remote \
-u http://localhost:13000/api -a token -t <APIキー> --skip-skills
# todos コレクションの一覧をJSONで取得
nb api resource list --resource todos -e local -j検証環境ではこの手順で接続でき、REST APIと同じ一覧が返りました。nbにはapiのほか、app（起動・停止・ログ・アップグレード）、backup、plugin、license、skillsなどのコマンド群があります。注意点は、接続情報が~/.nocobase/config.jsonにAPIキーごと平文で保存され、検証したmacOSでは他のユーザーも読める権限（644）で作られたことです。共用のサーバーでは設定ファイルを所有者だけが読める権限にし、親ディレクトリのアクセス権も確認します。APIキーの権限と有効期限も必要最小限にしてください。
Skillsはドラフト段階：2系のnb initと3系のskills-v3の違い
公式のnocobase/skillsは、データモデリング、画面構築、ワークフロー、権限、プラグイン開発などの手順をエージェントに教えるSkillsの集まりです。READMEの冒頭に「まだドラフトで、内容はいつでも変わりうる」と書かれています。2系ではnb initの実行時に自動で入り、不要なら--skip-skillsで外せます。
GitHubのREADMEにあるnpx skills@latest add nocobase/skills-v3は、NocoBase 3のアプリを作るための別物です。2.2系の本番に対して3系向けのSkillsを使わないよう、入れる前にどちらの系統かを確かめてください。Skillsという仕組み自体はAnthropicの公式スキルの中身と導入手順で解説しています。
プラグイン開発とアップグレード運用で詰まりやすい箇所
ノーコードの設定で届かない処理はプラグインで足します。同時に、パッチの間隔が短い製品なので版の上げ方を最初に決めておきます。
yarn pm createで作るプラグインの雛形とtar形式での配布
公式のプラグイン開発ガイドは、create-nocobase-appかGitソースでインストールした開発用の環境を前提にしています。Dockerで動かしている本番とは別に、開発用の環境を用意するのが最初の作業です。
# 雛形の生成（packages/plugins/@my-project/plugin-hello に作られる）
yarn pm create @my-project/plugin-hello
# ターミナル1：開発サーバーを起動して実行したままにする
yarn dev
# ターミナル2：同じプロジェクトディレクトリで有効化する
yarn pm enable @my-project/plugin-hello
# 配布用にビルド（.tgz を出力）
yarn build @my-project/plugin-hello --tar
# 対象アプリのホスト上で、Composeファイルのあるディレクトリから実行
nb plugin import /your/path/plugin-hello-0.1.0.tgz --storage-path ./storage
# 取り込み後に対象アプリを再起動し、プラグイン管理で有効化する雛形はサーバー側と、v1・v2の2種類のクライアント入口を持ちます。2系の新しい画面部品は@nocobase/client-v2のBlockModelを継承して作る形で、ガイドもこちらで書かれています。画面の見た目を細かく作り込む要件が多いなら、プラグインで無理に寄せるより、Retoolや内製の管理画面と比べるほうが早く結論が出ます。
ダウングレード不可の前提で組むバックアップと版の固定
Docker版のアップグレード手順は、docker-compose.ymlの版番号を書き換え、docker compose pull appとdocker compose up -d appで入れ替える方式です。同じページに「アップグレードのみ対応し、ダウングレードは不可」と書かれ、切り戻しは更新前のバックアップを復元して元のイメージに戻す手順だけが案内されています。
# 1. 更新前にデータベースを退避（PostgreSQL の例）
docker compose exec -T postgres pg_dump -U nocobase nocobase > backup_2.2.37.sql
# 2. docker-compose.yml の image を次の版へ書き換えてから入れ替え
docker compose pull app
docker compose up -d app
docker compose logs -f app検証環境の初期状態に近いデータベースでも、ダンプは約280KBありました。ダンプを取るだけで満足せず、検証環境で実際に復元して起動できるかまで確かめておきます。CLIで管理している環境ならnb backup createとnb backup restoreも使えます。サードパーティのプラグインは本体の更新に追随していないと起動を妨げることがあるため、プラグインを増やすほど更新のたびの確認項目も増えます。
NocoBaseのライセンス条件・価格と受託開発での利用範囲
NocoBase 2系はソースコードを公開していますが、Apache License 2.0に独自の利用制限を加えています。無料利用の可否と、顧客への販売・プラットフォーム提供の可否を分けて確認します。
Apache 2.0に上乗せされた追加条項で禁じられていること
v2.2.37のLICENSE.txt（2026年2月24日更新）は、Apache License 2.0を土台に独自の条項を加えています。v1.9.0のLICENSE.txtはAGPL-3.0が土台で、5.3項がマーケットプレイス外の改変やプラグイン、本体を基に開発したアプリをAGPL-3.0で公開するよう求めていました。2系の条項にこの公開義務はありませんが、5章で次の制限が残っています。
- 5.1：商用目的で利用できる
- 5.2：画面上のNocoBaseのブランド、名称、リンク、版番号、ライセンス表示を削除・変更してはならない（左上のメインロゴは例外）
- 5.3：コード内のNocoBaseの知的財産表示を削除・変更してはならない
- 5.4：原版・改変版を使ったノーコード、ゼロコード、ローコード、AIプラットフォームのSaaS・PaaSを公衆に提供してはならない
左上のロゴを自社のものに差し替えるだけならCommunity版でも条項の範囲内で、それ以外の画面上の表記を変えるには商用ライセンス（6.4）が要ります。NocoBaseの上に作ったものを誰でも使えるノーコード基盤として売る構想は、商用ライセンスでも禁止（7.3・7.4）です。
Community・Standard・Professionalの価格と、顧客向け案件でProfessionalが要る理由
公式の価格ページに掲載された2026年11月時点のエディションを整理します。
| エディション | 価格 | 主な追加機能 |
|---|---|---|
| Community | 無料 | ユーザー数・アプリ数・データ量は無制限 |
| Standard | 800ドル（一度払い） | ブランド差し替え・外部DB接続・Excel大量入出力 |
| Professional | 8,000ドル（一度払い） | 顧客向けアプリ・SSO・承認・編集履歴・環境分離 |
| Enterprise | 要問い合わせ | クラスタ構成・監査ログ・Oracle等の接続 |
商用の3エディションはいずれも永久ライセンスで、アップグレードの有効期間は1年です。受託開発で効いてくるのは、条文の6.5項です。顧客に販売する業務アプリ（条文の用語では「Upper Layer Application」）の販売権が明記されているのはProfessionalとEnterpriseの保有者で、7.5項は、Standardの保有者が商用ライセンスを持たない顧客へ上位アプリを販売することを禁じています。
Community版の5章には上位アプリの販売を直接禁じる条項はありません。ただし価格ページは「NocoBaseを使って顧客向けアプリケーションを開発したい」をProfessionalの選択理由に挙げています。顧客へ納品する案件は、Professionalの8,000ドルを最初から見積もりに載せるか、契約前にNocoBaseへ書面で確認するのが安全です。承認フローやSSOを要件に含む案件も同じくProfessionalが前提になります。また、Professional・Enterpriseで販売する場合も、顧客に追加開発・設定の権限を渡すなら、7.6項により顧客側にも商用ライセンスが必要です。
NocoBaseを採用してよい案件と、スクラッチやSaaSで作るべき場面
NocoBaseの採否は、データ構造の確定度、画面要件、運用体制、顧客への提供形態で判断します。
NocoBaseの採用条件：社内利用と確定したデータ構造
採用を勧めるのは、利用者が社内に閉じていて、扱うデータの構造が業務として決まっている案件です。案件管理、備品管理、問い合わせ台帳、契約の更新管理のように、画面が一覧・詳細・入力フォーム中心で、コレクション間の関連とロールごとの操作範囲を事前に整理できるものが該当します。データを社外のSaaSに置けない組織にも合います。
AIエージェントに画面やワークフローを組ませたいチームにも、2系のMCPサーバーとCLIは実用になります。権限の仕組みが基盤側にあるため、エージェントに渡すキーのロールを絞れば、操作できる範囲をNocoBaseの側で止められます。ノーコード製品の選び分けはノーコードツールの用途別比較で横並びに確認できます。
顧客に配る製品や大量トランザクション系で見送る条件
見送るべき場面は3つです。第一に、不特定の顧客へノーコード・ローコード・AIプラットフォームそのものをSaaS・PaaSとして提供する場合です。これは5.4項と7.4項の禁止対象であり、特定業務向けアプリの提供とは区別します。第二に、1日に数十万件の注文や決済を処理するような、性能と整合性の設計が中心になるシステム。第三に、データ構造がまだ決まらず、業務の流れを作りながら探る段階の案件です。構造が決まらないまま画面を量産すると、コレクションを作り直すたびに全画面を直すことになります。
NocoBase 3を今から本番に使うのも見送りです。3系は全パッケージがベータで、動作要件もNode.js 24以上とpnpm 11に変わっています。公式は、2系のアプリを3系へそのままアップグレードすることはできず、3系での再構築と業務データの取り込みが必要と説明しています。具体的な移行方法・ツールと2系の保守計画は未確定のため、既存アプリは2.2系で運用しながら案内を確認します。画面は独自に作り込み、データ管理だけを任せたいなら、ヘッドレスCMS系のDirectusのライセンスと始め方のほうが合う場合もあります。ローコード製品の分類全体はローコードツールの用途別比較と選定基準で整理しています。
Dockerでの起動自体は数分で終わります。手間がかかるのはその後で、コレクションの設計、ロールと権限、APIキーやMCPでの既存システムとの連携、版の更新とバックアップの運用が続きます。データ設計から任せたい、既存の基幹システムとつなぐ部分だけプラグインで作りたい、といった場合は、一創のノーコード・ローコードアプリ開発で、製品の選定から設計、運用手順の引き継ぎまでを一緒に進められます。
よくある質問
NocoBaseの導入検討でよく挙がる質問に、2.2系の仕様を前提に答えます。
NocoBaseは無料で商用利用できますか？
できます。Community版は無料で、ライセンスの5.1項で商用目的の利用が認められています。ユーザー数やアプリ数、データ量の上限もありません。ただし、左上のロゴ以外の画面上のNocoBase表記を消すことと、公衆向けのノーコード・ローコードSaaSとして提供することは禁止です。顧客へ業務アプリを販売する権利が明記されているのはProfessional以上です。
NocoBaseは日本語で使えますか？
使えます。起動直後は英語だけが有効なので、システム設定の「Enabled languages」に日本語を加え、既定の言語を日本語にします。自分で作ったコレクション名や項目名は、ローカライゼーション管理で訳を入れます。2系の日本語ドキュメントはnocode.docs.nocobase.com/ja/にあります。
NocoBaseの初期ログインのIDとパスワードは何ですか？
初期アカウントは[email protected]、パスワードはadmin123です。公開された初期値なので、起動したらすぐに変更してください。あわせて、初期状態で開いている新規登録を閉じておきます。
NocoBase 3に今から乗り換えるべきですか？
本番は2.2系のままにしてください。公式ドキュメントは3系の全パッケージがベータでAPIが変わりうると明記しています。2系のアプリは3系へそのままアップグレードできず、3系で作り直して業務データを取り込む方式で、移行ツールは未公開です。3系を試すなら、本番とは別の検証環境でSQLiteを使って動かす程度にとどめます。
NocoBaseのアップグレードで失敗したら元の版に戻せますか？
公式は「ダウングレードは不可」と明記しています。切り戻しの基本は、更新前のデータベースを復元して元の版のイメージへ戻すことです。環境を作り直す場合は、添付ファイルなどの永続ストレージ、追加プラグイン、APP_KEYを含む設定も復元できるよう保全します。更新前のバックアップと、そこから復元できることの確認を毎回の手順に組み込み、本番のイメージはlatestではなく版番号で固定します。
