Windmill, skrypty i przepływy jako narzędzie wewnętrzne

Windmill, skrypty i przepływy jako narzędzie wewnętrzne

Windmill bierze zwykły skrypt w Pythonie, TypeScripcie, Go albo Bashu, czyta jego sygnaturę i robi z niej formularz, punkt końcowy oraz krok przepływu. Bieżąca wersja to 1.795.0 z 22 sierpnia 2026 roku. Najciekawsza jest tu licencja, bo granica między kodem otwartym a własnościowym biegnie przez flagę kompilacji, a nie przez katalog.

Co Windmill właściwie robi

Jednostką budulcową jest skrypt, a nie węzeł w edytorze graficznym. Piszesz funkcję, Windmill parsuje jej sygnaturę i wyprowadza z niej schemat wejścia. Stąd w paczce narzędzia wierszowego czternaście osobnych parserów skompilowanych do WebAssembly, po jednym na język: windmill-parser-wasm-py, windmill-parser-wasm-ts, windmill-parser-wasm-go, windmill-parser-wasm-php, windmill-parser-wasm-java, windmill-parser-wasm-ruby, windmill-parser-wasm-rust, windmill-parser-wasm-csharp, windmill-parser-wasm-nu, windmill-parser-wasm-r i kilka pomocniczych. Schemat wejścia zamienia się w formularz, w treść żądania dla punktu końcowego i w listę pól do wypełnienia, gdy skrypt jest krokiem w przepływie.

Zestaw języków po stronie serwera daje się odczytać wprost z pliku backend/Cargo.toml, bo każdy jest osobną flagą kompilacji: python, rust, php, csharp, java, ruby, rlang, nu, do tego silniki zapytań mysql, mssql, oracledb, bigquery, snowflake, duckdb, a TypeScript przez deno_core. Meta-flaga all_languages włącza je razem. Jeśli budujesz obraz samodzielnie i pominiesz duckdb, ten język po prostu nie istnieje w tym pliku wykonywalnym.

Nad skryptami siedzą przepływy zapisane w formacie OpenFlow. Przepływ to lista kroków, gdzie krok jest albo odwołaniem do skryptu w przestrzeni roboczej, albo kodem osadzonym wprost w definicji. Do tego dochodzą pętle po kolekcji, rozgałęzienia, ponowienia, uśpienia i kroki oczekujące na zatwierdzenie przez człowieka. Wyzwalacze to harmonogramy, punkty końcowe HTTP, WebSocket, nasłuch na Postgresie, MQTT, AMQP i poczta. Kafka, NATS, SQS, GCP oraz Azure Event Grid są w grupie flag ee_core, czyli tylko w edycji płatnej, i pokrywa się to z tabelą na stronie cennika.

Warstwa wykonawcza to workery czytające kolejkę z Postgresa. W pliku docker-compose.yml z repozytorium ten sam obraz uruchamiany jest z MODE=server albo MODE=worker, a grupa native startuje dodatkowo z NATIVE_MODE=true. Domyślna baza w tym pliku to postgres:16, więc znajomość PostgreSQL przydaje się tu bardziej niż przy typowym narzędziu automatyzacji.

Licencja, czyli rozdzielnik zamiast licencji

Plik LICENSE w korzeniu repozytorium nie jest licencją. To rozdzielnik, który mówi, że kod jest licencjonowany rozmaicie: część na Apache 2.0 z pliku LICENSE-APACHE, część na AGPLv3 z pliku LICENSE-AGPL, a część funkcji dla firm na licencji własnościowej.

Podział wygląda tak. Katalogi python-client/, deno-client/, go-client/ i powershell-client/ są na Apache 2.0, tak samo pliki OpenAPI wraz ze specyfikacją OpenFlow. Cała reszta jest domyślnie na AGPLv3. Pliki pod backend/ są na AGPLv3 z wyjątkiem fragmentów kodu pod flagą kompilacji enterprise, a pliki pod frontend/ są na AGPLv3 z wyjątkiem fragmentów, które do uruchomienia wymagają pozytywnego sprawdzenia klucza licencyjnego. Te wyjątki są własnościowe i komercyjne. Rozdzielnik dodaje wprost, że rozgałęzienia prywatne i publiczne nie mogą zawierać tego kodu.

