Firecracker kontra klasyczny hosting. Czy Claude Code właśnie zmienił wszystko?

Firecracker kontra klasyczny hosting. Czy Claude Code właśnie zmienił wszystko?

Wrz 12, 2026 ai infrastructure firecracker microvms claude code cloud hosting paas developer tools cloud computing

Tajna infrastruktura Claude Code, o której nikt nie mówi

Każdy programista, który korzystał z Claude Code, zauważył, że coś jest tutaj inne. Środowisko działa szybko — podejrzanie szybko. Sesje uruchamiają się błyskawicznie, system plików jest czysty, a wszystko działa przez przeglądarkę. Ale czy zastanawiałeś się kiedyś, co tak naprawdę się dzieje, gdy się łączysz?

Okazuje się, że większość ludzi też nie — przynajmniej do teraz.

Na jaw wyszła fascynująca analiza reverse-engineering, która pokazuje, jak faktycznie działa środowisko wykonawcze Claude Code. To, co znaleziono, sugeruje, że Anthropic nie tylko buduje modele AI. Cicho konstruują warstwę infrastrukturalną, która może zagrozić platformom takim jak Vercel, Railway i Render.

To wszystko stoi na Firecracker

Serce technologii zasilającej Claude Code to Firecracker — ten sam open-source'owy mikromonitor, który napędza AWS Lambda i Fargate. Jeśli budujesz infrastrukturę chmurową, powinieneś zwrócić na to uwagę.

Oto co działa w każdej sesji Claude Code:

  • 4 vCPU (Intel Xeon Cascade Lake @ 2.80GHz)
  • 16 GB RAM
  • 252 GB dysku
  • Kernel Linux 6.18.5

Żadnego zagnieżdżonego wirtualizowania. Firecracker celowo usuwa flagi VMX/SVM, które pozwalałyby gościowi na uruchamianie własnych maszyn wirtualnych — to świadome posunięcie bezpieczeństwa izolujące obciążenia.

Ale tutaj robi się ciekawie: nie ma systemd. Żadnego demona SSH. Żadnego crona. Żadnej infrastruktury logowania. Całe drzewo procesów wygląda tak:

PID 1: /process_api --firecracker-init --addr 0.0.0.0:2024
  └─ PID 517: /usr/local/bin/environment-manager task-run --session cse_...
       └─ PID 532: claude (sama konsola)

Trzy procesy. I tyle. Pierwszy proces to niestandardowy binarny plik działający jako system init i brama API WebSocket. Nasłuchuje na porcie 2024 połączeń WebSocket i portu 2025 dla dodatkowych endpointów.

To elegancki projekt infrastruktury — usuwanie wszystkiego, co niepotrzebne, aby zminimalizować powierzchnię ataku i zmaksymalizować wydajność.

Architektura snapshotów: tam dzieje się magia

Najbardziej niezwykłe odkrycie to nie sama mikromaszyna — to jak sesje są inicjalizowane.

Sesje nie bootują od zera. Są przywracane ze zamrożonych snapshotów.

Gdy badacze sprawdzili logi bootowania, znaleźli 48,5-godzinną lukę między utworzeniem szablonowej VM a przywróceniem sesji:

[  30.731516] Run /process_api as init process
    ~~~ 48.5 HOUR GAP — VM WAS FROZEN AS SNAPSHOT ~~~
[174695.927758] virtio_blk: [vdc] new size: ...

To w zasadzie ten sam koncept SnapStart, który AWS Lambda spopularyzowało. Szablon bootuje raz, inicjalizuje się do stanu gotowości, a potem zostaje zamrożony jako snapshot. Gdy uruchamiasz nową sesję, system przywraca ten snapshot w milisekundach zamiast czekać na pełną sekwencję startową.

Hot-swapping urządzeń podczas przywracania jest szczególnie sprytny:

| Urządzenie | Szablon | Po przywróceniu | Zawartość | |------------|---------|-----------------|-----------| | vda | placeholder | 256 GiB ext4 | Session rootfs (Ubuntu 24.04) | | vdb | placeholder | 63.7 MB squashfs | /opt/claude-code | | vdc | placeholder | 12.1 MB squashfs | /opt/env-runner |

System plików root to dynamicznie wstrzykiwane urządzenie blokowe. Środowisko Ubuntu siedzi na wolumenie ext4, który jest podmieniany w czasie przywracania, podczas gdy narzędzia Claude Code i runner środowiska są montowane jako nakładki squashfs.

Takie warstwowe podejście oznacza, że każda sesja dostaje czyste, izolowane środowisko bez narzutu ponownego tworzenia całego systemu plików.

Co "Antspace" oznacza dla wyścigu infrastruktury AI

