Dockerデプロイ

公式のnowledgelabs/memイメージは、デスクトップアプリと同じバックエンドを実行し、/appでWebアプリを提供し、すべてのデータをホスト上の3つのプレーンなバインドマウントディレクトリ（./data、./config、./cache）に保持します。 バックアップは、すでにお使いの方法（rsync、restic、tar、ZFSスナップショットなど）で行えます。

これはプレビュー版です。 実際のホストで出荷され、エンドツーエンドで検証されていますが、オペレーター向けのインターフェースは整備が進むにつれて進化し続けます。

この方法はあなたに適していますか？

以下の すべて に当てはまる場合はDockerを選んでください：

• 管理する長時間稼働のホスト（VPS、家庭用NASマシン、クラウドVM、ホームラボサーバーなど）があり、Memをそこにサービスとして常駐させたい。
• そのホスト上でDockerを使って他の長時間稼働サービスをすでに管理している、またはシェルでいくつかのコマンドを実行してcompose.yamlを編集できる程度の慣れがある。
• ラップトップ / スマートフォン / 他のマシン上のWebアプリとnmem CLIがネットワーク経由で接続できる、集中管理された1つのMemサーバーが欲しい。

どれにも当てはまらない場合は、代わりに デスクトップアプリ をインストールしてください。 これがほぼすべてのユーザーにとって通常の方法であり、データは完全にあなたのマシン上に保存されます。

サポートされているアーキテクチャ

イメージはマルチアーキテクチャマニフェストとして公開されているため、docker pull nowledgelabs/mem:<version>はサーバーを通常実行する2つのアーキテクチャで正しく解決されます：

アーキテクチャを選ぶ必要はありません。 Dockerがホストに適したものをプルします。 開発用にApple Silicon MacでDocker Desktopを実行している場合はarm64をプルして動作しますが、これは推奨される方法ではありません。 個人のMacではデスクトップアプリの方がシンプルです。

GPUイメージ（オプション）

ホストにNVIDIA GPUがあり、ローカル埋め込みを高速化したい場合は、デフォルトの代わりにオプトインの:<version>-cudaタグを実行してください：

docker run --gpus all ... nowledgelabs/mem:<version>-cuda

Composeスタックでは、memサービスのimage:を:<version>-cudaタグに向け、gpus: all（Compose v2.30以降）または同等のdeploy.resources予約を追加します。

切り替える前に知っておくべきいくつかの点：

• GPUイメージはlinux/amd64のみです。 デフォルトの:<version>タグはマルチアーキテクチャ（amd64 + arm64）かつCPU専用のままなので、GPUアクセラレーションを特に希望しない限り、そのまま使用し続けてください。
• ホストにはNVIDIA Container Toolkitがインストールされている必要があります。 これがないとコンテナは起動しますがCPUにフォールバックするため、何も得られません。
• イメージにはGPUアクセラレーションされた埋め込みランタイムが同梱されており、言語モデルは含まれていません。 GGUFモデルはCPUイメージの場合と同じ方法でご自身で用意する必要があります。

このページの他のすべて（データレイアウト、バックアップ、アップグレード、検証）は両方のタグで同一です。

AMDおよびIntel向けGPUイメージ（Vulkan）

ホストにAMDまたはIntel GPUがある場合は、:<version>-vulkanタグを実行してください。 Vulkanを使用するためNVIDIAでも動作しますが、通常は:<version>-cudaイメージの方が高速です。

AMDまたはIntelの場合は、GPUのレンダーノードを渡します。 追加のツールキットは不要です：

docker run --device /dev/dri -p 14242:14242 ... nowledgelabs/mem:<version>-vulkan

このイメージでNVIDIAを使用する場合は、NVIDIA Container Toolkitをgraphicsケイパビリティとともに使用します：

docker run --gpus all -e NVIDIA_DRIVER_CAPABILITIES=graphics,compute,utility \
  -p 14242:14242 ... nowledgelabs/mem:<version>-vulkan

Composeスタックでは、memサービスのimage:を:<version>-vulkanタグに向け、対応するデバイスパススルー（AMDまたはIntelの場合はdevices: ["/dev/dri:/dev/dri"]）を追加します。