Granica biegnie więc przez flagę, nie przez katalog. W praktyce flagi są dwie, co widać w sekcji meta-flag pliku backend/Cargo.toml.

# backend/Cargo.toml, sekcja "Edition meta-features", fragment
oss     = ["oss_core", "all_languages", "no_auth"]
ce_core = ["oss_core", "private", "operator"]
ce_rpi  = ["ce_core", "all_languages"]
ce      = ["ce_rpi", "jemalloc", "dind", "agent_worker_server"]
ee      = ["ce", "ee_core", "ee_server", "kafka-gssapi"]

Flaga private wciąga moduły, których w publicznym repozytorium nie ma. Publiczne drzewo zawiera pliki z przyrostkiem _oss, a one pod tą flagą reeksportują moduły ee. Sprawdziłem pod znacznikiem wydania v1.795.0: backend/windmill-common/src/ee.rs oraz backend/windmill-git-sync/src/git_sync_ee.rs zwracają kod 404. Druga flaga to enterprise, która włącza zachowania edycji płatnej i pociąga za sobą flagę license. Zestaw oss nie zawiera żadnej z nich, zestaw ce zawiera private bez enterprise, a zestaw ee obie.

Co dokładnie robi kod pod flagą, widać po samych zaślepkach. Poniżej skrót z pliku backend/windmill-git-sync/src/git_sync_oss.rs.

// backend/windmill-git-sync/src/git_sync_oss.rs, skrót
#[cfg(feature = "private")]
pub use crate::git_sync_ee::*;

#[cfg(not(feature = "private"))]
pub async fn handle_deployment_metadata<'c>(
    _email: &str,
    _created_by: &str,
    _db: &DB,
    _w_id: &str,
    _obj: DeployedObject,
    _deployment_message: Option<String>,
    _skip_db_insert: bool,
    _renamed_from: Option<&str>,
) -> Result<()> {
    // komentarz w oryginale: synchronizacja z Gitem to funkcja edycji płatnej
    return Ok(());
}

Analogicznie backend/windmill-api/src/ee_oss.rs zawiera funkcję validate_license_key, która w wariancie otwartym zwraca błąd z informacją, że klucza nie da się zweryfikować w edycji społecznościowej. W backend/windmill-common/src/ee_oss.rs leżą stany LICENSE_KEY_VALID, LICENSE_OFFLINE_OVER_CU_CAP i LICENSE_OFFLINE_OVER_SEAT_CAP oraz struktura OfflineMetadata z polami v, kind, hash, seats i cu_limit. To pokazuje, że licencja offline nosi ze sobą liczbę miejsc i pułap jednostek obliczeniowych, a instancja sama pilnuje, czy je przekroczyła.

Po stronie frontendu sprawdzenie jest jednym wywołaniem. Plik frontend/src/lib/enterpriseUtils.ts eksportuje funkcję setLicense, która woła SettingsService.getLicenseId() i zapisuje wynik w magazynie enterpriseLicense. Elementy interfejsu, które ten magazyn odczytują, są tymi własnościowymi fragmentami z rozdzielnika. Z publicznego repozytorium nie da się wypisać ich listy w sposób pewny, bo to zwykłe warunki w komponentach, więc jedynym praktycznym spisem pozostaje tabela porównawcza na stronie cennika.

Budując ze źródeł z flagą oss dostajesz czyste AGPLv3, bo rozdzielnik mówi wprost, że plik wykonywalny skompilowany bez flagi enterprise jest oprogramowaniem otwartym na warunkach AGPLv3. Sprawdzenie, co się zbudowało, jest pośrednie, bo nie ma punktu końcowego wypisującego listę flag. Działają za to trzy obserwacje. Uruchomienie w trybie agenta na pliku bez flagi enterprise kończy się paniką z komunikatem, że tryb agenta jest dostępny tylko w edycji płatnej. Wpisanie klucza licencyjnego kończy się błędem opisanym wyżej. Indekser pełnotekstowy zgłasza, że biblioteka tantivy nie znalazła się w tym pliku ani obrazie.

