本物の Linux マシンを、コマンド一つで。

SSH ネイティブな隔離を備えた、オープンソースの Agent 実行環境。各 Agent は Kubernetes または LXC 上で、永続的かつネットワーク隔離されたマシンを取得します——kube-apiserver トークンは不要、 eBPF による送信トラフィックポリシーとMCP server を標準搭載。セルフホスト可能、Apache 2.0 ライセンス。

AI Agent 向け CI 実行向け PR プレビュー向け

Containarium Cloud を試す v1.0 オープンソース CLI を入手 v0.x

ご自身の VM にセルフホストするか、運用の手間を省いてホスト型コントロールプレーンをご利用ください。

~ / containarium

$ containarium create my-agent-box
✓ container my-agent-box created
✓ sentinel route my-agent-box.example.com live
✓ MCP server listening inside the box

$ containarium ssh-config my-agent-box >> ~/.ssh/config

# Now point any agent at it — Claude Code, Cursor, Cline...
$ claude --mcp my-agent-box.example.com
Connected. Your agent has its own box.

Containarium とは

もう一つの Agent ではなく、プリミティブです。

あらゆる Agent には、実際に活動できる環境が必要です——コードを安全に実行し、ファイルを編集し、ツールを呼び出せる場所。Containarium はまさにその環境そのものです。あなたが Agent を用意し、私たちがマシンを提供します。

隔離されたマシン——LXC または Kubernetes

Agent ごとに 1 台の Linux マシン、LXC または K8s Pod 上で動作。本物の root 権限、本物のファイルシステム、eBPF による送信トラフィックポリシー—— ホスト、クラスターのコントロールプレーン、そして他のすべてのテナントから完全に隔離されています。

ホスト名で公開

内蔵の Sentinel（sshpiper + Caddy + PROXY protocol）により、すべてのマシンが TLS を備えたルーティング可能なホスト名を取得します。SSH と HTTP はそのまま使えます。

MCP server を内蔵

マシン内で MCP server が動作し、stdio 経由で shell とファイル操作を提供します。 MCP に対応した Agent なら何でも操作できます：Claude Code、Cursor、Cline、あるいは独自の Agent。

仕組み

Agent からマシンへ、ワンホップで。

STEP 1

マシンを作成する

containarium create が LXC コンテナを起動し、Sentinel にルートを登録します。
STEP 2

Agent を接続する

マシンは MCP server を公開します。あなたの Agent は SSH または HTTPS 経由——ホスト名で接続します。
STEP 3

動かす

Agent はファイルを編集し、コマンドを実行し、コードを発行します——すべてあなたが管理する隔離された環境の中で。

活用シーン

Agent をノート PC で動かすべきでない、あらゆる場面に。

長時間稼働するコーディング Agent

Claude Code や Cursor に永続的なマシンを与える——セッションをまたいで状態を保持し、どこからでも作業を継続できます。

CI と一時的な環境

PR ごとにマシンを起動し、その中で Agent を実行し、使い終わったら破棄する。もう runner を奪い合う必要はありません。

Agent フリート

タスクごと、ユーザーごと、テナントごとに 1 台のマシン。ルーティングは Sentinel が担当し、あなたは Agent に集中できます。

カスタム MCP ツール

内蔵の MCP server の隣に、独自の MCP server を追加できます。どの Agent からも両方が見え、余計な配線は不要です。

CI 向け

失敗したときに SSH で入れるテストランナー。

GitHub がホストする runner は、テストが失敗した瞬間に消えてしまうブラックボックスです。 Containarium なら、すべての CI ジョブに本物の Linux マシンを与え、実行間でウォームキャッシュを維持し—— 失敗時には 1 時間生かしたままにするので、人間（あるいは Agent）がその場で壊れた状態をデバッグできます。

.github/workflows/test.yml

name: CI
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: footprintai/containarium-run@v1
        with:
          api-url: ${{ secrets.CONTAINARIUM_API_URL }}
          token:   ${{ secrets.CONTAINARIUM_TOKEN }}
          cache-key: ${{ hashFiles('go.sum') }}

.github/containarium.yml

# Three fields. Resist adding a fourth.
image: ubuntu-24.04

setup:                   # cached by cache-key
  - apt-get install -y build-essential
  - go mod download

test:                    # the actual CI command
  - go test ./...

テストが失敗すると、keep-on-failure: true があなたの PR にこのコメントを投稿します：

containarium-bot commented just now

❌ CI failed — box kept alive for debugging

Failing test: TestExposePort_TLSHandshake in internal/server/expose_test.go:142

Debug this box live (expires in 58 minutes · extend 1h · tear down now)

# SSH in
ssh -p 2222 [email protected]

# Or hand it to your agent (Claude Code, Cursor, ...)
claude mcp add containarium-debug \
  https://mcp.containarium.dev/box/pr-1234-abc?token=ey...

🤖 Posted by containarium-run · commit a7b2f93

CI を Containarium に接続する 3 つの方法

GitHub Actions はよく使われるインターフェースの一つです——Containarium はそれを、自律度が段階的に高まる 3 つの層でサポートします。能力（ジョブごとに 1 台の一時的な Linux マシン）はどの層でも同じで、違うのはコードが実際にどこで実行されるかだけです。

層	対象	セットアップ	コードの実行場所
0・お試し約 5 分でセットアップ	検討中のチーム、趣味の OSS プロジェクト	ホスト型クラウドに登録・`containarium-run` Action を使用	コード → GHA ホスト型 → cloud.containarium.dev → Containarium マシン
1・中規模チーム約 30 分でセットアップ	自前のインフラを持つチーム	Containarium OSS 版をセルフホスト・`hacks/runner/` で N 個の一時的な runner を構築	コード → GHA ホスト型（調整のみ担当）→ 自社の runner プール
2・エンタープライズ監査 / SSO	「コードを境界の外に出せない」企業	第 1 層 + 監査ログ + SSO + データ所在地文書	FootprintAI のインフラを一切経由しない
3・エアギャップオフラインバンドル	規制の厳しい業界	第 2 層 + オフラインインストールバンドル + プライベート Git server	お客様の VPC 内に完全に封じ込め