ルームの追加と管理

マシンはサーバー上の設定ドキュメントに記述されます。サーバーの管理者（hostel-users）である必要があります。各変更は即座に適用されます。

hostel config providers        # NAME, KIND, MACHINES
hostel config rooms            # MACHINE, KIND, OS, PLATFORMS, LABELS, ROOMS
hostel config edit             # TOMLを$EDITORで変更

マシン名は <provider>/<machine> 形式、または名前が一意の場合は <machine> のみです。名前は ^[a-z][a-z0-9-]*$ に一致します。プラットフォーム要件（Xcode、Android SDK、KVM、デスクトップ）は hostel-platforms にあります。

NAT背後にあるマシン（サーバーに参加）

これはほとんどの自前マシンに使用します：自宅のMac mini、Windows PC、Linuxボックス。マシンはサーバーへのアウトバウンド接続を維持します。インターネットからのインバウンドSSHは不要です。

自分のコンピューターで、マシンコードを生成します（24時間有効、1回のみ使用可）：
```
hostel config rooms add mac-mini --platform ios --label xcode-26.5 --label desktop
hostel config rooms add win-pc --label desktop
```
--platform と --label は繰り返し指定できます。--provider で静的プロバイダを選択します（デフォルトは home。サーバーが存在しない場合は追加します）。アプリでは：Front desk › Add a room。
新しいマシンで、表示されたコマンドを管理者として実行します：macOSとLinuxでは sudo、Windowsでは管理者PowerShell。このコマンドはサーバーから hostel をダウンロードし、hostel machine join <code> を実行します。

hostel machine join はユーザー hostel（管理者権限なし）を作成し、サーバーの鍵をインストールし、マシンを設定に追加（connect = true、OSはマシンから取得）、hostel machine connect を実行するサービスをインストールします：

OS	サービス	ログ
Linux	systemdユニット `hostel-machine-connect.service`（ユーザー `hostel-connect`）	`journalctl -u hostel-machine-connect`
macOS	LaunchDaemon `so.hostel.machine-connect`	`/var/log/hostel-machine-connect.log`
Windows	スケジュールタスク `Hostel machine connect`（`LOCAL SERVICE`）	`C:\ProgramData\hostel\machine-connect.log`

トークンは /etc/hostel または C:\ProgramData\hostel に保存され、ルームユーザーは読み取れません。ステップが失敗した場合は、修正して同じコマンドを再実行します：続行されます。--no-service はサービスをスキップし、自分で実行する hostel machine connect コマンドを表示します（--server <url> --token-file <file> [--server-key k] [--ssh 127.0.0.1:22]）。

join が表示する、人間にしかできない手順を実行します：
- macOS：システム設定 › 一般 › 共有 › リモートログインをオン（hostel 用）。iOS用のXcode。desktop の場合は、hostel の自動ログインとスクリーンセーバー後のパスワードなし。
- Windows：OpenSSH Serverが実行され、自動的に起動すること（Get-Service sshd）。desktop の場合は「Hostel desktop」タスク。
- Linux：SSHサーバーがポート22で実行され、hostel の鍵ログインを許可していること。
確認：hostel status で1分以内にルームが表示されます。

サーバーがSSH経由で到達する静的マシン

サーバーがマシンへのTCP接続を開ける場合（同じLANまたはVPN）に使用します。マシン上に、サーバーのSSH公開鍵を持つ標準ユーザー hostel を作成します。鍵は hostel admin pubkey（管理者のコンピューター上）の出力、または hostel server init が表示したもの（「サーバー公開鍵」）です。Linuxの場合：

sudo useradd -m -s /bin/bash hostel
sudo install -d -m 700 -o hostel -g hostel ~hostel/.ssh
echo 'ssh-ed25519 AAAA... hostel-server' | sudo tee ~hostel/.ssh/authorized_keys
sudo chown hostel:hostel ~hostel/.ssh/authorized_keys && sudo chmod 600 ~hostel/.ssh/authorized_keys