Najważniejsza konsekwencja dotyczy obrazów. Rozdzielnik stwierdza, że edycja społecznościowa dostępna w obrazach pod ghcr.io/windmill-labs/windmill oraz w wydaniach binarnych na GitHubie zawiera pliki na AGPLv3 i Apache 2.0, ale również kod niepubliczny i własnościowy. Potwierdza to zestaw ce_core, który zawiera private. Warunki dla tej edycji są własne: wolno używać wszystkich jej funkcji bez opłat, w granicach limitów i przydziałów zaszytych w programie, wolno rozpowszechniać ją w postaci niezmienionej, natomiast nie wolno jej sprzedawać, odsprzedawać, oferować jako usługi zarządzanej, modyfikować ani opakowywać bez osobnej umowy. Plik .env w repozytorium pokazuje oba adresy obrazów: ghcr.io/windmill-labs/windmill:main dla edycji społecznościowej i ghcr.io/windmill-labs/windmill-ee:main dla płatnej.

Odpowiedź na pytanie, na jakiej licencji jesteś, brzmi więc: to zależy od tego, skąd wziąłeś plik wykonywalny. Z oficjalnego obrazu jesteś na własnych warunkach Windmill Labs, nie na AGPLv3, i nie wolno ci tego obrazu modyfikować. Z własnej kompilacji z flagą oss jesteś na AGPLv3 i modyfikować wolno, ale bez funkcji, które siedzą pod private.

Kiedy obowiązki z AGPLv3 faktycznie się uruchamiają przy narzędziu wewnętrznym. Sam fakt uruchomienia niezmienionego programu w firmie niczego nie wymaga poza zachowaniem not licencyjnych. Sekcja 13 licencji dotyczy sytuacji, w której udostępniasz zmodyfikowaną wersję użytkownikom przez sieć, a wtedy tym użytkownikom należy się odpowiadający kod źródłowy. Pracownicy klikający w panel przez przeglądarkę są takimi użytkownikami. Jeśli więc łatasz backend i wystawiasz go w intranecie, kod z łatami należy się osobom, które z niego korzystają, i nikomu więcej. Twoje skrypty i przepływy nie są dziełem zależnym od serwera, a biblioteki klienckie leżą na Apache 2.0 właśnie po to, żeby zaimportowanie wmill w skrypcie nie wciągało copyleftu. To odczyt tekstu licencji, nie porada prawna.

Wersja, pakiety i stan projektu

Wydania wychodzą prawie codziennie. Kanał wydań pokazuje 1.790.0 z 15 sierpnia, a 1.795.0 z 22 sierpnia 2026 roku, czyli dziewięć wydań w osiem dni, wliczając poprawkowe 1.792.1, 1.792.2 i 1.794.1. Taka częstotliwość ma dwie strony: poprawki docierają szybko, ale przypięcie znacznika main albo latest w produkcji oznacza, że instancja zmienia się codziennie.

Narzędzie wierszowe windmill-cli ma w rejestrze npm 765 wersji, ostatnia to 1.795.0 opublikowana 22 sierpnia 2026 roku. Żadna wersja nie jest oznaczona jako wycofana. Poza znacznikiem latest wisi tam drugi, gitsync, wskazujący na 1.777.2-gitsync.0, więc instalacja bez podania wersji zawsze bierze latest. Paczka po rozpakowaniu ma około 3,8 MB, deklaruje piętnaście zależności przypiętych co do wersji, w tym esbuild w wersji 0.28.0 i czternaście parserów WebAssembly. Te parsery wyraźnie zostają w tyle za samym narzędziem: windmill-parser-wasm-py jest w wersji 1.782.0, windmill-parser-wasm-ts w 1.695.0, a windmill-parser-wasm-csharp, -java i -nu w 1.510.1. Nie jest to błąd, tylko skutek publikowania parsera dopiero wtedy, gdy się zmienia, ale audyt zależności pokaże tu piętnaście różnych numerów wersji dla jednej rodziny pakietów.