Oto spekulacja, która robi robotę: reverse-engineering ujawnił referencje sugerujące, że Anthropic może budować wewnętrzną platformę zwaną "Antspace."

Jeśli to prawda, stawia to Anthropic jako potencjalnego konkurenta PaaS — Vercel dla aplikacji natywnych dla AI.

Pomyśl, co budują:

  • Środowisko wykonawcze obsługujące autoryzację, zarządzanie procesami i komunikację WebSocket
  • Izolowane wykonanie oparte na mikromaszynach z silnymi granicami bezpieczeństwa
  • Natychmiastowe wdrażanie i skalowanie oparte na snapshotach
  • Architekturę API-first zaprojektowaną dla programistycznej kontroli

To dokładnie infrastruktura, której potrzebujesz, żeby obsługiwać nie tylko Claude Code, ale cały arsenał narzędzi programistycznych opartych na AI, pipeline'ów wdrożeniowych i platform hostingowych.

Architektura bezpieczeństwa zasługuje na uwagę

Zespół wyraźnie dobrze przemyślał bezpieczeństwo. Na uwagę zasługują takie środki:

init_on_free=1 — Strony pamięci są zerowane po zwolnieniu, co zapobiega wyciekom danych między sesjami.

CRNG reseeding — Generator kryptograficznych liczb losowych jest ponownie zasilany po przywróceniu VM. To kluczowe, bo snapshoty mogłyby teoretycznie dzielić ten sam stan entropii, co stanowiłoby podatność kryptograficzną.

Capability dropping — Po inicjalizacji PID 1 porzuca CAP_SYS_RESOURCE, ograniczając możliwości procesu nawet w przypadku kompromitacji.

--block-local-connections — Dostęp WebSocket do localhost jest zablokowany, uniemożliwiając sesji bezpośrednie łączenie się z interfejsami zarządzania.

Autentykacja JWT — Połączenia WebSocket wymagają zweryfikowanych tokenów, a sekrety są usuwane z konfiguracji po użyciu.

To nie są theatricalne środki bezpieczeństwa — to realne wzmocnienia sugerujące, że ta infrastruktura była projektowana z myślą o produkcyjnych obciążeniach.

Dlaczego to ma znaczenie dla programistów

Niezależnie od tego, czy budujesz narzędzia AI, agentów kodujących, czy aplikacje cloud-native, wzorce wyłaniające się z infrastruktury Claude Code warto studiować:

  1. Firecracker staje się domyślnym wyborem dla obciążeń wymagających izolacji. Jeśli oceniasz kontenery kontra mikromaszyny, Firecracker oferuje bezpieczeństwo na poziomie VM z szybkością kontenerów.

  2. Inicjalizacja oparta na snapshotach to przyszłość dla wszystkiego, co wymaga czasów startu poniżej sekundy. Ten wzorzec rozprzestrzenia się od Lambda do środowisk programistycznych.

  3. Niestandardowe systemy init przeżywają renesans. Gdy nie potrzebujesz pełnego stosu systemd, minimalny niestandardowy supervisor może być szybszy, bezpieczniejszy i bardziej dopasowany do celu.

  4. Firmy AI budują infrastrukturę, która może ostatecznie konkurować z tradycyjnymi dostawcami chmury. Wewnętrzna platforma Anthropic, jeśli jest prawdziwa, reprezentuje znaczącą inwestycję w przestrzeń hostingową.

Następnym razem, gdy uruchamiasz Claude Code, nie korzystasz tylko z narzędzia CLI — patrzysz na wgląd w infrastrukturę chmurową natywną dla AI, która może zdefiniować, jak inteligentne aplikacje są budowane i wdrażane w nadchodzących latach.

Szerszy obraz

Najbardziej uderzające w tym odkryciu nie jest żaden pojedynczy szczegół techniczny. To dowód, że firmy AI myślą poważnie o pełnym stosie — nie tylko modelach, ale infrastruktury do uruchamiania wszystkiego, co te modele umożliwiają.

Anthropic nie tylko buduje Claude. Buduje platformę, która może wspierać nową generację aplikacji natywnych dla AI.

A jeśli "Antspace" jest prawdziwy? Konkurencja w przestrzeni hostingu AI właśnie się robi bardzo interesująca.


Masz przemyślenia na temat infrastruktury AI lub chcesz podzielić się własnymi odkryciami z reverse-engineeringu? Społeczność programistyczna rozkwita dzięki takim rozmowom. Czasami najcenniejsze wglądy pochodzą z zaglądania pod maskę.

Read in other languages:

BG RU EL CS UZ TR SV FI PT RO NB HU NL IT FR ES DE DA ZH-HANS EN