Fly.io, mikromaszyny, które zasypiają do zera

Fly.io, mikromaszyny, które zasypiają do zera

Fly.io bierze obraz kontenera i uruchamia go jako osobną maszynę wirtualną w jednym z osiemnastu regionów wymienionych w cenniku, licząc sobie za sekundy jej działania. Maszyna bez ruchu może zostać zatrzymana przez proxy i wtedy płacisz wyłącznie za jej system plików. Cena tej wygody siedzi gdzie indziej: w danych, które są przypięte do jednego serwera w jednym regionie.

Co Fly.io właściwie uruchamia

Podstawową jednostką jest Fly Machine, którą dokumentacja opisuje wprost jako maszynę wirtualną, a nie proces w kontenerze dzielącym środowisko z sąsiadami. Dostarczasz obraz zgodny z OCI albo Dockerfile, z którego Fly zbuduje obraz, a platforma tworzy z niego maszynę w wybranym regionie. Aplikacja, czyli Fly App, jest workiem na maszyny: może ich mieć jedną, może dziesięć w pięciu regionach.

Przed maszynami stoi Fly Proxy. To on kończy TLS, rozkłada ruch między maszyny, kieruje żądanie do najbliższego regionu i, co dla tego tekstu najważniejsze, potrafi zatrzymywać i uruchamiać maszyny na podstawie ruchu. Adresacja wygląda tak, że każda aplikacja dostaje współdzielony adres IPv4 i dowolną liczbę adresów anycast IPv6 za darmo, a dedykowany IPv4 kosztuje 2 dolary miesięcznie.

System plików maszyny jest ulotny i słaby wydajnościowo. Dokumentacja podaje twardy sufit: maksymalnie 2000 operacji wejścia i wyjścia na sekundę oraz 8 MiB na sekundę przepustowości, niezależnie od tego, jak dużą maszynę wybierzesz. Wszystko, co ma przetrwać wdrożenie i ma być szybkie, musi trafić na Fly Volume albo do bazy poza maszyną.

Wokół tego rdzenia narosła reszta oferty. Managed Postgres to zarządzany PostgreSQL w prywatnej sieci organizacji. Rozszerzenia to usługi obce sprzedawane przez rachunek Fly, między innymi obiektowy magazyn Tigris oraz Redis od Upstash. Fly Kubernetes to zarządzany klaster za 75 dolarów miesięcznie plus koszt maszyn i wolumenów, które w nim utworzysz. Maszyna może być w stanie uruchomionym, zatrzymanym albo zawieszonym, i te trzy stany rozliczają się zupełnie inaczej.

Pierwsze wdrożenie i plik fly.toml

Wejście w projekt wygląda tak samo dla każdego języka, bo wszystko sprowadza się do obrazu.

# instalacja narzędzia wiersza poleceń
curl -L https://fly.io/install.sh | sh

fly auth login

# wykrycie frameworka, wygenerowanie fly.toml i ewentualnie Dockerfile
fly launch

# wdrożenie bez pytania o potwierdzenie
fly deploy --now

# jedna maszyna zamiast pary zapasowej
fly deploy --ha=false

# wdrożenie tylko do wybranych regionów
fly deploy --regions ams,ord

# strategia wymiany: canary, rolling, bluegreen albo immediate
fly deploy --strategy bluegreen

fly status
fly logs
fly ssh console

Jedna rzecz z tej listy potrafi zaskoczyć na pierwszym rachunku. Flaga --ha domyślnie ma wartość prawda, co oznacza, że wdrożenie tworzy zapasowe maszyny podnoszące dostępność aplikacji. Świeżo uruchomiony projekt startuje więc z dwiema maszynami, a nie z jedną, i płacisz za obie. Jeśli budujesz środowisko testowe, --ha=false jest sensownym ustawieniem od pierwszego dnia.

Konfiguracja mieszka w pliku fly.toml w katalogu głównego projektu.

app = "sklep-demo"
primary_region = "ams"

[build]
  dockerfile = "Dockerfile"