W paczce npm jest jedna niezgodność. Pole license w rejestrze ma wartość Apache 2.0, która nie jest poprawnym identyfikatorem SPDX, a jedyny dołączony plik licencyjny to nie tekst Apache, tylko wspomniany rozdzielnik z korzenia repozytorium. Samo narzędzie mieści się w duchu klientów na Apache 2.0, ale rozdzielnik nie wymienia katalogu cli/ wprost. Automat zbierający metadane opisze ten pakiet jako Apache 2.0 i nie zauważy, że dołączony plik mówi o trzech licencjach naraz.

Klient pythonowy wmill w PyPI jest w wersji 1.795.0, ma pole licencji Apache-2.0, jedyną zależność httpx>=0.24 i żadnego wydania wycofanego. Obraz buduje się na rust:1.97-slim-trixie i node:24-alpine. Paczka npm nie deklaruje pola engines, więc menedżer pakietów nie ostrzeże cię przy starym Node.

Gdzie żyje kod i jak go wersjonować

Skrypty, przepływy i aplikacje żyją w bazie Windmilla, nie w repozytorium. To ta sama sytuacja, którą opisywaliśmy przy Knocku: logika biznesowa poza repozytorium oznacza brak przeglądu zmian, brak historii obwiniania i brak wycofania zmiany przez cofnięcie zatwierdzenia. Windmill trzyma wersje obiektów w bazie i pozwala wrócić do poprzedniej, ale to jest historia w panelu, a nie w Gicie.

Wyjściem jest narzędzie wierszowe. Działa przeciwko dowolnej instancji, również społecznościowej.

npm install -g windmill-cli
wmill workspace add
wmill init

# pobranie całej przestrzeni roboczej do katalogu bieżącego
wmill sync pull --yaml

git add . && git commit -m "stan przestrzeni roboczej przed zmianą"

# wypchnięcie zmian z katalogu z powrotem na instancję
wmill sync push

# uruchomienie pojedynczego skryptu z danymi wejściowymi
wmill script run u/alice/cleanup --data '{"days": 30}'

Zachowanie synchronizacji opisuje plik wmill.yaml w korzeniu katalogu. Nazwy pól poniżej pochodzą z rozpakowanej paczki 1.795.0.