そのユーザーに対してSSH鍵ログインを許可します。sshd でTCP転送を有効にしたままにします（OpenSSHのデフォルト。トンネルに必要）。その後、hostel config edit で追加します：

[providers.home]
kind = "static"

[providers.home.machines.mac-mini]
address = "[email protected]"    # user@host[:port]; デフォルトユーザー hostel、ポート22
os = "macos"                         # 必須：linux、macos、または windows
platforms = ["ios", "android"]       # デバイスプラットフォーム。OSプラットフォームは自動
labels = ["xcode-26.5", "desktop"]
tools = { java = "21" }              # マシンレベルのmiseツール
env = { HOSTEL_IOS_RUNTIME = "26.5" }
# slots = [{ name = "a" }, { name = "b" }]   # 同時に2つのリース（デフォルト：1スロット "a"）

slots：各スロット n はトンネル用にポート 7500 + 10n ～ 7509 + 10n を取得します。スロットは ports、env、独自のOS user を設定できます。
プロバイダの env と tools はそのすべてのマシンに適用されます。マシンキーは同名のキーを上書きします。
サーバーは最初の接続時にマシンのSSHホスト鍵を固定します。
Windowsの手動設定：docs/static-room-setup.md の「Windows」セクション（ユーザーと、OpenSSHが要求する authorized_keys のアクセスルール）。
パブリックアドレスの場合：サーバーからのインバウンドSSHのみを許可するか、connect = true（参加フロー）を使用してインバウンドSSHを閉じます。

エディターを使わずに1つのキーを変更する（platforms と labels はカンマ区切りリスト）：

hostel config rooms set mac-mini labels=xcode-26.5,desktop
hostel config rooms set mac-mini platforms=ios

Namespace（オンデマンドクラウドマシン）

Namespace（namespace.so）は、リースが必要なときにルームを作成します：macOS（またはLinux）用の devbox、Linux用の instance。両方のCLIをサーバーのユーザーとしてインストールし、~/.local/bin をサービスの PATH に追加します：

curl -fsSL https://get.namespace.so/cloud/install.sh | sh        # nsc
curl -fsSL get.namespace.so/devbox/install.sh | bash             # devbox
sudo mkdir -p /etc/systemd/system/hostel.service.d
printf '[Service]\nEnvironment=PATH=%s/.local/bin:/usr/local/bin:/usr/bin:/bin\n' "$HOME" \
  | sudo tee /etc/systemd/system/hostel.service.d/path.conf
sudo systemctl daemon-reload && sudo systemctl restart hostel

自分のコンピューターから（URLが表示されるので開いてワークスペースを選択）：

hostel config providers login namespace        # --cli devbox または --cli nsc で1つのCLIのみ
hostel config providers add ns --kind namespace

次に、hostel config edit でマシンテンプレートを追加します：

[providers.ns]
kind = "namespace"
max_rooms = 3                        # このプロバイダの全マシン合計
# limits = [{ machines = ["mac"], max_rooms = 1 }]

[providers.ns.machines.mac]
spec = { product = "devbox", platform = "macos", size = "m", image = "tahoe-slim" }
platforms = ["ios"]
labels = ["xcode-26.5", "desktop"]
env = { DEVELOPER_DIR = "/Applications/Xcode_26.5.app/Contents/Developer", HOSTEL_IOS_RUNTIME = "26.5" }
max_rooms = 1
max_lifetime = "3h"                  # devboxに必須：プランの最大期間

[providers.ns.machines.linux]
spec = { product = "instance", machine_type = "linux/amd64:8x16" }   # オプション：image（デフォルト ubuntu:24.04）
platforms = ["android"]
labels = ["kvm"]
tools = { java = "21" }
max_rooms = 2

コストと制限（Namespaceの現在のプランを確認）：