切り替える前に知っておくべきいくつかの点：

• このイメージはlinux/amd64のみです。 デフォルトの:<version>タグはマルチアーキテクチャ（amd64 + arm64）かつCPU専用のままなので、GPUアクセラレーションを特に希望しない限り、そのまま使用し続けてください。
• Vulkanデバイスが見つからない場合でもコンテナは起動しCPUにフォールバックするため、GPUなしでも安全に実行できますが、遅くなります。
• CUDAイメージと同様に、GPUアクセラレーションされたランタイムが同梱されており、言語モデルは含まれていません。 GGUFモデルはCPUイメージの場合と同じ方法でご自身で用意する必要があります。

このページの他のすべて（データレイアウト、バックアップ、アップグレード、検証）は3つのタグすべてで同一です。

クイックスタート

すぐに使えるスタックはコミュニティリポジトリにあります：

git clone https://github.com/nowledge-co/community.git
cd community/docker
./nmemctl up

nmemctlはこのデプロイのライフサイクルコントローラーです。 コンテナを起動し、/livezを待ち、APIキーを表示し、開くべきURLを教えてくれます。 すでにライセンスコードをお持ちの場合：

./nmemctl license activate <BASE64-LICENSE-CODE>

その他のコマンド：./nmemctl status（ヘルス + キー + URL）、./nmemctl logs -f、./nmemctl upgrade <version>、./nmemctl wipe（ファクトリーリセット）、完全なリストは./nmemctl help。

手動で同じことを3行で：

docker compose up -d
docker compose exec -T mem nmem key                                # print API key
docker compose exec -T mem nmem license activate <BASE64-CODE>     # optional

次にhttp://<your-host>:14242/appを開き、求められたらAPIキーを貼り付けます。

https://raw.githubusercontent.com/nowledge-co/community/main/skills/nowledge-mem-docker/SKILL.md

得られるもの

• デスクトップアプリと同じMemバックエンドを実行する1つのコンテナ。 Webアプリは/appで利用可能です。
• 非rootユーザー、読み取り専用のイメージファイルシステム、すべてのデータはcompose.yamlの隣の3つのローカルディレクトリに保存されます。 dockerボリュームのイディオムを学ぶ必要はありません。 rsync、restic、tar、またはZFSスナップショットでバックアップできます。
• ソースから直接ビルドされた小さなイメージ（圧縮時約1.3 GB）。 デスクトップリリースと同じPythonバンドルです。
• マルチアーキテクチャ：1つのタグがamd64とarm64の両方のホストで動作します。

APIキーはどこにありますか？

Memは初回起動時にAPIキーを生成します。 見逃した、紛失した、またはローテーションしたい場合は、以下のいずれかが機能します：

./nmemctl status                              # reprints key, license, URL, health
./nmemctl key                                 # just the current key
./nmemctl key --rotate                        # rotate to a new value
./nmemctl logs | grep -A 1 "API Key"          # peek at the first-run banner

キーはホスト上の./config/co.nowledge.mem.desktop/remote-access.jsonに保存され（コンテナ内の/etc/nowledge-mem/...にマウントされます）、イメージのアップグレード後も保持されます。 ./configをバックアップすればキーもバックアップされます。 ローテーションする場合は、既存のすべてのクライアント（Web UI、MCPクライアント、リモートマシン上のnmem CLI）に新しい値を貼り直す必要があります。

ワンクリックインストール（NASアプリストア）

上記のすべてにはシェルが必要です。 NASアプリストア（Synology、QNAP、Unraidなど）からワンクリックでインストールした場合、シェルがないかもしれません。 その場合は、Composeのenvironmentブロックで NOWLEDGE_NAS_BOOTSTRAP: "1" を設定します（コメントアウトされた状態で同梱されており、デフォルトはオフです）。 次に同じネットワーク上のブラウザからWeb UIを開き、設定 → どこからでもアクセス に移動すると、「セットアップを完了：アクセスキーをコピー」カードでターミナルなしでキーをコピーできます。

