# 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.

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ę.

```mermaid
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](/pl/docs/security/isolation/). O tym, co worker robi z żądaniem, przeczytasz w [Workery](/pl/docs/under-the-hood/workers/).

## Ten sam kontener, inna platforma

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