[env]
  PORT = "8080"
  NODE_ENV = "production"

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = "suspend"
  auto_start_machines = true
  min_machines_running = 0

  [http_service.concurrency]
    type = "requests"
    soft_limit = 200
    hard_limit = 250

[[vm]]
  size = "shared-cpu-1x"
  memory = "512mb"
  cpu_kind = "shared"
  cpus = 1

[mounts]
  source = "sklep_dane"
  destination = "/data"
  initial_size = "10gb"
  snapshot_retention = 14

Pole primary_region decyduje, gdzie fly deploy tworzy nowe maszyny, i trafia do maszyny jako zmienna środowiskowa PRIMARY_REGION. Sekcja [[vm]] jest opcjonalna, ale jej brak ma konsekwencję: bez niej polecenia wdrożeniowe nie próbują wymuszać rozmiaru maszyn, a fly scale count przy pustej aplikacji sięgnie po shared-cpu-1x. Odwrotna pułapka jest gorsza. Jeśli powiększysz maszynę przez fly scale vm, a w pliku dalej stoi sekcja [[vm]] ze starym rozmiarem, następne fly deploy cofnie zmianę.

Sekcja [mounts] wymaga dwóch pól, source i destination, przy czym destination nie może być katalogiem głównym. Pole initial_size działa wyłącznie przy fly launch i fly deploy, gdy trzeba utworzyć nowy wolumen, i jest ignorowane przez fly volume create. Retencja migawek domyślnie wynosi pięć dni, minimum to jeden dzień, maksimum sześćdziesiąt.

Maszyny, które zasypiają i wstają na żądanie

Mechanizm autostop i autostart jest powodem, dla którego ten hosting w ogóle wygląda tanio przy nierównym ruchu. Za maszynę zatrzymaną albo zawieszoną nie płacisz za procesor ani pamięć, tylko za jej system plików.

Reguła zatrzymywania jest konkretna i dobrze ją znać, zanim zdziwisz się, że nic nie zasypia. Proxy co kilka minut sprawdza nadmiar mocy w każdym regionie osobno. Gdy w regionie stoi więcej niż jedna maszyna, liczy nadmiar = liczba maszyn - (liczba maszyn powyżej soft_limit + 1) i jeśli wynik jest równy co najmniej jeden, zatrzymuje dokładnie jedną maszynę. Jeden przebieg to jedna maszyna na region, więc schodzenie z dziesięciu maszyn do jednej zajmuje kilka takich cykli. Gdy w regionie została jedna maszyna, proxy sprawdza po prostu, czy ma ona jakikolwiek ruch, i przy obciążeniu zerowym ją usypia.

Wartość auto_stop_machines przyjmuje "off", "stop" albo "suspend", a domyślną wartością przy braku wpisu jest "off". To znaczy, że aplikacja bez tego pola nigdy nie zaśnie sama. Wariant "suspend" wstaje szybciej niż "stop", bo maszyna zachowuje stan pamięci, ale dokumentacja zaznacza, że ma swoje zastrzeżenia i nie zawsze jest możliwy. Pole auto_start_machines domyślnie ma wartość prawda, a min_machines_running domyślnie zero, przy czym ta ostatnia liczba dotyczy wyłącznie regionu podstawowego. Trzymanie jednej maszyny czuwającej w regionie podstawowym nie zapobiega usypianiu maszyn w pozostałych regionach.

Najważniejsze ograniczenie jest takie, że proxy nigdy nie tworzy ani nie kasuje maszyn. Sufit skalowania to liczba maszyn, które sam utworzyłeś przez fly scale count albo fly machine clone. Autostart tylko budzi to, co już istnieje. Dokumentacja ostrzega też, że przy tysiącach maszyn w jednej aplikacji rytm pętli sprawdzającej staje się wąskim gardłem i większość bezczynnych maszyn zostanie uruchomiona, bo proxy nie nadąża ich zatrzymywać. Do środowisk deweloperskich na użytkownika Fly zaleca wtedy osobną aplikację na użytkownika z routingiem dynamicznym albo wyłączanie się aplikacji samodzielnie po okresie bezczynności.

