Topologia kontenerów

Speedwave uruchamia każdy projekt jako zestaw kontenerów wewnątrz małej maszyny wirtualnej z Linuksem, dzięki czemu wszystko to trzyma z dala od twojego komputera.

Maszyna wirtualna

Speedwave nie korzysta z Docker Desktop. Zamiast tego uruchamia własną maszynę wirtualną z Linuksem i wewnątrz niej umieszcza środowisko uruchomieniowe kontenerów.

macOS
Windows

Speedwave uruchamia maszynę wirtualną Lima na Virtualization Framework od Apple. Lima jest dołączona do aplikacji w komplecie i pozostaje odizolowana od każdej innej instalacji Limy, jaką możesz mieć na swoim komputerze.

Rozmiar maszyny wirtualnej dobierany jest na podstawie twojego sprzętu: to połowa pamięci RAM hosta, ograniczona do widełek od 4 GiB do 32 GiB. Mac z 16 GiB RAM dostaje maszynę o rozmiarze 8 GiB.

Speedwave uruchamia dedykowaną dystrybucję WSL2 o nazwie Speedwave, opartą na Hyper-V. Kreator konfiguracji przygotowuje ją przy pierwszym uruchomieniu aplikacji, a gdyby to się nie powiodło, instalator ma w zapasie awaryjny tryb offline. Przy każdym starcie Speedwave ostrzegawczo sprawdza dwa niezmienniki: czy wersja nerdctl wewnątrz dystrybucji jest przypięta i czy opcje punktów montowania drvfs są poprawne, tak aby uid kontenera nie napotykał błędów uprawnień przy starcie.

Pamięcią i procesorem zarządza samo WSL2, a Speedwave się w to nie wtrąca. Dopisuje jednak do współdzielonego pliku .wslconfig klucze zgodności z VPN, dzięki czemu usługi kierowane przez VPN pozostają osiągalne z wnętrza dystrybucji. Zaczynają działać po wsl --shutdown, o które Speedwave sam cię poprosi.

Obie platformy wymagają co najmniej 16 GiB RAM. Na macOS Speedwave sprawdza to przy starcie i ostrzega cię, gdy masz mniej. Windows nie zawsze potrafi odczytać ilość RAM hosta, więc tam ostrzeżenie może się nie pojawić, ale wymóg nadal obowiązuje.

Speedwave tłumaczy też ścieżki hosta z Windows na potrzeby kontenerów: litera dysku w rodzaju C:\Users\... staje się /mnt/c/Users/..., a ścieżka UNC WSL prowadząca do własnej dystrybucji Speedwave mapowana jest wprost. Ścieżkę do innej dystrybucji albo do zasobu sieciowego program odrzuca i podpowiada, jak ją naprawić.

Kontenery dla każdego projektu

Każdy projekt działa we własnej sieci o nazwie speedwave_<project>_network i nigdy nie widzi kontenerów innego projektu. W tej sieci Speedwave uruchamia:

speedwave_<project>_claude: kontener, w którym działa Claude Code. Nie przechowuje żadnych tokenów ani nie ma gniazda silnika kontenerów.
speedwave_<project>_proxy: własny pośrednik Speedwave dla ruchu LLM.
speedwave_<project>_mcp_hub: MCP Hub, jedyny serwer MCP, jaki widzi Claude.
speedwave_<project>_mcp_<service>: po jednym kontenerze na każdą podłączoną integrację.

flowchart TB
  subgraph VM["Linux VM (Lima on macOS / WSL2 on Windows)"]
    subgraph NET["speedwave_&lt;project&gt;_network"]
      Claude["claude<br/>no tokens, no socket"]
      Proxy["proxy<br/>port 4000"]
      Hub["mcp_hub<br/>port 4000, zero tokens"]
      W1["mcp_&lt;service&gt; worker<br/>/tokens:ro"]
      W2["mcp_&lt;service&gt; worker<br/>/tokens:ro"]
      Claude -->|"LLM traffic"| Proxy
      Claude -->|"tools"| Hub
      Hub --> W1
      Hub --> W2
    end
  end

Kontener Claude sięga tylko do dwóch miejsc: do proxy po ruch LLM i do MCP Hub po narzędzia. Z żadną usługą nie łączy się nigdy bezpośrednio. Każdy worker montuje wyłącznie dane uwierzytelniające własnej usługi, i to w trybie tylko do odczytu, a sam hub nie przechowuje żadnych tokenów. Tę granicę w całości opisuje Model izolacji. O tym, co worker robi z żądaniem, przeczytasz w Workery.

Ten sam kontener, inna platforma

Obrazy kontenerów są identyczne na macOS i na Windows. Zmienia się tylko maszyna wirtualna pod spodem.