defaultTs: bun
includes:
  - f/**
excludes:
  - f/scratch/**
skipVariables: false
skipResources: false
skipSecrets: true
skipScripts: false
skipFlows: false
skipApps: false
includeUsers: false
includeGroups: false
includeSchedules: true
includeTriggers: true
gitBranches: {}

Kilka szczegółów z tego pliku. Brak pola defaultTs powoduje ostrzeżenie i przyjęcie bun jako domyślnego środowiska dla TypeScriptu. Pole syncBehavior niesie numer wersji zachowania synchronizacji, a narzędzie odmawia pracy, gdy plik żąda wersji nowszej, niż obsługuje, i każe wywołać wmill upgrade. Pole skipSecrets ustawione na prawdę jest rozsądnym stanem wyjściowym, bo inaczej wartości sekretów wylądują w katalogu roboczym. Sekcja gitBranches wiąże gałęzie z ustawieniami wypychania, a codebases obsługuje paczki budowane przed wysłaniem.

I tu wchodzi licencja, bo synchronizacja ma dwa kierunki i tylko jeden jest darmowy. Kierunek z repozytorium na instancję to zwykłe wywołanie narzędzia wierszowego w procesie ciągłej integracji i działa wszędzie. Kierunek odwrotny, czyli automatyczne wypychanie każdego wdrożenia z panelu do repozytorium, obsługuje funkcja handle_deployment_metadata, która w budowie bez flagi private nic nie robi i zwraca sukces. Moduł niepubliczny dokłada tam enqueue_git_pull_job, reconcile_and_enqueue_pull, persist_auto_pull_state i record_auto_pull_failure. Tabela cennika podaje przy tym, że w darmowym wariancie własnym synchronizacja z Gitem działa do dwóch użytkowników. Nie ma w tym sprzeczności, jest za to wniosek: ten darmowy limit istnieje w oficjalnym obrazie społecznościowym, w którym kod niepubliczny siedzi, a nie w pliku wykonywalnym zbudowanym z publicznych źródeł. Samego mechanizmu odcięcia po drugim użytkowniku nie da się przeczytać, bo jest w kodzie zamkniętym.

Praktyczny układ dla zespołu wygląda więc tak: przestrzeń robocza deweloperska do klikania, wmill sync pull do repozytorium jako źródło prawdy, przegląd zmian w zgłoszeniu i wmill sync push do przestrzeni produkcyjnej z procesu ciągłej integracji. Panel do wypychania zmian między przestrzeniami i widok wdrożenia na produkcję są w tabeli oznaczone jako płatne.

Cennik i limity

Strona cennika renderuje bez JavaScriptu wyłącznie zakładkę wariantu własnego. Tabela porównawcza w surowym kodzie ma identyfikatory tier-free-selfhost i tier-enterprise-selfhost, a zakładki wariantu chmurowego i białej etykiety nie pojawiają się w treści. Liczb dla planu chmurowego nie podaję, bo ich tam nie ma. Jedyny ślad po nim to dane strukturalne strony, które wymieniają ofertę o nazwie Team w cenie 10 dolarów za miejsce miesięcznie. Ta pozycja nie występuje nigdzie w widocznej części strony, a odpowiedź w sekcji częstych pytań mówi o planie Teams rozliczanym według faktycznego zużycia. Podaję obie postaci i zaznaczam rozbieżność.

Wariant darmowy do uruchomienia u siebie to edycja społecznościowa bez limitu liczby wykonań. Limity są gdzie indziej: trzy przestrzenie robocze, najwyżej pięćdziesięciu użytkowników, najwyżej cztery grupy, dziesięciu użytkowników z logowaniem jednokrotnym, 10 GiB przydziału na magazyn obiektów przestrzeni roboczej, przechowywanie szczegółów uruchomień do trzydziestu dni i sto wiadomości dziennie dla wyzwalacza pocztowego. Rozgałęzienia przestrzeni roboczych i przestrzenie deweloperskie wliczają się do limitu trzech. Poza zasięgiem zostają dzienniki audytu, autoskalowanie, workery agentowe, limity współbieżności, workery dedykowane, zewnętrzne magazyny sekretów i wyzwalacze na Kafce, NATS, SQS, GCP oraz Azure.

Płatna edycja rozlicza się z dwóch rzeczy naraz. Miejsca kosztują 20 dolarów miesięcznie za programistę i 10 dolarów za operatora, czyli użytkownika, który może uruchamiać skrypty, przepływy i aplikacje, ale ich nie tworzy. Każdy unikalny użytkownik uwierzytelniany zewnętrznym tokenem JWT liczy się tak samo jak operator, przy czym unikalność liczona jest według trójki nazwa lub adres pocztowy, zakres i instancja, z aktywnością w ostatnich trzydziestu dniach. Druga oś to jednostki obliczeniowe po 50 dolarów miesięcznie. Jedna jednostka to dwa gigabajty pamięci workera przez miesiąc. Worker o dwóch gigabajtach to jedna jednostka, worker o pamięci większej niż dwa gigabajty w wariancie własnym to dwie, minimalne rozliczenie na workera to pół jednostki, a worker natywny zawsze liczy się jako jedna jednostka niezależnie od pamięci. Ośmiu podworkerów natywnych to jedna jednostka.

Arytmetyka domyślnej symulacji na stronie zgadza się co do centa: jeden programista za 20 dolarów, dwa standardowe workery po dwa gigabajty jako dwie jednostki za 100 dolarów i osiem podworkerów natywnych jako jedna jednostka za 50 dolarów daje trzy jednostki i sumę 170 dolarów miesięcznie. Karta oferty nad symulatorem mówi jednak o cenie od 120 dolarów miesięcznie. Ta kwota odpowiada jednemu programiście i dwóm jednostkom, ale strona nigdzie tego nie wyjaśnia, więc traktuję 120 dolarów jako deklarowany próg wejścia, a 170 jako wynik konfiguracji domyślnej. Obie liczby pochodzą z tej samej strony.

Definicja wykonania przydaje się przy porównaniach: to pojedyncze zadanie trwające krócej niż sekundę, każda kolejna sekunda liczy się jako następne wykonanie, a wykonanie przepływu jest sumą kroków. Zadanie dostaje jeden rdzeń wirtualny i dwa gigabajty pamięci. Po przekroczeniu wykupionych warunków klucz licencyjny nie gaśnie natychmiast: dostajesz trzydzieści pięć dni na uporządkowanie sprawy, zanim wygaśnie. Zużycie raportowane jest telemetrią, przy czym jednostki obliczeniowe liczone są tylko z instancji oznaczonych jako produkcyjne, a miejsca z wszystkich instancji, z użytkownikiem liczonym raz. Plan Pro jest dostępny dla osób prywatnych, firm poniżej dziesięciu pracowników i 250 tysięcy dolarów przychodu oraz startupów na wczesnym etapie, wyłącznie w wariancie własnym, a organizacje pozarządowe i uczelnie mają 60 procent zniżki od ceny edycji płatnej. Płatności obsługuje Stripe. Na pytanie o zamknięcie firmy dostawca odpowiada, że klucze zostaną przedłużone bezterminowo, a instancja działa bez połączenia z internetem tak długo, jak klucz jest ważny.

Windmill a alternatywy

Sensowny podział wygląda tak. n8n wygrywa, gdy zadanie polega na przeklikaniu integracji między gotowymi usługami i nikt nie chce pisać kodu. Temporal wygrywa, gdy proces trwa dniami, ma stan i wymaga gwarancji odtworzenia po awarii, a kod ma zostać w twojej aplikacji. Inngest i Trigger.dev wygrywają, gdy potrzebujesz kolejki zadań w tle dla aplikacji, którą już masz, i nie chcesz osobnego portalu. Retool wygrywa, gdy panel dla działu operacyjnego jest celem samym w sobie, a zamknięte źródło nie przeszkadza. Prefect jest bliżej Windmilla w warstwie orkiestracji, ale celuje w potoki danych i nie generuje interfejsu dla użytkownika końcowego.

Windmill mieści się w luce między tymi światami: kod pisze programista, ale uruchamia go i ogląda ktoś inny, przez formularz albo panel, a całość da się postawić na własnym serwerze obok pozostałych usług, choćby przez Dokploy. Cena tego układu jest jedna i konkretna: kod domyślnie mieszka w cudzej bazie danych i trzeba świadomie zorganizować jego drogę do repozytorium.

Typowe błędy

Pierwszy to założenie, że oficjalny obraz jest na AGPLv3. Nie jest. Zawiera kod niepubliczny i podlega własnym warunkom edycji społecznościowej, które zabraniają modyfikowania i opakowywania. Jeśli twój dział prawny zaakceptował AGPLv3, a wdrożenie idzie z obrazu, zaakceptował coś innego.

Drugi to liczenie na synchronizację z Gitem w pliku wykonywalnym zbudowanym z publicznych źródeł. Funkcja obsługująca wdrożenie zwraca tam sukces i nie robi nic, bez żadnego błędu w dzienniku.

Trzeci to planowanie wyzwalaczy na Kafce, NATS lub SQS w wariancie darmowym. Te flagi należą do grupy ee_core i w edycji społecznościowej ich nie ma, co potwierdza tabela cennika.

Czwarty to zderzenie z limitem trzech przestrzeni roboczych. Rozgałęzienia przestrzeni i przestrzenie deweloperskie wliczają się do tej samej trójki, więc układ z podziałem na rozwój, testy i produkcję zajmuje cały limit i nie zostaje nic na eksperymenty.

Piąty to przypięcie znacznika main w produkcji. Przy dziewięciu wydaniach w osiem dni instancja aktualizuje się przy każdym ponownym pobraniu obrazu. Przypnij dokładny numer wydania i podnoś go świadomie.

Szósty to poleganie na dziennikach audytu przy ustalaniu, kto co wdrożył. W edycji społecznościowej ich nie ma, a szczegóły uruchomień znikają po trzydziestu dniach. Jeśli nie masz synchronizacji z Gitem, nie masz też historii zmian.

Siódmy to przepuszczenie pola license paczki npm przez automat licencyjny bez zaglądania do pliku. Pole mówi Apache 2.0, a dołączony plik opisuje trzy licencje naraz, w tym własnościową.

Ósmy to pobranie przestrzeni roboczej bez skipSecrets. Wartości sekretów trafią do katalogu roboczego, a stamtąd łatwo do repozytorium.

FAQ

Czy używając oficjalnego obrazu Docker jestem na AGPLv3?

Nie. Rozdzielnik w repozytorium mówi wprost, że edycja społecznościowa z obrazów pod ghcr.io/windmill-labs/windmill i z wydań binarnych na GitHubie zawiera także kod niepubliczny i własnościowy. Warunki są wtedy własne: użycie wszystkich funkcji za darmo w granicach limitów zaszytych w programie oraz rozpowszechnianie w postaci niezmienionej, bez prawa do sprzedaży, odsprzedaży, oferowania jako usługi zarządzanej, modyfikowania i opakowywania. Czyste AGPLv3 dostajesz dopiero, kompilując samodzielnie bez flag enterprise i private.

Czy muszę udostępniać kod moich skryptów i przepływów?

Nie. Skrypty i przepływy to twoje dane uruchamiane na platformie, a nie dzieło zależne od serwera. Biblioteki klienckie w katalogach python-client/, deno-client/, go-client/ i powershell-client/ są na Apache 2.0 właśnie po to, żeby ich import nie wciągał copyleftu. Obowiązek z sekcji 13 licencji AGPLv3 dotyczy zmodyfikowanego kodu samego serwera i tylko wobec osób, które korzystają z niego przez sieć.

Czy synchronizacja z Gitem działa w wersji darmowej?

W oficjalnym obrazie społecznościowym tak, z limitem dwóch użytkowników podanym w tabeli cennika. W pliku wykonywalnym zbudowanym z publicznych źródeł bez flagi private nie działa wcale, bo funkcja handle_deployment_metadata jest tam zaślepką zwracającą sukces. Kierunek odwrotny, czyli wypychanie z repozytorium na instancję poleceniem wmill sync push, działa zawsze.

Ile kosztuje płatna edycja dla dwóch programistów i jednego workera?

Według cennika miejsc i jednostek wychodzi 40 dolarów za dwa miejsca programistyczne plus 50 dolarów za standardowy worker o dwóch gigabajtach, czyli 90 dolarów miesięcznie. Karta oferty mówi jednak o cenie od 120 dolarów miesięcznie i nie wyjaśnia, czy jest to próg minimalny. Traktuj 120 dolarów jako kwotę wyjściową do rozmowy i potwierdź ją u dostawcy.

Jak sprawdzić, czy mój plik wykonywalny zawiera kod własnościowy?

Nie ma punktu końcowego wypisującego listę flag kompilacji, więc sprawdza się to pośrednio. Wpisanie klucza licencyjnego kończy się błędem, gdy brakuje flagi private. Start w trybie agenta kończy się paniką, gdy brakuje flagi enterprise. Indekser wyszukiwania pełnotekstowego zgłasza brak biblioteki tantivy i odsyła do obrazu płatnego. Najpewniejszym źródłem pozostaje polecenie, którym budowałeś, czyli zawartość --features.

Kiedy Windmill nie jest właściwym wyborem?

Gdy potrzebujesz procesów trwających dniami z pełną gwarancją odtworzenia stanu, bo to obszar Temporala. Gdy chcesz, żeby logika została w repozytorium aplikacji i nie było osobnego portalu, bo wtedy lepsza jest kolejka zadań. Gdy nikt w zespole nie pisze kodu, bo edytor graficzny da tam więcej. I gdy planujesz sprzedawać produkt zbudowany na cudzym obrazie, bo warunki edycji społecznościowej tego zabraniają.

Kod źródłowy i rozdzielnik licencyjny znajdziesz w repozytorium na GitHubie, a warunki płatne oraz symulator na stronie cennika.