# lista maszyn z regionami i stanem
fly machine list

# ręczne zatrzymanie i uruchomienie
fly machine stop 3d8d9601a12345
fly machine start 3d8d9601a12345

# klon maszyny do innego regionu
fly machine clone 3d8d9601a12345 --region nrt

# dwie maszyny w Amsterdamie, jedna w Tokio
fly scale count 2 --region ams
fly scale count 1 --region nrt

# zmiana rozmiaru i pamięci
fly scale vm shared-cpu-2x
fly scale memory 1024

# dostępne rozmiary i regiony
fly platform vm-sizes
fly platform regions

Cennik i to, co zostało z planu darmowego

Rozliczenie idzie za organizację i za zasoby, bez pakietów. Karta płatnicza jest wymagana dla każdej organizacji poza organizacjami podpiętymi do rozliczenia nadrzędnego.

Za maszynę uruchomioną płacisz cenę nazwanego presetu plus mniej więcej 5 dolarów za każdy dodatkowy gigabajt pamięci na trzydzieści dni. Najmniejszy preset, shared-cpu-1x z 256 MB pamięci, kosztuje 0,0028 dolara za godzinę i wychodzi między 1,94 a 2,43 dolara miesięcznie zależnie od regionu, bo cennik nakłada na regiony różne narzuty. Ten sam preset z 1 GB pamięci to 5,92 dolara miesięcznie w najtańszej grupie, a performance-1x z 2 GB kosztuje 32,19 dolara. Za maszynę zatrzymaną płacisz wyłącznie za system plików: 0,15 dolara za gigabajt na trzydzieści dni. Rezerwacja bloku mocy daje 40 procent zniżki, na przykład 36 dolarów z góry za rok daje 5 dolarów kredytu miesięcznie na maszyny współdzielone w konkretnym regionie, przy czym kredyt nie przechodzi na kolejny miesiąc i obejmuje wyłącznie procesor oraz dodatkową pamięć.

Ruch wchodzący jest darmowy w całości. Za wychodzący płacisz według grupy regionów, a organizacje utworzone po 18 lipca 2024 roku są automatycznie objęte stawkami rozdzielonymi na ruch publiczny i prywatny. Przejścia na te stawki nie da się cofnąć.

Do tego dochodzą drobne pozycje, które sumują się szybciej, niż wygląda. Certyfikat na jedną nazwę hosta to 0,10 dolara miesięcznie, wieloznaczny 1 dolar, przy czym pierwsze dziesięć certyfikatów jednonazwowych w organizacji jest darmowych. Statyczny adres wyjściowy dla maszyny kosztuje 0,005 dolara za godzinę, czyli około 3,60 dolara miesięcznie. Wsparcie techniczne poza forum społeczności jest płatne: 29 dolarów miesięcznie za pakiet Standard, 199 za Premium, od 2500 za Enterprise.

Historia planu darmowego jest tu istotna, bo w sieci wciąż krąży opis stanu sprzed kilku lat. Plany zostały wycofane 7 października 2024 roku i nie są sprzedawane nowym klientom. Dawne darmowe przydziały, czyli do trzech maszyn shared-cpu-1x z 256 MB pamięci, 3 GB wolumenów oraz 100 GB ruchu wychodzącego w Ameryce Północnej i Europie plus po 30 GB w pozostałych grupach, są honorowane wyłącznie dla organizacji, które miały je przed tą datą. Kto przejdzie na rozliczenie za zużycie, nie wróci do starego planu.

Dziś nowe konto dostaje okres próbny, a nie plan darmowy. Obejmuje dwie godziny pracy maszyn albo siedem dni, zależnie od tego, co skończy się pierwsze. W jego ramach mieści się maksymalnie dziesięć maszyn, 20 GB wolumenów, do dwóch rdzeni i 4 GB pamięci na maszynę, a maszyny próbne są ustawione tak, żeby zatrzymywały się po pięciu minutach działania. Poza okresem próbnym zostają dedykowane adresy IPv4 i rdzenie o podwyższonej wydajności. Po wyczerpaniu limitów albo po siedmiu dniach aplikacje przestają działać, a nowych maszyn nie uruchomisz do czasu podania karty. Dodanie karty w trakcie kończy okres próbny natychmiast i od tego momentu wszystko liczy się do rachunku.

