背景

mcp-nixosは、 nixpkgsのパッケージ情報やNixOSのオプション、Home Managerのオプションなどの、 Nixに関する情報をMCP(Model Context Protocol)経由で提供するサーバです。 AIアシスタントがNixOS関連のパッケージ名や設定を、不正確になりやすいWebFetch経由ではなく容易に検索できるようになります。

PC上のClaude DesktopやClaude Codeからnixでプロセスを立ち上げて使っていたのですが、 AndroidのClaude(claude.ai)からも使いたくなりました。 claude.aiのRemote MCP機能を使えば、 HTTPエンドポイントを持つMCPサーバに接続できます。

なぜパブリックにしたのか

最初はTailscaleなどの認証付きネットワーク経由で公開しようと考えていました。流石に知らない人からのリクエストを自分が実装したわけではないプログラムで処理するのは怖いので。

なので一回TailscaleのTailnetから接続できるように、 sparfenyuk/mcp-proxy: A bridge between Streamable HTTP and stdio MCP transports などを使って構築してみました。

しかしclaude.aiのRemote MCPは自分のマシンではなくAnthropicのサーバからリクエストが飛んでくるので、 Android端末がTailscaleに接続していても、 Tailscaleのデバイス認証は使えませんでした。

OAuthを使う方法もありますが、使うのが自分一人だとしてもOAuthの実装はかなり面倒くさいことが分かりました。そもそもmcp-nixosは読み取り専用のMCPサーバなので、認証をつける必然性はないはずです。面倒くささに見合わないのでやめました。

なのでパブリックに公開することにしました。

どうせパブリックにするなら、 NixOSコミュニティへの貢献にもなります。自分以外の人もclaude.aiなどからmcp-nixosを使えるようになるので。

リスクについては、仮想マシンで隔離すれば万が一脆弱性を突かれても被害を最小限に抑えられると判断しました。現状でもCloudflare TunnelやTailscaleで自宅サーバのサービスをインターネットに公開しているので、程度問題ですがリスクはどうせ常に抱えているものと割り切ります。

なぜmicrovm.nixか

microvm.nixは、 NixOS Flakeを使って軽量なNixOS仮想マシンを構築・実行するプロジェクトです。 QEMU、 cloud-hypervisor、 Firecracker(AWS Lambdaの基盤として使われています) など複数のハイパーバイザーに対応しています。

以前、 NixOS containersでForgejoとAtticdをコンテナ化した - ncaq に書いたように、その時はNixOS Containersでサービスを分離していました。 NixOS Containersはsystemd-nspawnベースのコンテナで、コンテナのご多分に漏れずカーネルをホストと共有します。

今回はあまり知らないコードが不特定のリクエストを処理するので、仮想マシンの方が安心です。例えばforgejoはログインしないとトップページにアクセスできるだけの設定にしているので、 Codebergとかもログイン周りは検証するでしょうし、変なことができる可能性は少ないでしょう。今回のmcp-nixosはいきなり本物のリクエストを送信できるので、どう動くかイマイチわからない怖さがあります。

コンテナだと共有カーネルの攻撃対象領域が広いですが、仮想マシンならカーネルが分離されるうえに、ハードウェアも仮想化されるため攻撃対象領域がハイパーバイザーとそのデバイスドライバーに限定されます。

microvm.nixを選んだ理由は、 NixOS Containersと同じように宣言的に書けるからです。実際使ってみたところ、コンテナとほぼ同じ感覚で設定を書けました。

mcp-nixosのHTTPモード起動方法の調査

mcp-nixosはFastMCPフレームワークを使用しています。 FastMCP 2.xは複数のトランスポートモードをサポートしているため、コード変更なしでHTTPモードで起動できます。

コマンドのイメージは以下のような感じです。

fastmcp run mcp_nixos.server:mcp --transport streamable-http --host 0.0.0.0 --port 8080

streamable-httpが現在推奨されているトランスポートです。 SSEもサポートされていますが後方互換性のためのもので、新規では使わない方が良いでしょう。

実装

feat: mcp-nixosのHTTPエンドポイントを建てる by ncaq · Pull Request #582 · ncaq/dotfiles で実装しました。

options.machineAddresses = lib.mkOption {
  type = lib.types.attrsOf addressType;
  default = {
    forgejo = {
      host = "192.168.100.10";
      guest = "192.168.100.11";
    };
    atticd = {
      host = "192.168.100.20";
      guest = "192.168.100.21";
    };
    mcp-nixos = {
      host = "192.168.100.30";
      guest = "192.168.100.31";
    };
  };
  description = "Machine (container/microVM) network addresses";
};

networking.nat = {
  enable = true;
  internalInterfaces = [
    "ve-+" # container veth interfaces
    "vm-+" # microVM TAP interfaces
  ];
};

options.microvmCid = lib.mkOption {
  type = lib.types.attrsOf (lib.types.ints.between 3 4294967294);
  default = {
    mcp-nixos = 3;
  };
  description = "vsock CID assignments for microVMs (must be >= 3, unique per VM)";
};