これは意図的に限定的です。 オプトインのみで、キーが最初に使用された時点で完全に閉じられ、Access Anywhereトンネル経由で到着したものに対しては表示が拒否されます。 サーバーは訪問者のアドレス（リバースプロキシの転送クライアントヘッダーを含む）をチェックし、パブリックなものを拒否します。 標準的なLinux Dockerホストでは実際のクライアントIPが保持されるため、これは外部からの訪問者を確実に拒否しますが、一部のネットワーク設定ではブリッジゲートウェイが提示され、LANクライアントと外部のものが同じに見えます。 常に確信できるわけではないため、信頼できる家庭内ネットワーク上のマシンでのみ有効にしてください。 ポートがインターネットに直接公開されている場合は、代わりにnmemctlでキーを取得してください。

データの保存場所

compose.yamlの隣に3つのローカルディレクトリがあります。 これらはあなたが所有し、標準的なツールが直接機能します：

ファイルはコンテナ内のUID 10001が所有します。 ./nmemctl upは初回実行時にワンショットのヘルパーコンテナを介してディレクトリの所有権を変更するため、chownやsudoを自分で入力する必要はありません。

./nmemctl upgrade <version>（または手動でdocker compose pull && docker compose up -d）でアップグレードすると、3つのディレクトリはすべてそのまま残ります。 ライセンスはアクティベートされたまま、データと会話はそのまま、キャッシュ内の埋め込みモデルにより検索は何も再ダウンロードする必要がありません。 新規インストールにリセットする唯一の操作は./nmemctl wipeで、これは意図的な「ワイプしてやり直す」フローです。

SELinuxオペレーター（RHEL / Fedora / Rocky）：compose.yamlの各バインドマウントに:Zを追加して、SELinuxがコンテナアクセス用にホストディレクトリのラベルを付け直すようにします。 このラベルは初回適用時に破壊的であるためオプトインです。

どこからでもサーバーにアクセス

cloudflaredはイメージ内に同梱されているため、Docker上のAccess Anywhereはすぐに使えます。 追加するサイドカーも、実行するcloudflared service installもありません。 サーバーがトンネルを起動および管理します。

Web UIの 設定 → どこからでもアクセス から、またはコンテナ内のnmem CLIから設定します：

docker compose exec -T mem nmem config access ...

トンネルが稼働したら、URLとAPIキーをコピーして他のデバイスを接続します。 セットアップ、キーの扱い、クライアント接続の手順はデスクトップアプリと同じなので、完全なウォークスルーは1つのページにあります：リモートアクセス。

docker compose exec -it mem nmem tui

メモリと増大するデータ

デフォルトのmem_limit: 4gはMemの パッシブ な使用（グラフ、Webアプリ、アイドル検索）に合わせてサイズ設定されています。 サーバー上でAI NowやFeed Agentを積極的に使用する場合は、これを増やしてください。 目安として：

ファイルアップロードやエージェントクエリでUIが500エラーでハングしたままになる場合は、安全な復旧方法はdocker compose restart memです。 イメージは次回起動時に内部メモリバジェットを自動的に引き上げるため、同じワークロードはその後収まるはずです。 それでも続く場合は、上記の表に従ってmem_limitを増やしてください。

arm64 SBC（Raspberry Pi 5、Orange Pi 5など）では同じ表が適用されますが、これらのボードは通常、ホストRAMをGPUや他のアクセラレーターと共有していることに注意してください。 OS用の余裕を残してください。

検索が完全に機能していることを確認する

検索は常に機能し続けるため、待つ必要はありません。 GET /healthはどの部分が稼働しているかを正確に教えてくれます：

curl -s http://<your-host>:14242/health | python3 -m json.tool

重要なフィールドは2つあります：

• embedding.mode はセマンティック検索がどのように実行されているかを示します：
  • remote：リモート埋め込みプロバイダー（例：Nowledge AIまたは独自のキー）。 完全なセマンティック検索。
  • local-gguf：同梱のGGUF埋め込みモデル。 完全なセマンティック検索。
  • local-hash-fallback：実際の埋め込み器が設定されていないため、セマンティックランキングが低下しています。 キーワード検索は引き続き機能します。 これは埋め込みプロバイダーまたはモデルを設定するシグナルです。
