エディションとサーフェスプロファイル

Nodaro には、Community、Business、Cloud の 3 つのエディションがあります。どれも同じコードからビルドされ、EDITION 変数で選択します。Business エディションでは、さらにサーフェスプロファイルを使って、環境に表示する内容を再ビルドなしで絞り込めます。インターフェイスの一部を隠す、ノードやモデルを取り除く、製品名を変える、ログインを制限する、といったことができます。このページでは、その両方を説明します。

3 つのエディション

• Community（EDITION=community、デフォルト）は、無料のセルフホスティング型エディションです。アカウントを登録した人は全員、一般ユーザーになります。
• Business（EDITION=business）は、管理パネルとユーザー管理を追加します。セルフホスティングで運用し、請求がない点は Community と同じです。
• Cloud（EDITION=cloud）は、クレジットと請求を追加します。app.nodaro.ai で使われているエディションで、セルフホスティング向けではありません。

Business エディションの管理パネルとユーザー管理は、Enterprise 機能です。開発とテストの目的では実行できますが、本番環境で使うには、Nodaro Enterprise のサブスクリプションが必要です。ライセンスを参照してください。

セルフホスティング環境を Business に切り替える

API は、起動時に EDITION を読み込みます。ブラウザーで動くエディターは、イメージのビルド時に VITE_EDITION からエディションを読み込みます。公開されているイメージは Community エディションとしてビルドされているため、Business エディションの環境はソースからビルドします。

Community から Business に移行しても、データベースへの影響はありません。スキーマが同じだからです。

  nodaro:
    build:
      args:
        VITE_EDITION: business      # was: community
    environment:
      EDITION: business             # was: community

docker compose -f docker-compose.community.yml build --no-cache nodaro
docker compose -f docker-compose.community.yml up -d

ソースからビルドした環境は、git pull と build でアップデートします。docker compose pull を使うと、公開されている Community エディションのイメージがもう一度ダウンロードされてしまいます。

ビルドは、空または不明な VITE_EDITION を拒否します。このチェックがないと、値が未設定でもエラーなくビルドされて community にフォールバックし、管理パネルのない Business エディションのイメージができてしまいます。Compose ファイルは、この値を自動で渡します。docker build を手動で実行する場合は、--build-arg VITE_EDITION=community、business、cloud のいずれかが必要です。

ビルド時に固定される設定とされない設定

ブラウザー向けの 3 つの設定は、ビルド時に固定されません。API のアドレス、ブラウザーが使うログインのアドレス、anon キーです。コンテナは起動時に、PUBLIC_URL、FRONTEND_SUPABASE_URL、SUPABASE_ANON_KEY からこれらの値を /config.js に書き込み、ブラウザーはアプリの起動前にこのファイルを読み込みます。そのため、公開されているイメージのままでも、再起動すればどのポートやドメインでも提供できます。VITE_* のビルド引数は、実行時の値が未設定の場合のフォールバックにすぎません。

そのほかの、ビルド時に固定されるブラウザー向けの設定は次のとおりです。

サーフェスプロファイル

NODARO_SURFACE_PROFILE は、Business または Cloud の環境のインターフェイスを、再ビルドなしで絞り込みます。Community エディションはこの変数を無視し、常にインターフェイスのすべてを表示します。

• 形式：インラインの JSON か、ファイルを読み込む場合は @/path/to/profile.json の形で指定します。Compose スタックでファイルを使うには、ファイルをコンテナにマウントし、コンテナ内のパスを指定します。
• 絞り込みのみ：プロファイルでできるのは、隠すことと取り除くことです。エディションが無効にしているものを有効にすることはありません。
• フィールドはすべて任意：空のリストは「デフォルトのまま」を意味します。プロファイルを設定しない場合、環境はインターフェイスのすべてを表示します。
• エラー：形式が正しくないフィールドは、ログに警告を出したうえで、そのフィールドのデフォルト値に戻ります。プロファイル自体をまったく読み込めない場合、Business または Cloud の環境は [surface-profile] FATAL … Refusing to boot a narrowing deployment mainline-open を出力して起動を停止します。これは、ファイルを読み取れない、JSON が不正、値全体が検証に失敗する、といった場合に起こります。絞り込みを行う環境が、すべてを表示した状態で起動することがあってはならないためです。
• 反映：アプリを再起動します。プロファイルは、/config.js を通じてブラウザーに届きます。

例

NODARO_SURFACE_PROFILE={"nav":{"hide":["gallery"]},"brand":{"productName":"Studio"},"outputs":{"allowPublic":false},"voice":{"allowedGenders":["male"]}}

この例では、ギャラリーを隠し、製品名を Studio に変え、すべての出力を非公開にし、男性のボイスだけを提供します。

フィールド

ロゴとファビコンは、プロファイルには含まれません。Docker イメージに静的ファイルのレイヤーを追加して置き換えます。

ホーム画面のセクション