Dane przypięte do regionu

Tu leży realna granica pomysłu na aplikację rozstawioną po świecie. Fly Volume to wycinek dysku NVMe na tym samym fizycznym serwerze, na którym stoi maszyna, i jest z tym sprzętem związany. Wolumen należy do jednej aplikacji, istnieje w jednym regionie na jednym serwerze i podpina się do dokładnie jednej maszyny. Nie jest to magazyn sieciowy i platforma nie replikuje danych między wolumenami. Jeśli chcesz, żeby dwie kopie się zgadzały, replikację musi zrobić Twoja aplikacja.

Konsekwencje są bezlitosne i dokumentacja pisze o nich wprost, ostrzegając, żeby zawsze mieć co najmniej dwa wolumeny na aplikację. Awaria dysku pod jedyną maszyną z wolumenem to przestój, a przy jednej kopii danych także ich utrata. Migawki są robione codziennie z retencją od jednego do sześćdziesięciu dni, domyślnie pięć, ale Fly sam pisze, że nie powinny być podstawową kopią zapasową. Za wolumeny płacisz 0,15 dolara za gigabajt miesięcznie od pojemności przydzielonej, a nie zajętej, i płacisz także wtedy, gdy maszyna jest zatrzymana albo gdy wolumen w ogóle nie jest do niczego podpięty. Migawki kosztują 0,08 dolara za gigabajt miesięcznie ponad pierwsze 10 GB w miesiącu, a opłata za nie weszła 1 stycznia 2026 roku i pojawiła się pierwszy raz na fakturze z początku lutego.

Managed Postgres nie zdejmuje tego problemu, tylko przenosi go poziom wyżej. Plany zaczynają się od pakietu Basic z rdzeniem współdzielonym i 1 GB pamięci za 38 dolarów miesięcznie, przez Starter z 2 GB za 72 dolary, Launch z rdzeniem wydajnym i 8 GB za 282 dolary, Scale za 962 dolary, aż po Performance za 1922 dolary. Do tego dochodzi 0,28 dolara za każdy przydzielony gigabajt magazynu na trzydzieści dni. Klaster jest wysokodostępny, ale mieszka w jednym regionie, więc maszyna w Tokio odpytująca bazę w Amsterdamie płaci opóźnieniem, a od lutego 2026 roku także transferem prywatnym po stawkach z tabeli powyżej.

Dwie rzeczy o Managed Postgres, o których łatwo się nie dowiedzieć na czas. Baza żyje poza aplikacją, więc skasowanie aplikacji nie kasuje bazy i rachunek biegnie dalej. Druga jest poważniejsza: dokumentacja wymienia poprawki bezpieczeństwa i aktualizacje wersji jako funkcje dopiero rozwijane, obok alertów dla klienta i narzędzi migracyjnych. Jak na usługę nazwaną zarządzaną, to zastrzeżenie warte przeczytania dwa razy przed wdrożeniem produkcyjnym. Samodzielnie prowadzony Fly Postgres nadal działa, ale cennik opisuje go w sekcji produktów nieobsługiwanych.

Praktyczny wniosek jest taki, że globalna jest warstwa bezstanowa, a nie dane. Sensowny układ to baza w jednym regionie, maszyny bezstanowe blisko użytkowników i pamięć podręczna na brzegu. Do tego ostatniego pasuje Redis od Upstash sprzedawany jako rozszerzenie, z zastrzeżeniem z cennika, że transfer danych do takich usług obcych jest rozliczany osobno.

Licencje i to, co naprawdę jest otwarte

Platforma jest zamknięta. Otwarte są narzędzia wokół niej i tu robi się ciekawie, bo trzy źródła licencji nie mówią tego samego.