• reindex_needed は検索インデックスが古い場合にtrueになります。 通常は埋め込みIDが変更された（プロバイダーまたはモデルを切り替えた）ためです。

サーバーはインデックスを再構築するために起動をブロックしません。 すぐに起動し、インデックスが追いつく間はキーワード（FTS）検索を提供するため、古いインデックスはエラーになるのではなく静かにキーワード結果にフォールバックします。 準備ができたら、設定 → メモリ処理 → 検索 から、または手動で再構築をトリガーします：

curl -X POST -H "Authorization: Bearer $NMEM_API_KEY" http://<your-host>:14242/search-index/reindex

イメージが当社から来たことを検証する

各リリースはSigstoreアテステーションとともに公開されます。 プルしようとしているイメージが当社のビルドパイプラインから来たものである（同じタグを持つ別の場所からではない）ことを確認したい場合は、次を実行します：

cosign verify docker.io/nowledgelabs/mem:0.9.4 \
  --certificate-identity-regexp='https://github.com/nowledge-co/mem/.github/workflows/release-docker.yml@.*' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com'

成功した実行はビルドのGitHub Actions IDを示します。 失敗は、プルしたイメージが当社のパイプラインによって生成されたものではないことを意味します。 信頼しないでください。

アテステーションはマニフェストに添付されているため、同じcosign verifyがamd64とarm64の両方で機能します。

実行中のコンテナがどのコミットからビルドされたかを正確に確認するには、ビルドSHAを読み取ります：

docker compose exec -T mem nmem-server --build-info

同じ値はGET /healthの.build_shaの下にあり、ネットワーク経由またはスクリプトからデプロイを検証したい場合に便利です。

パブリックホスト上のTLS

サーバーがインターネットから到達可能で、実際の証明書が必要な場合、同じcommunity/docker/ディレクトリにCaddyサイドカーが同梱されています：

export NOWLEDGE_DOMAIN=mem.example.com
export NOWLEDGE_LE_EMAIL=you@example.com
docker compose -f compose.yaml -f compose.tls.yaml up -d

ホストを指すDNSレコード、Let's Encryptチャレンジ用に開かれたポート80と443、およびDocker Compose v2.24.4以降（オーバーレイは以前のバージョンが黙って無視するYAMLマージタグを使用します）が必要です。 Caddyは証明書を自動的に更新します。

バックアップと移行

2つのレイヤーがあり、移動に合う方を選んでください：

ボリュームレベルのスナップショット（両端で同じイメージバージョン、最速の復元）：

./nmemctl export                    # stop, tar ./data ./config ./cache, restart
./nmemctl export --no-cache         # smaller archive, skip rebuildable cache
./nmemctl import mem-export-<host>-<ts>.tar.gz   # restore on the new host

アプリケーションレベルのダンプ（バージョン間、または.deb / デスクトップインストールからの移行、デスクトップアプリが「ファイルにエクスポート」に使用するのと同じポータブルJSONL形式を使用）：

./nmemctl backup-app                # produces mem-app-export-<host>-<ts>.zip
./nmemctl restore-app mem-app-export-<host>-<ts>.zip

このポータブルエクスポート形式のアプリ側ガイドについては、バックアップ、エクスポート、インポートをお読みください。

どちらのフローも意図的にmachine_idを残します。 移行先は新しいデバイスIDを取得し、初回起動時にライセンスを再アクティベートします（1シートを消費します）。 移行が成功したらソースサーバーを廃止してください。 両方を並行して実行すると状態が分岐します。

rsync、restic、borg、ZFSスナップショット、またはプレーンなtarを./dataと./configに対して直接使用することもできます。 これらは単なるホストディレクトリです。 保証された一貫性のあるスナップショットのために、まずコンテナを停止し（./nmemctl down）、その後./nmemctl upを実行します。

