O czym jest ten film
- Dlaczego lokalne modele „nie umieją kodować”: winne jest środowisko, w którym pracują — Claude Code wstawia do okna kontekstu około 20 tysięcy tokenów (prompt systemowy Anthropic i narzędzia wewnętrzne), zanim wyślesz pierwszą wiadomość.
- Każdy model — także flagowy — zaczyna głupieć po zapełnieniu 50–70% okna kontekstu; darmowe modele lokalne mają go zwykle tylko około 120 tysięcy tokenów, więc każda strata jest bolesna.
- Darmowym modelom brakuje sprawności w posługiwaniu się narzędziami: nadmiar funkcji je gubi. Rozwiązaniem jest „chudy” harness, czyli minimalna otoczka narzędziowa.
- Pi Agent SDK to właśnie taka otoczka: agent może zaledwie przeglądać i edytować pliki w folderze projektu; MCP, skills i wyszukiwanie w sieci dochodzą opcjonalnie, z rynku wtyczek.
- Instalacja jest prosta: Pi przez NPM z pi.dev, Ollama z ollama.com, a jako model do kodowania autor poleca Qwen 3.6 (27B — ok. 16 GB VRAM; 35B — ok. 24 GB VRAM).
- Modele lokalne podpina się ręcznie w pliku models.json (katalog .pi/agent) — to jedyny „techniczny” moment całego poradnika.
- Reguły projektu trzymamy w pliku AGENTS.md i podpinamy nim system designu (design.md), bo lokalnym modelom brakuje wyobraźni do samodzielnego projektowania.
- System designu łatwiej wygenerować z obrazu: szablon z Dribbble wrzucamy do ChatGPT, Claude albo darmowego Google Stitch.
- Serce metody: szczegółowy plan implementacji tworzymy mocnym, darmowym modelem chmurowym, dzielimy na pojedyncze funkcje i wdrażamy po kolei, czyszcząc kontekst po każdym kroku.
- Gotową stronę statyczną publikujemy na Hostingerze przez migrację z pliku zip i tak samo ją aktualizujemy.
10 najważniejszych takeaways — z kontekstem zastosowania
1.To nie model zawodzi, tylko przeładowana otoczka
Na czym polega: Samo otwarcie Claude Code zjada ok. 20 tysięcy tokenów kontekstu — a użytkownik nie ma na to żadnego wpływu. Dla modelu lokalnego ze 120 tysiącami tokenów to spalenie co szóstego tokena, zanim jakakolwiek praca się zacznie.
Jak stosować: Zanim obwinisz model, policz, ile kontekstu pochłania samo środowisko agentowe. Wybieraj lekkie otoczki (Pi Agent SDK, OpenCode) i pilnuj, żeby sesje były krótkie.
Na co uważać: Niektóre narzędzia nie pokazują wprost, ile tokenów pochłania prompt systemowy i definicje narzędzi — zakładaj, że ta „ukryta opłata” zawsze istnieje i jest spora.
2.Model głupnie po przekroczeniu 50–70% okna kontekstu
Na czym polega: Degradacja jakości przy dużym zapełnieniu kontekstu dotyczy wszystkich modeli, również flagowych. U lokalnych modeli ten moment przychodzi wyjątkowo szybko.
Jak stosować: Trzymaj instrukcje zwięzłe, często zaczynaj świeże sesje (w Pi służy do tego /new) i pracuj małymi porcjami zamiast jednej długiej rozmowy.
Na co uważać: Wrzucenie do czatu wielkiego dokumentu (np. planu na ponad tysiąc linii) to najpewniejszy sposób, żeby wejść w strefę degradacji.
3.Darmowym modelom trzeba dać mniej narzędzi, nie więcej
Na czym polega: Lokalne modele nie mają sprawności flagowych siatek w wywoływaniu narzędzi. Gdy mają do wyboru dziesiątki funkcji, gubią się i przestają wiedzieć, co robić.
Jak stosować: Zacznij od absolutnego minimum — w Pi to podgląd i edycja plików w folderze projektu. Każde rozszerzenie (dostęp do sieci, adapter MCP) dokładaj dopiero wtedy, gdy konkretny krok pracy go realnie wymaga.
Na co uważać: Każda wtyczka to dodatkowe tokeny w kontekście i dodatkowa szansa na pomyłkę. „Wolniejszy, ale przewidywalny” agent wygrywa z „sprawnym, ale zbitym z tropu”.
4.Plan pisz mocnym modelem chmurowym, wdrażaj lokalnym
Na czym polega: Jakość planu implementacji decyduje o jakości wyniku. Z bardzo szczegółowym planem nawet słaby model daje dobre efekty; z lipnym planem nie uratuje cię żadna sieć.
Jak stosować: Do wygenerowania planu użyj ChatGPT albo Claude — wystarczy darmowy plan. Warto użyć gotowego promptu z materiału: sekwencja funkcji do wdrożenia pojedynczo, poziom szczegółowości „zrozumiały dla młodszego programisty”, wynik w Markdownie.
Na co uważać: Nie oszczędzaj akurat na etapie planowania — to najgorsze możliwe miejsce na używanie słabego modelu.
5.Wielki plan dziel na funkcje i wdrażaj po jednej
Na czym polega: Plan na 1364 linie nie zmieści się w oknie kontekstu lokalnego modelu. Trzeba go rozbić na małe pliki funkcji w logicznej kolejności, z uwzględnieniem zależności między nimi.
Jak stosować: Wciągnij plan do agenta i poproś o podział na numerowane funkcje (np. „01 — fundament”), z poleceniem przemyślenia zależności. Potem: czysta sesja, pierwszy plik, polecenie „wdroż to”, test; po zakończeniu — znów czysta sesja i kolejny plik.
Na co uważać: Nie ulegaj pokusie wdrożenia całego planu naraz ani pomijania testów między krokami — po kilku funkcjach stracisz orientację, co dokładnie się zepsuło.
6.AGENTS.md jako trwała pamięć projektu
Na czym polega: To plik z regułami, który agent czyta na starcie sesji. Wpisujesz tam zasady dotyczące stylu, interfejsu czy stacku i podpinasz odniesienia do plików, np. systemu designu.
Jak stosować: W katalogu projektu stwórz AGENTS.md i dopisuj reguły, które mają obowiązywać stale, a nie tylko w jednej rozmowie. Do konkretnych dokumentów odwołuj się przez @.
Na co uważać: Plik też zajmuje kontekst — zamiast stu drobiazgowych poleceń lepiej podpiąć jeden zwięzły dokument i dbać o jego porządek.
7.System designu wygeneruj obok, nie lokalnym modelem
Na czym polega: Lokalnym modelom brakuje pomysłowości w tworzeniu systemów designu od zera — wyprodukują coś poprawnego, ale mdłego.
Jak stosować: Znajdź szablon na Dribbble, skopiuj obraz i każ ChatGPT, Claude albo Google Stitch (w pełni darmowy) zbudować na jego podstawie system designu. Gotowy plik design.md wrzuć do projektu i podpnij w AGENTS.md.
Na co uważać: Jakość wyniku zależy od jakości wzorca — zrzut ekranu od grafika klienta zadziała lepiej niż przypadkowy obrazek z sieci. Pobrany plik zwykle wymaga drobnych korekt.
8.Modele lokalne rejestruje się ręcznie w models.json
Na czym polega: Pi samo nie wykryje Ollamy ani LM Studio — trzeba dodać wpisy w pliku models.json w katalogu .pi/agent w folderze domowym użytkownika.
Jak stosować: Jeden wpis JSON odpowiada jednemu modelowi. Kolejne dodajesz, kopiując istniejący wpis i zmieniając nazwę modelu. W filmie autor udostępnia swój gotowy plik do pobrania.
Na co uważać: Literówka w nazwie modelu albo błąd składni w JSON sprawi, że model nie pojawi się na liście /model — bez żadnego komunikatu o błędzie.
9.Na małych modelach unikaj autonomicznych trybów typu „goal”
Na czym polega: Pi ma rozszerzenie Goal, znane z Claude Code i Codexa, które pozwala zlecić agentowi dłuższy cel do samodzielnego realizowania. Niestety główny wątek rozmowy i tak zapełnia się błyskawicznie.
Jak stosować: Zamiast autonomii — rytm ręczny: jedna funkcja, wdrożenie, test, czysty kontekst, następna funkcja. Brzmi żmudnie, ale właśnie dlatego działa.
Na co uważać: Pokusa „niech zrobi wszystko sam” kończy się na modelu brodzącym we własnym kontekście — czyli dokładnie tam, skąd wanted uciec.
10.Stronę statyczną publikujesz i aktualizujesz przez zip
Na czym polega: Gotowy serwis HTML trafia na hosting przez funkcję migracji: pliki do folderu public_html, spakowanie do zipa, wgranie. Aktualizacja to ten sam obieg od nowa.
Jak stosować: Po każdej zmianie w projekcie odśwież zip, wróć do panelu hostingu i ponów migrację — nowe pliki zastąpią stare. Dla Reacta/Next.js wybierz hosting z Node.js i spakuj pliki nieco inaczej.
Na co uważać: Adres tymczasowy wystarczy do testów, ale dla klienta potrzebujesz własnej domeny; w prezentowanym hostingu pierwsza jest darmowa przez rok (a kod od twórcy daje dodatkowy rabat).
Redakcyjne tłumaczenie
Wszystko zależy od otoczki, nie od modelu
Wszyscy powtarzają, że lokalne modele nie nadają się do prawdziwego programowania. Pobierasz taki model, podpinasz go do Claude Code — i po chwili wszystko się sypie. Prawda, o której nikt nie mówi, jest inna: problemem nie jest model, tylko harness, czyli otoczka narzędziowa, w której model pracuje.
Wystarczy uruchomić Claude Code, a do okna kontekstu trafia około 20 tysięcy tokenów, zanim wyślesz choć jedną wiadomość. Nie masz na to żadnego wpływu — to systemowy prompt Anthropic oraz wewnętrzne narzędzia samego Claude Code. Do tego nie wliczono jeszcze MCP ani skills. (Informacja dodatkowa: MCP, czyli Model Context Protocol, to otwarty standard podłączania zewnętrznych narzędzi i źródeł danych do modeli językowych; „skills” to pakiety instrukcji rozszerzające możliwości agenta.)
Rozwiązanie jest takie: darmowe modele lokalne trzeba uruchamiać w lekkiej otoczce. W tym materiale przyjrzymy się Pi Agent SDK i przejdziemy przez cały obieg pracy, dzięki któremu można niezawodnie budować oprogramowanie na darmowych modelach.
„Strefa głupienia”, czyli matematyka okna kontekstu
Zacznijmy od ograniczeń. Te modele działają na twoim sprzęcie: ładują się do VRAM — pamięci karty graficznej — i mieszczą ograniczoną liczbę tokenów, zwykle około 120 tysięcy, w większych wariantach do 200 tysięcy. Jeśli otoczka typu Claude Code sama zajmuje 20–30 tysięcy tokenów, błyskawicznie trafisz w strefę, w której model po prostu głupieje.
I to nie jest bolączka tanich siatek — dotyczy wszystkich modeli, również flagowych konstrukcji Anthropic i OpenAI. Po przekroczeniu pewnego progu zapełnienia okna kontekstu, zwykle między 50 a 70 procent, inteligencja i jakość odpowiedzi zaczynają spadać. Dlatego zaleca się, by instrukcje w sesji były maksymalnie zwięzłe i na temat; nie chcemy w ogóle zbliżać się do przepełnienia kontekstu. Model darmowy, dysponujący ledwie 120 tysiącami tokenów, nie może pozwolić sobie na spalenie 30% tego budżetu na samą otoczkę.
Jest jeszcze jedna rzecz, kluczowa przy pracy z darmowymi modelami: one szybko się gubią i dają się przytłoczyć. Po prostu nie mają sprawności flagowych siatek w wywoływaniu narzędzi ani w rozumowaniu. A skoro Claude Code daje agentowi całą masę narzędzi, taki agent traci głowę i przestaje wiedzieć, co właściwie ma robić. Stąd pomysł na chudy harness — Pi Agent SDK albo OpenCode, o którym opowiadałem w poprzednim materiale. Takie otoczki wstrzykują minimalny zestaw narzędzi potrzebnych agentowi kodującemu. W przypadku Pi to dosłownie garść funkcji: agent może wyłącznie wyszukiwać pliki i wprowadzać zmiany w konkretnym folderze. Natywnie nie obsługuje MCP, skills, wyszukiwania w sieci ani niczego innego, co nadyma kontekst. Każdą z tych możliwości możesz jednak samodzielnie dobudować z rynku wtyczek. Idea jest prosta: dostajesz szybki, odchudzony harness i sam decydujesz, jakie obciążenie do niego dopakujesz.
Instalacja: Pi i Ollama
Zabieramy się do roboty. Wejdź na pi.dev, wybierz instalację przez NPM, skopiuj polecenie, a potem uruchom je w wierszu poleceń — PowerShell, terminal, cokolwiek używasz. Gdy się skończy, sprawdź, czy wszystko gra, wpisując polecenie pi. Powinien pokazać się interfejs czatu.
Żeby uruchomić model lokalnie, instalujemy Ollamę. Wchodzimy na ollama.com, klikamy pobieranie, wybieramy system operacyjny i instalujemy. Sprawdzamy komendą ollama — jeśli zobaczysz menu, znaczy, że zadziałało. Zostaje jeszcze pobranie samego modelu.
Moja rada: wejdź do ChatGPT albo Claude i każ przeprowadzić mały research, które modele da się sensownie uruchomić na twoim sprzęcie. Ja jestem wielkim fanem Qwen 3.6 — moim zdaniem to obecnie najlepszy bazowy model do kodowania, który zmieścisz na własnej maszynie. Występuje w dwóch wariantach: 27 miliardów parametrów (potrzebne około 16 GB VRAM) albo 35 miliardów (około 24 GB VRAM). Kopiujesz nazwę modelu, wracasz do terminala i uruchamiasz ollama pull z tą nazwą.
Test jest equally prosty: ollama run plus nazwa modelu, a potem zwykłe „hej”. Odpowiedź streamuje na ekran — czyli działa.
Podpięcie modeli: plik models.json
Na ten moment otwieram VS Code w pustym folderze projektu, w terminalu uruchamiam pi i poleceniem /model przechodzę do konfiguracji dostawców i modeli. U ciebie lista może być pusta — ale jeśli korzystałeś z Gemini, Codexa czy Claude Code, zobaczysz na niej już kilka pozycji. Nas interesują modele lokalne.
To jedyny krok w całym materiale, który może sprawiać wrażenie technicznego — ale naprawdę nie ma dramatu, po prostu idź za instrukcją. W katalogu domowym użytkownika (na Windowsie: folder Users) znajduje się ukryty katalog .pi, w nim katalog agent, a w nim plik models.json. Jeśli pliku nie ma, po prostu go utwórz. Dla wygody otwieram ten katalog w VS Code. Plik startowo jest pusty; żeby dodać modele z Ollamy albo LM Studio — jeśli wolisz to narzędzie do lokalnego wnioskowania — wklejasz odpowiednią konfigurację. Gdy w przyszłości dojdziesz do kolejnych modeli, wracasz do tego pliku: w tablicy models kopiujesz istniejący wpis i podstawiasz nazwę kolejnej sieci. Z LM Studio sprawa wygląda identycznie — realnie chodzi tylko o zmianę nazwy modelu. Mój plik możesz pobrać z opisu filmu; podlinkowałem go w darmowej społeczności.
W Pi uruchamiam /model, wyszukuję Qwen 3.6 — bo skonfigurowałem go i w Ollamie, i w LM Studio, widzę dwie pozycje. Wybieram Ollamę, piszę „hej” i, jeśli wszystko poszło dobrze, dostaję odpowiedź.
Przy okazji trzy komendy na przyszłość: /new czyści okno kontekstu i rozpoczyna nową sesję — będziemy tego często używać — a /quit wyłącza agenta.
Pamięć projektu: AGENTS.md i system designu
Agent Pi obsługuje też pliki pamięci. W folderze projektu tworzę AGENTS.md i wpisuję dowolne reguły projektu — na próbę: „odpowiadaj jak pirat”. Restartuję agenta, piszę „hej” i faktycznie: odpowiedź przychodzi w pirackim stylu. Ale dopiszmy coś użyteczniejszego — sekcję o interfejsie i stylistyce z zasadą „zawsze stosuj niniejszy system designu” oraz odniesienie do pliku design.md. Ten plik tworzę w katalogu głównym projektu i będzie w nim właśnie system designu: typografia, kolory, odstępy, zaokrąglenia ramek — wszystko, czego potrzebujemy do budowy strony. Jeśli robisz strony dla klientów, warto zebrać od nich te informacje i trzymać właśnie w takim miejscu. (Informacja dodatkowa: AGENTS.md to plik z wytycznymi dla agentów kodujących, czytany automatycznie na początku każdej sesji — wspiera go coraz więcej narzędzi tego typu.)
Przy okazji: jeśli dopiero wchodzisz w temat systemów designu, mam na to pełny kurs — od podstaw, przez pracę z platformami takimi jak Stitch, aż po zbudowanie „egzekutora” systemu designu, który pilnuje zgodności projektu z regułami niezależnie od tego, jak duży jest kod i czy powstaje od zera, czy na istniejącej bazie. Kurs znajdziesz w Agendik Labs, link zostawiam w opisie.
Wróćmy do pracy. Plik wciągasz do rozmowy metodą przeciągnij-i-upuść albo oznaczasz go w czacie małpą. I proszę: „Stwórz system designu dla restauracji”. Jeśli kiedykolwiek używałeś Claude Code, różnicę poczujesz natychmiast — ta otoczka jest tak lekka, że agent po prostu śmiga. Gotowe. Przeglądam wygenerowany system designu i wycinam zbędne elementy. A ponieważ plik jest podpięty w pamięci projektu, agent powinien z niego rzeczywiście korzystać. Sprawdźmy: nowa sesja, polecenie „Stwórz landing page dla restauracji The Oak and Barrel”. Agent melduje, że ma już pełne rozeznanie systemu designu — i bierze się do strony. Po chwili jest gotów. Wynik? Całem niezły, łatwy do poprawek, z subtelnymi animacjami przy przewijaniu.
Skąd wziąć ładny system designu
Tu jednak szczera uwaga: lokalne modele nie grzeszą pomysłowością przy tworzeniu systemów designu od zera. Kretywności po prostu im brak. Dlatego praktyczna rada: wejdź na Dribbble, poszukaj szablonu, znajdź coś, co ci się podoba, skopiuj obraz i każ ChatGPT albo Claude zbudować system designu na jego podstawie — a potem pobierz wygenerowany plik do projektu. Całkowicie darmową alternatywą jest Google Stitch: wklejasz tam obraz, prosisz o system designu na jego podstawie, wybierasz platformę web i model 3.1 Pro, wysyłasz — i po chwili dostajesz gotowy zestaw, który pobierasz i przenosisz do folderu projektu. Masz więc kilka dróg do celu: jeśli grafik podał ci zrzut ekranu projektu, wystarczy wrzucić go do Stitch i wygenerować system na jego podstawie.
Wtyczki: dokładaj tylko to, czego naprawdę potrzebujesz
Mamy projekt i system designu, więc naturalnym odruchem byłoby teraz doinstalowanie skills albo serwerów MCP. Domyślnie Pi nie obsługuje żadnych z nich. Zobaczcie, jak to wygląda: pytam „Co nowego u OpenAI?”. W Claude Code czy Codexie model po prostu wywołałby narzędzie wyszukiwania i sięgnął do internetu. Pi odpowiada: „Nie mam dostępu do internetu w czasie rzeczywistym”. I to jest zabieg celowy — harness jest chudy z założenia, a rozszerzenia dobierasz sam, w sekcji z pakietami. Można tam filtrować wg popularności i znajdziesz wtyczki praktycznie do wszystkiego: pi web access, pi subagents czy adapter MCP, który pozwoli agentowi wywoływać narzędzia MCP.
Skoro chcemy dać agentowi dostęp do sieci, wchodzimy w pi web access, kopiujemy polecenie instalacyjne i uruchamiamy je w terminalu. Wracam do agenta, zaczynam nową sesję i zadaję to samo pytanie o nowości z OpenAI. Tym razem agent dysponuje już narzędziem wyszukiwania — sam otwiera stronę i przygotowuje krótki dokument z researchu, który możemy zatwierdzić przyciskiem approve. Całkiem fajne, prawda?
Ale zasada pozostaje ta sama: trzymamy się zwięzłości. Dlatego nie będę dokładał ani skills, ani narzędzi MCP.
Plan implementacji — najważniejszy element całego obiegu
Teraz najważniejsza część i zarazem poważne ostrzeżenie. Na tym etapie powinno się stworzyć szczegółowy plan implementacji strony — i to on jest sercem całej metody. Jeśli plan jest słaby, wynik będzie słaby. I odwrotnie: z naprawdę szczegółowym planem możesz pracować na bardzo słabym modelu i wciąż wygrywać dobrym efektem końcowym. Dlatego powiem wprost: planu nie generuj modelem lokalnym. Użyj do tego ChatGPT albo Claude — w zupełności wystarczy darmowy plan taryfowy.
W ChatGPT wpisuję więc coś w stylu: „Stwórz szczegółowy plan implementacji. Plan musi zawierać logiczną sekwencję funkcji, które programista może wdrażać pojedynczo, aby dojść do finalnego rezultatu. Powinien być na tyle szczegółowy, żeby poradził sobie z nim młodszy programista. Zwróć wynik jako markdown”. Następnie opisuję stronę, którą chcę zbudować: serwis restauracji The Oak and Barrel, specjalizującej się w stekach, burgerach, winie i piwie kraftowym.
Gotowy plan zabieram do projektu: tworzę folder plans, a w nim plik implementation-plan.md. To potężny dokument — w moim przypadku 1364 linie.
Dzielenie planu na funkcje i praca krok po kroku
Kuszące jest wrzucić taki plik w całości do czatu i kazać go wdrożyć. Ale pamiętaj o tym, o czym mówiliśmy na początku — o strefie, w której model głupieje. Dokument tej wielkości daleko przekroczy okno kontekstu agenta. Robimy więc inaczej: wciągamy plik i prosimy: „Potrzebuję, żebyś podzielił ten duży plan implementacji na pojedyncze funkcje. Funkcje mają tworzyć logiczną sekwencję, na przykład 01 — fundament itd. Programista powinien móc zbudować całe rozwiązanie, wdrażając funkcje po kolei. Starannie rozważ zależności między funkcjami”.
Uruchamiam — i wielki plan rozpada się na mniejsze, poręczne kawałki, z którymi da się pracować. W tym momencie mam komplet plików, które mogę wdrażać sekwencyjnie, aż powstanie cała strona. I tu implementacja staje się banalna: czyszczę okno kontekstu, wciągam pierwszy plik i piszę po prostu „wdroż to”. Gdy agent skończy, znowu czysta sesja, kolejny plik, „proszę wdrożyć tę funkcję” — i tak w kółko, aż do końca.
Przy okazji jedna uwaga: jeśli nie chcesz robić wszystkiego ręcznie tak jak ja teraz, Pi ma rozszerzenie Goal. Jeśli przywykłeś do podobnych poleceń w Claude Code czy Codexie, skonfigurujesz je również tutaj. Osobiście odradzam je jednak przy małych modelach — główny wątek rozmowy i tak zapełnia się błyskawicznie. Lepiej skupić się na wdrażaniu i testowaniu jednej funkcji naraz.
U mnie krokiem numer 15 jest pobieranie zdjęć stockowych z Pexelsa. I właśnie dlatego wcześniej instalowaliśmy dostęp do sieci — agent sam wyszukuje obrazy i je pobiera. Oczywiście możesz też zrobić to ręcznie: szukasz na Pexelsie burgerów, restauracji, czegokolwiek, wybierasz zdjęcie w odpowiedniej rozdzielczości, pobierasz, dodajesz do projektu i każesz agentowi użyć konkretnego pliku.
Efekt
Agent melduje zakończenie pracy — i oto wynik. U góry nawigacja; w widoku mobilnym strona jest faktycznie responsywna: przyciski układają się jeden pod drugim, a górne menu zamienia się w hamburger. Niżej zdjęcia stockowe, czysty design z drobnymi animacjami — i wszystko wygląda na sprawne. Klikamy „zobacz pełne menu” i trafiamy na kartę z pozycjami i cenami, z przyciskami filtrującymi konkretne kategorie.
Tą samą metodą możesz stronę bez końca doszlifowywać: coś do dodania? Tworzysz plan implementacji tej zmiany, dzielisz go na funkcje i podajesz agentowi pojedynczo. I robisz to wszystko za darmo, na lokalnym modelu, na własnej maszynie.
Publikacja na hostingu
Zostało nam wypuszczenie strony w świat. Hostingów jest mnóstwo, ale ja używam Hostingera — jest tani, niezawodny i konfiguracja trwa chwilkę; link zostawiam w opisie, jeśli chcesz iść tą samą ścieżką. Dla budujących strony dla klientów: na tym planie zmieścisz do 50 serwisów, a po podniesieniu taryfy nawet do 100; do tego domena jest darmowa przez pierwszy rok. Wybieramy plan i okres, po czym wpisujemy domenę — dla potrzeb demo coś w stylu oakandbarrelpi.com, z dopiskiem, że pierwszego roku nie zapłacimy ani grosza. Ja nie będę marnować domeny na demonstrację, więc ją usuwam. Niewielki bonus od mnie: po wpisaniu kodu „Leon hosting” dostajesz dodatkowe 10% zniżki. Dokańczamy zamówienie.
W panelu hostingu przechodzimy do zakładki ze stronami i dodajemy nową, wybierając „custom PHP and HTML website”. Gdybyś budował w Next.js albo Reakcie, wybrałbyś Node.js — my trzymaliśmy się prostoty, więc HTML. Podajemy domenę; ja użyję tymczasowej. Z menu strony wybieramy migrację, a potem opcję wgrania plików kopii. Najprościej otworzyć sobie folder projektu w eksploratorze. Proces wygląda trochę inaczej zależnie od stacku: dla Reacta czy Next.js pakujesz wszystkie pliki do zipa i wgrywasz bezpośrednio. Dla strony HTML takiej jak moja tworzysz folder public_html, przenosisz do niego pliki projektu — style CSS, obrazy, JavaScript, contact, index, menu — klikasz prawym przyciskiem i pakujesz folder do zipa, po czym wgrywasz go na hosting i przesyłasz żądanie. Migracja gotowa: dostajemy adres, pod którym strona jest dostępna z każdego miejsca na świecie. Jeśli przypiszesz własną domenę, po prostu wpisujesz ją zamiast adresu tymczasowego.
Utrzymanie jest równie proste. Po każdej zmianie w projekcie aktualizujesz zip, wracasz do opcji migracji na hostingu i przechodzisz ten sam proces od nowa — nowe pliki zastąpią stare.
Na koniec
Mam nadzieję, że materiał się przyda. Cała sztuka pracy z lokalnymi modelami sprowadza się do jednego: dać im otoczkę na tyle lekką, żeby wyniki były dobre. Jeśli masz pytania — śmiało, pisz w komentarzach. A jeśli chcesz więcej poradników o kodowaniu z agentami, subskrybuj kanał. Dziękuję za obejrzenie i do zobaczenia następnym razem.