Narzędzie wiersza poleceń, repozytorium superfly/flyctl, ma w katalogu głównym plik LICENSE z pełnym tekstem Apache 2.0, a interfejs programistyczny GitHuba raportuje dla niego Apache-2.0. Repozytorium ma około 1695 gwiazdek, 310 rozgałęzień, 216 otwartych zgłoszeń i nie jest zarchiwizowane, a ostatnia zmiana pochodzi z 21 sierpnia 2026 roku. Bieżące wydanie to v0.4.87 z 20 sierpnia 2026 roku. Rozbieżność siedzi w opublikowanym artefakcie: archiwum wydania zawiera dokładnie jeden plik, binarium flyctl, i żadnego pliku licencyjnego. Kto instaluje narzędzie skryptem instalacyjnym, dostaje program bez tekstu licencji, choć licencja jak najbardziej istnieje w repozytorium.

Drugi przypadek jest gorszy. Generator plików Dockerfile dla projektów w Node, pakiet @flydotio/dockerfile w wersji 0.7.10, deklaruje w rejestrze npm licencję MIT. Repozytorium fly-apps/dockerfile-node nie ma pliku licencyjnego, a punkt końcowy licencji w interfejsie GitHuba zwraca dla niego 404. Opublikowana paczka też nie zawiera żadnego pliku licencyjnego. Cała informacja o licencji MIT to jedno pole w package.json i nic więcej. Do audytu zależności to za mało, a pakiet jest tym, co fly launch proponuje projektom w Node.

Trzecia pułapka jest nazewnicza. W rejestrze npm istnieje pakiet o nazwie flyctl w wersji 1.2.11, na licencji MIT, ale to nakładka osoby trzeciej na oficjalne narzędzie, z repozytorium poza organizacją Fly. Instalacja npm install flyctl nie daje oficjalnego narzędzia.

Z rzeczy naprawdę otwartych i używanych poza Fly warto wymienić dwie. LiteFS, rozproszony system plików do replikacji SQLite, jest na Apache 2.0 i ma około 4866 gwiazdek, choć ostatnia zmiana pochodzi z maja 2026 roku. Corrosion, rozproszony magazyn stanu, także Apache 2.0, ma około 1829 gwiazdek i jest aktywnie rozwijany.

Kwestia przywiązania do dostawcy jest prosta do oszacowania. Obraz kontenera przeniesiesz wszędzie. Nie przeniesiesz fly.toml, zachowania proxy z autostopem, prywatnej sieci z adresami Flycast ani API maszyn. Im więcej logiki oprzesz na tym, że maszyna wstaje na żądanie w konkretnym regionie, tym więcej trzeba będzie napisać od nowa przy przeprowadzce.

Fly.io a alternatywy

Wybór rozstrzyga się na kształcie aplikacji. Jeśli masz długo żyjący proces, gniazda WebSocket, zadania w tle albo obraz, który musi być tym samym obrazem lokalnie i na produkcji, Fly.io pasuje lepiej niż model bezserwerowy Vercela czy Netlify. Jeśli budujesz witrynę z frameworka i chcesz podglądów dla każdej gałęzi bez pisania konfiguracji, tamte platformy dowożą to bez pracy. Railway stoi bliżej Fly.io pod względem modelu, ale nie daje tak drobiazgowej kontroli nad rozstawieniem maszyn w regionach. Jeśli natomiast głównym powodem jest koszt i chcesz mieć wszystko u siebie, Coolify na własnym serwerze wychodzi taniej, kosztem tego, że utrzymanie serwera staje się Twoją pracą.

Typowe błędy

Pierwszy to założenie, że aplikacja usypia sama. Domyślną wartością auto_stop_machines przy braku wpisu jest "off", więc maszyna utworzona ręcznie albo skopiowana z cudzej konfiguracji będzie mieliła całą dobę. Sprawdź plik, a nie intuicję.

Drugi to zapomniane wolumeny. Płacisz za pojemność przydzieloną od chwili utworzenia, także wtedy, gdy wolumen nie jest podpięty do żadnej maszyny, a skasowanie maszyny wolumenu nie usuwa. Po eksperymentach przejrzyj fly volume list w każdej aplikacji.