アプリケーションレベルのダンプは、アーキテクチャ間の移行（例：amd64 VPSからarm64 NASへの移動）の方法でもあります。 ボリュームレベルのスナップショットは、一部のオンディスクプロジェクションについてソースアーキテクチャのデータレイアウトに結び付いているため、アーキテクチャ間の移動はbackup-app / restore-appを経由する必要があります。

Web UIからのアップグレード（オプション）

デフォルトでは、セルフホストのMemサーバーのアップグレードは、リリースごとに一度SSHで接続して./nmemctl upgrade <version>を実行することを意味します。 Memを使用しているのと同じWebアプリからアップグレードしたい場合は、自動更新を一度オンにします：

./nmemctl auto-update enable

この方法は公式のcommunity/dockerデプロイ専用です。 NASアプリストアのインストール、NAS Container Managerテンプレート、Portainerスタック、Unraidテンプレート、カスタムComposeファイルは、それらを作成したシステムを通じて更新する必要があります。 Memは新しいバージョンが存在することを表示できますが、未知のデプロイレイアウトを書き換えるべきではありません。

これによりデプロイごとのトークンが生成され、アップグレード作業を処理する小さなコンパニオンコンテナが追加され、ブラウザからインストールをトリガーできるようになります。 この後：

• タイトルバーのバッジ は、デスクトップアプリが更新を通知するのと同じように、新しいMemイメージが公開されると点灯します。
• 設定 → サーバーカード は、現在のバージョン、最新の公開バージョン、ダウンロードボタン（バックグラウンドプル、ダウンタイムなし）、インストールボタン（約30秒のダウンタイム、コンテナが再作成される前にスナップショットが取得されます）を表示します。
• バージョンのスキップが機能します。 0.9.2を使用していて0.9.4が最新の場合、インストールは直接0.9.4に移動します。 前方のみのスキーマ移行は、新しいイメージの初回起動時に順番に実行されます。

オンにする前に：

• コンパニオンコンテナは/var/run/docker.sockをマウントします。 これがオプトインのままである理由です。 そのコンテナはホスト上でroot相当です。 Memコンテナ自体はソケットアクセスを取得しません。
• リモートインストールは意図的なオプトインです。 更新の確認は常にWeb UIから機能しますが、ダウンロードとインストールはNOWLEDGE_ADMIN_REMOTE_OPS=1が設定されるまでループバックのみです。 auto-update enableはそのフラグをあなたのために設定します。 ブラウザからインストールをクリックすることはサーバー側の状態変更だからです。 信頼できるネットワークでのみ有効にしてください。
• すべてのインストールは、コンテナを再作成する前に./dataと./configのスナップショットを./cache/_pre-upgrade-<timestamp>.tar.gzに取得します。 最後の3つのスナップショットがディスク上に残ります。 新しいイメージが起動に失敗した場合、Web UIはスナップショットパスを表示するので、SSHで接続して./nmemctl import <path> --forceを実行し、以前の状態を復元できます。

./nmemctl auto-update status              # current state, last pull, retained snapshots
./nmemctl auto-update rotate              # rotate the updater token
./nmemctl auto-update upgrade             # bump the companion container's image
./nmemctl auto-update disable             # remove the companion container; keep the snapshots

完全なオペレーターノート

完全なオペレーター契約（すべての環境変数、セキュリティ強化の詳細、デバイスIDの不変条件、トラブルシューティングレシピ）については、コミュニティリポジトリのcommunity/docker/README.mdを参照してください。

関連

• インストール：ほとんどのユーザーが求めるデスクトップアプリの方法。
• Linuxサーバーデプロイ：systemdユニットを使用した.debインストール。 コンテナよりもapt管理の更新を好むLinuxサーバー向け。
• バックアップ、エクスポート、インポート：アプリケーションレベルのエクスポート形式と復元フロー。
• リモートアクセス：Access Anywhereキー、APIアクセス、マルチデバイス同期。 Dockerデプロイにも同様に適用されます。
• LLMプロバイダー：バックグラウンドインテリジェンス（デイリーブリーフィング、インサイト、グラフエンリッチメント）に必要です。
• トラブルシューティング：ヘッドレスコンテナの方法を含む、一般的なオペレーターの問題。