Hostelは、プレフィックス hostel-<server_id>- のルームに対してのみ動作します。
devboxはエフェメラルです：約15分間アイドル状態、および max_lifetime に達すると削除されます。インスタンスには固定の期限があり、サーバーが延長します。
macOS devboxはLinuxよりも1分あたりのコストがはるかに高くなります。
プラン制限はすべてのリースに適用されます（1つのログインを共有）。Developerプラン：ユーザーあたり1 devbox、最大3時間、Windows不可。「制限に達しました」というエラーは、limit_retry（2分）の間マシンを満杯としてマークします。
linux インスタンスタイプのみがサポートされています。Namespace上のAndroidはLinuxを使用します。
ログインは数日間有効です。期限が切れるとプロバイダ呼び出しが失敗します：再ログインしてください。

外部プロバイダ（独自のコマンド）

kind = "external" は、各操作（capabilities、provision、resume、stop、extend、destroy、list、access）に対して、標準入力/標準出力でJSONをやり取りする独自のコマンドを実行します。docs/design.md のセクション7「外部プロバイダ契約」に完全な契約が記載されています。リポジトリの test/fakeprovider（Dockerコンテナ）はテストツールであり、サポート対象のプロバイダではありません。

[providers.docker]
kind = "external"
command = ["/usr/local/bin/my-provider"]
command_env = { DOCKER_HOST = "unix:///var/run/docker.sock" }
timeouts = { provision = "5m", default = "1m" }

[providers.docker.machines.small]
os = "linux"                         # 必須
spec = { image = "debian:13" }       # そのままコマンドに渡されます
max_rooms = 2

制限とウォームルーム（オンデマンドマシン）

キー	場所	デフォルト
`max_rooms`	プロバイダ（全マシン）/ マシン	なし / 1
`limits`	プロバイダ：`[{ machines = [...], max_rooms = N }]`	`[]`
`max_lease`	プロバイダ、マシン	`2h`
`max_lifetime`	プロバイダ、マシン	なし
`warm_running`	プロバイダ、マシン：空きルームをこの期間実行状態で保持	`5m`
`warm_stopped`	プロバイダ、マシン：停止したルームをこの期間保持	`24h`

ドレイン、修復、削除、破棄

hostel config rooms drain mac-mini        # 新規リースなし。現在のリースは継続
hostel config rooms undrain mac-mini
hostel config rooms repair mac-mini       # 壊れたルームを再チェック
hostel config rooms repair mac-mini --accept-host-key
hostel config rooms destroy ns/mac        # リースのないオンデマンドルーム（複数ある場合はルーム名を指定）
hostel config rooms remove mac-mini       # マシンを削除。そのルームトークンは無効化
hostel config providers remove ns         # オンデマンドルームがない場合のみ

アクティブなリースがあるマシンは削除できません：ドレインしてから待ちます。
ルームがあるオンデマンドマシンは削除できません：最初にルームを破棄します。
hostel admin room drain|undrain|repair|destroy <ルーム名またはID> でも同様の操作ができます。

オフラインマシン

intervals.presence（30秒）ごとに、サーバーはアイドル状態の各静的ルームをチェックします。応答しないルームは オフライン になり、リースを受け付けなくなります。再び応答すると、サーバーが自動的にルームを再準備します。コマンドは不要です。hostel status は offline (last seen ...) と表示します。hostel-troubleshoot を参照してください。

csansoon/hostel-rooms

hostel-rooms とは？

お気に入りのAIに質問する

ドキュメント

ルームの追加と管理

NAT背後にあるマシン（サーバーに参加）

サーバーがSSH経由で到達する静的マシン

Namespace（オンデマンドクラウドマシン）

外部プロバイダ（独自のコマンド）

制限とウォームルーム（オンデマンドマシン）

ドレイン、修復、削除、破棄

オフラインマシン

Individual skills in this repo

csansoon/hostel-install

csansoon/hostel-platforms

csansoon/hostel-server-setup

関連スキル

steipete/bluebubbles

steipete/eightctl

steipete/blucli

steipete/bear-notes

steipete/camsnap

steipete/gifgrep