ワークスペース
1 つの SubLane インスタンス内でメンバー、リソース、使用量を分離します。
ワークスペースは、1 セットのメンバーとサブスクリプションの境界です。ワークスペース名は、SubLane ロゴの横に表示されます。 左側のサイドバーの上部。管理しているワークスペースを変更するには、そこで別の名前を選択します。
アカウント、リソースグループ、メンバー アクセス、個人 API キー、利用枠、リクエスト履歴、使用状況、および監査レコードは、選択したワークスペースに属します。ユーザーは 1 つのログインを持ち、異なる役割を持つ複数のワークスペースに所属することができます。
最初のワークスペースを作成する
新規インストールの場合、セットアップには 2 つの手順があります。管理者ログインを作成し、次に 最初のワークスペースに名前を付けます。 2 番目のステップが送信されるまで、何も初期化されません。管理者がそのワークスペースの所有者になり、サインインします。
新しいワークスペースは空から始まります。便利にするには:
- で アカウントに接続し、サブスクリプションを確認します。
- で リソースグループ、プールを作成し、サブスクリプションを追加します。
- で メンバー、人を作成して使用します グループアクセス 各人に使用できるプールを付与します。
- メンバーは以下に独自のキーを作成します API キー。必要に応じて、管理者は追加できます 利用枠 専用プールへ。
フォローすることができます 初回リクエストガイド 初期アカウントとキーについては、 メンバーアクセス 共有する準備ができたら。
ワークスペースの切り替えまたは追加
SubLane ロゴの横にあるスイッチャーを開きます。アクセスできるワークスペースをリストし、現在のワークスペースにマークを付けます。 ワークスペースの作成。切り替えると、選択したワークスペースのプライベート ページ データがリロードされます。別のワークスペースの作成は、アカウント、プール、メンバー、キーの空のセットから始まります。
各ユーザーは、該当する場合は最初のワークスペースを含め、最大 10 個のワークスペースを所有できます。 11 番目の返品の作成 409 workspace_limit_reached.
キーは、それが作成されたワークスペースとプールにバインドされたままになります。ブラウザーのワークスペースを切り替えても、キーが移動したり、そのリクエストが記録される場所は変更されません。別のワークスペースまたはプールの新しいキーを作成します。
2 つのサンプル ワークスペースを含むワークスペース スイッチャーの例:

誰が何をできるのか
| このワークスペースでの役割 | アクセス |
|---|---|
| 所有者または管理者 | このワークスペースのメンバー、アカウント、プール、許可、許可、使用状況、および監査を管理します。 |
| メンバー | 独自のキーを管理し、独自のリクエスト、使用法、および制限を確認します。 |
誰かのメンバーシップを無効にすると、ブラウザへのアクセスとキーがブロックされます このワークスペースで。ログインや他のワークスペースへのアクセスは無効になりません。最初の管理者は、インスタンス全体の Codex バージョン設定とバックアップも管理します。他のワークスペース管理者は、これらのプラットフォーム制御を受け取りません。
インスタンス全体に残るもの
SubLane は、これらのワークスペースを 1 つの Go プロセスと SQLite データベースで実行します。バックアップには、 インスタンス全体、すべてのワークスペースとその暗号化キーを含みます。単一ワークスペースのエクスポートや復元はありません。課金、PostgreSQL ストレージ、および複数のアプリケーション レプリカは現在のリリースの対象外です。
ブラウザー要求には選択されたワークスペース ID が含まれますが、サーバーは保護された各要求のセッションとメンバーシップをチェックします。ゲートウェイ要求は、個人キーの保存されたバインディングからワークスペースを識別します。ブラウザ選択ヘッダーではそれらを移動できません。ゲートウェイは、新しいリクエストでキー、メンバーシップ、プール、モデルへのアクセスを再チェックし、WebSocket になります。
起動時に新規データベースを初期化し、サポート対象の既存データベースには未適用のマイグレーションを順に適用します。001_settings.sql を含む初期の非互換構造は拒否されるため、元のディレクトリを保存して新規ディレクトリを使用してください。更新前にバックアップを作成して検証します。イメージの切り替えだけでは移行済みデータを元に戻せません。