dashboard.tabs は、順序付きのホワイトリストです。使えるキーは、workflows、projects、apps、miniapps、templates、tutorials、statistics、gallery、studio、mcp です。

• workflows、projects、studio：続きからタブのワークスペースフィルターにある一覧で、リストに書いた順に表示されます。3 つのどれもリストにない場合は 3 つとも表示されるため、メインの一覧が空になることはありません。
• apps：続きからにある Nodaro アプリの帯です。
• templates：探索にある「テンプレートから始める」の列と、サイドバーの「テンプレート」の項目です。
• tutorials：探索にあるスキルアップのチュートリアルと、サイドバーの「チュートリアル」の項目です。templates と tutorials の両方がない場合、「探索」タブは表示されません。
• miniapps：サイドバーの「ミニアプリ」の項目です。
• statistics：「実行履歴」ページにある統計の概要です。
• mcp：「作業を再開」の 4 つ目の一覧です。MCP クライアントが、自動で作成される mcp プロジェクトに作ったワークフローが表示されます。

残したいセクションを、すべてリストに書きます。たとえば ["workflows","projects","statistics","tutorials"] では、ワークフローとプロジェクトの一覧、チュートリアル、統計が残ります。Studio の一覧、アプリの帯、テンプレートの列、サイドバーの「テンプレート」と「ミニアプリ」の項目は表示されなくなります。nav.hide は、これに加えて適用されます。

許可リスト

内容を厳選した環境には、許可リストのほうが安全です。新しいノードやモデルが、拒否していないという理由で表示されてしまうことがなく、リストに追加するまで使えない状態のままになるためです。

• sticky-note や preview などのユーティリティノードは、許可リストに書かれていなくても取り除かれません。取り除くには、deny で明示的に指定する必要があります。
• 管理者は、管理パネルで、ノードとモデルを使えるかどうかを実行中に変更できます。保存した実行時の設定は、初期状態にリセットされるまで、プロファイルのリストに代わって使われます。
• 管理者が管理パネルで無効にしたノードは、管理者なら引き続き使えます。プロファイルで取り除いたノードは、管理者にとっても取り除かれます。ただし、プロファイルで取り除いたノードを管理者が管理パネルで再び有効にすると、そのノードは全員に公開されます。管理者のロールは、それを任せられる信頼できる人にだけ付与してください。
• 無効にしたモデルは、管理者にとっても無効です。
• 実行は、その実行を行うユーザーとしてチェックされます。アプリやプレゼンでの実行は、それを実行した人として行われます。スケジュールや Webhook によってトリガーされた実行はワークフローのオーナーとして行われ、API トークンや接続済みのアプリは、それぞれのオーナーとして動作します。オーナーが管理者の場合、その実行ではユーザーに隠されたノードを使えます。そのようなワークフローの Webhook の URL は、慎重に扱ってください。
• 隠されたノードを含むアプリ、コンポーネント、テンプレートは公開できません。リクエストは node_not_available で失敗します。
• ロールの変更がこれらのチェックに反映されるまで、約 5 分かかります。

ログイン方法

auth.methods は、ログインページに表示するログイン方法を、email、google、sso の中から絞り込みます。sso をリストに入れるのは、SSO ボタンのテキストである auth.ssoLabel を設定する場合だけにしてください。

リストに sso だけを指定すると、サーバー側のルールも有効になります。ログインするすべてのアカウントは、シングルサインオンを通じて作成またはリンクされたものでなければなりません。それ以外のセッションは最初の API 呼び出しで 403 sso_required で拒否されるため、認証サービスに直接登録したアカウントでは環境を使えません。リストに email を加えると、このルールは無効になります。シングルサインオンを参照してください。

ボイスの性別

voice.allowedGenders は、サーバー側で適用されます。

• ボイスの一覧と共有ボイスライブラリには、許可した性別のボイスだけが表示されます。
• ほかの性別の組み込みボイスを指定したリクエストは、voice_not_available で拒否されます。
• デフォルトとフォールバックのボイスは、すべて、許可した性別の最初のボイスになります。
• エディターは、Suno のノードで、ほかの性別のボーカルの性別タグを隠します。

ボイスを作成するノードでは、出力されるボイスの性別を事前に知ることができません。これらのノードを取り除くには、"nodes":{"deny":["voice-design","voice-remix"]} を追加します。

ピッカーのカタログ

レビュー済みのピッカーの内容だけを提供する必要がある環境では、"catalogs":{"required":true,"factoryPresets":false} を設定します。

• required: true の場合、エディターは、サーバーから厳選されたカタログ全体を受け取ってから、ピッカーの選択肢を提供します。そのリクエストが失敗した場合は、選択肢を 1 つも提供しません。新しいノードと初期状態へのリセットでは、提供された値だけを使います。
• factoryPresets: false の場合、同梱のプリセットはエディターと API で非表示になります。ユーザー自身のプリセットは残ります。
• サーバーは、インポートしたワークフローや以前に保存したワークフローに含まれる、除外されたカタログの選択肢も拒否します。