Trzeci to baza pozostawiona po skasowanej aplikacji. Managed Postgres żyje poza aplikacją i usunięcie aplikacji nie dotyka klastra, co przy planie za 282 dolary miesięcznie boli konkretnie.

Czwarty to fly scale vm przy zostawionej sekcji [[vm]] w pliku konfiguracyjnym. Zmiana rozmiaru zrobiona z wiersza poleceń zostanie cofnięta przy najbliższym wdrożeniu, bo plik ma pierwszeństwo.

Piąty to liczenie na autoskalowanie, którego nie ma. Proxy budzi wyłącznie maszyny już utworzone, więc sufit ruchu wyznacza fly scale count, a nie chwilowe obciążenie.

Szósty to rozstawienie maszyn po świecie przy bazie w jednym regionie. Maszyna w Sydney odpytująca Postgresa w Amsterdamie odda gorszy czas odpowiedzi niż jedna maszyna w Amsterdamie, a od lutego 2026 roku dołoży do tego rachunek za transfer prywatny.

Siódmy to przeoczenie flagi --ha. Domyślnie wdrożenie tworzy maszyny zapasowe, więc projekt, który miał kosztować dwa dolary miesięcznie, kosztuje cztery.

Ósmy to traktowanie okresu próbnego jak planu darmowego. Dwie godziny pracy maszyn kończą się szybciej, niż wygląda, zwłaszcza gdy maszyna nie usypia, a po ich wyczerpaniu aplikacje po prostu stają.

FAQ

Czy Fly.io ma plan darmowy?

Nie. Plany zostały wycofane 7 października 2024 roku, a dawne darmowe przydziały honoruje się wyłącznie organizacjom, które miały je wcześniej. Nowe konto dostaje okres próbny: dwie godziny pracy maszyn albo siedem dni, do dziesięciu maszyn i 20 GB wolumenów. Karta jest wymagana dla każdej organizacji rozliczanej samodzielnie.

Ile kosztuje najmniejsza aplikacja utrzymywana cały czas?

Jedna maszyna shared-cpu-1x z 256 MB pamięci działająca bez przerwy to od 1,94 do 2,43 dolara miesięcznie zależnie od regionu. Do tego dochodzi wolumen po 0,15 dolara za gigabajt, ruch wychodzący po 0,02 dolara za gigabajt w Europie i Ameryce Północnej oraz ewentualny dedykowany IPv4 za 2 dolary.

Co dokładnie dzieje się z maszyną bez ruchu?

Proxy co kilka minut liczy nadmiar mocy w regionie. Przy jednej maszynie w regionie i obciążeniu zerowym zatrzymuje ją lub zawiesza, przy wielu maszynach usypia jedną na przebieg. Za maszynę zatrzymaną płacisz tylko za system plików, 0,15 dolara za gigabajt na trzydzieści dni.

Czy wolumen da się replikować między regionami?

Nie automatycznie. Wolumen istnieje na jednym serwerze w jednym regionie i platforma nie synchronizuje danych między wolumenami. Replikację musi zapewnić aplikacja, na przykład przez LiteFS przy SQLite albo przez replikację po stronie bazy.

Czy flyctl jest oprogramowaniem otwartym?

Repozytorium superfly/flyctl jest na licencji Apache 2.0 i tak też raportuje je interfejs GitHuba. Archiwum wydania zawiera samo binarium, bez pliku licencyjnego. Sama platforma, czyli proxy i warstwa zarządzania maszynami, pozostaje zamknięta.

Kiedy Fly.io nie jest dobrym wyborem?

Gdy aplikacja jest witryną statyczną z formularzami, bo wtedy prostsze są platformy bezserwerowe. Gdy potrzebujesz bazy replikowanej między regionami bez pisania tego samodzielnie. Gdy nie chcesz utrzymywać własnego pliku Dockerfile ani myśleć o tym, w którym regionie stoi który dysk.

Cennik zasobów opisuje dokumentacja Fly.io, warunki okresu próbnego osobna strona, a kod narzędzia wiersza poleceń leży w repozytorium na GitHubie.