{ pkgs, config, ... }:
let
  addr = config.machineAddresses.mcp-nixos;
  # Pythonの依存関係とパッケージ自体をまとめて環境にします。
  # mcp-nixosコマンドを直接実行するわけではないので依存パッケージの別途指定が必要です。
  mcp-nixos-env = pkgs.python3.withPackages (
    _: pkgs.mcp-nixos.propagatedBuildInputs ++ [ pkgs.mcp-nixos ]
  );
  # HTTPで提供するためにmcp-nixosをコマンドラインで動かすのではなくPythonモジュールを呼び出します。
  serverPy = "${pkgs.mcp-nixos}/${pkgs.python3.sitePackages}/mcp_nixos/server.py";
in
{
  microvm.vms.mcp-nixos = {
    inherit pkgs;
    config = {
      microvm = {
        hypervisor = "cloud-hypervisor";
        vcpu = 1;
        mem = 768;
        vsock.cid = config.microvmCid.mcp-nixos;
        interfaces = [
          {
            type = "tap";
            id = "vm-mcp-nixos";
            mac = "02:00:00:00:00:30";
          }
        ];
        shares = [
          {
            tag = "ro-store";
            source = "/nix/store";
            mountPoint = "/nix/.ro-store";
            proto = "virtiofs";
          }
        ];
      };
      # ...
    };
  };
}

mcp-nixos-env = pkgs.python3.withPackages (
  _: pkgs.mcp-nixos.propagatedBuildInputs ++ [ pkgs.mcp-nixos ]
);

systemd.services.mcp-nixos-http = {
  description = "mcp-nixos HTTP server";
  after = [ "network.target" ];
  wantedBy = [ "multi-user.target" ];
  serviceConfig = {
    ExecStart = "${mcp-nixos-env}/bin/fastmcp run ${serverPy}:mcp --transport streamable-http --host 0.0.0.0 --port 8080";
    DynamicUser = true;
    Restart = "always";
    RestartSec = 5;
    NoNewPrivileges = true;
    ProtectSystem = "strict";
    ProtectHome = true;
    PrivateTmp = true;
    PrivateDevices = true;
  };
};

systemd.services.mcp-nixos-traffic-control = {
  description = "Traffic control for mcp-nixos microVM";
  requires = [ "microvm-tap-interfaces@mcp-nixos.service" ];
  after = [ "microvm-tap-interfaces@mcp-nixos.service" ];
  bindsTo = [ "microvm-tap-interfaces@mcp-nixos.service" ];
  wantedBy = [ "microvm-tap-interfaces@mcp-nixos.service" ];
  serviceConfig = {
    Type = "oneshot";
    RemainAfterExit = true;
    ExecStart = "${pkgs.iproute2}/bin/tc qdisc replace dev vm-mcp-nixos root tbf rate 100mbit burst 10mbit latency 400ms";
  };
};

"mcp-nixos.ncaq.net" = "http://${config.machineAddresses.mcp-nixos.guest}:8080";

後から修正した部分

systemd.network = {
  enable = true;
  networks."20-vm-mcp-nixos" = {
    matchConfig.Name = "vm-mcp-nixos";
    addresses = [
      { Address = "${addr.host}/24"; }
    ];
  };
};

感想

microvm.nixを使ってみて、 NixOS Containersに比べても別に全然面倒くさくなく宣言的に書けると感じました。 microvm.vms.<name>.configの中にNixOSの設定を書くだけで、コンテナのcontainers.<name>.configと同じ感覚です。

設定する側が意識する違いとしては固定メモリ割り当てが必要なことぐらいです。

パフォーマンスがそこまで気にならない用途であれば、セキュリティを重視したいときに気軽に使えそうです。

今回のようにインターネットに直接公開するサービスは仮想マシンで隔離して、内部向けのサービスはコンテナで軽く動かすという使い分けが良いのかなと思います。

逆にDocker/Podmanの立場が自分の中では微妙になってきた気がします。軽い分離ならNixOS Containersで十分ですし、ちゃんと分離するなら仮想マシンを建てる方が安心です。まあDockerイメージはソフトウェア開発者が公式に配布していることが結構あるので、それを使ってサクッと動かすときはDockerもまだまだ便利だと思います。

自宅サーバの話であって、プロジェクト検証環境とかではDocker Composeもまだまだ使いますしね。

まとめ

mcp-nixosのHTTPエンドポイントをmicrovm.nixで建ててパブリックに公開しました。

• AndroidのClaude(claude.ai)からNixOS情報にアクセスするのが目的
• 読み取り専用MCPに認証は不要と判断してパブリック公開
• microvm.nixでcloud-hypervisorベースの仮想マシンに隔離
• 帯域制限やsystemdハードニングで踏み台対策
• Cloudflare Tunnel経由でhttps://mcp-nixos.ncaq.net/mcp/として公開
• 既存のコンテナ管理と統一するためmachine-mapping.nixに一元化

主なソースコードはncaq/dotfilesにあります。