title: 'Ktoś zainstalował koparkę bitcoina na moim VPS-ie. To był moment, w którym odpuściłem własny serwer.' excerpt: 'Zabezpieczyłem VPS-a najlepiej, jak umiałem — klucze SSH, fail2ban, firewall, automatyczne aktualizacje. A jednak ktoś się włamał. Ten tekst jest o tym, dlaczego przeniosłem bloga na AWS Amplify i zamieniłem utrzymywanie serwera na utrzymywanie konfiguracji.' featuredImage: '/images/featured/vps-bitcoin-miner-amplify.webp' date: '2026-05-14' publishDate: '2026-05-14T00:00:00Z' readTime: 8 tags: [ 'aws', 'architektura-frontendu', 'deployment', 'nextjs', 'lessons-learned', 'security', ]

Ktoś zainstalował koparkę bitcoina na moim VPS-ie. To był moment, w którym odpuściłem własny serwer.

Miałem VPS-a na OVH i zabezpieczyłem go najlepiej, jak frontend developer potrafi zabezpieczyć maszynę z Linuksem: SSH na niestandardowym porcie, logowanie tylko kluczem z długim hasłem, fail2ban, UFW z otwartymi tylko potrzebnymi portami i automatyczne aktualizacje bezpieczeństwa.

Nie była to tylko podstawowa lista z poradników typu „jak zabezpieczyć VPS-a”. Poszedłem krok dalej.

I to nadal nie wystarczyło.

Ktoś mimo wszystko się dostał i zainstalował koparkę kryptowalut. Nie dowiedziałem się o tym z monitoringu — bo monitoring pobocznego VPS-a to dokładnie ten typ rzeczy, który po cichu wypada z listy zadań. Dowiedziałem się, bo OVH napisało do mnie maila, że coś jest nie tak z moim serwerem: próbował włamywać się na inne instancje VPS i generował dużo podejrzanego ruchu.

To był ten nieprzyjemny moment.

Po mailu z OVH zacząłem skanować serwer, sprawdzać uruchomione procesy, podejrzane pliki i połączenia wychodzące. Wtedy znalazłem koparkę. Nie wiedziałem, jak długo tam była, co jeszcze zostało zmienione i czy po „posprzątaniu” tej maszyny mógłbym jej jeszcze kiedykolwiek zaufać.

To był moment, w którym zdecydowałem się przenieść bloga na AWS Amplify.

Nie ze względu na koszt.

Z prostszego powodu: serwer, który zabezpieczyłem najlepiej, jak potrafiłem, i tak został przejęty — a rzecz, której przestałem aktywnie pilnować, nie była już czymś, co chciałem dalej posiadać.

Prawdziwa lekcja nie brzmi: „AWS jest bezpieczniejszy”

Nie jest.

Źle skonfigurowane konto AWS może wyciec tak samo boleśnie jak źle skonfigurowany VPS. Czasami nawet boleśniej, bo rachunki skalują się razem z nadużyciem.

Lekcja jest inna: VPS to serwer, za który odpowiadasz. Amplify to platforma, która odpowiada za serwer.

Na VPS-ie odpowiadałem za aktualizacje systemu, konfigurację web servera, odnowienie SSL-a, reguły firewalla, klucze SSH, cron joby, o których zdążyłem zapomnieć, i koparkę kryptowalut, którą ktoś uprzejmie zainstalował za mnie.

Na Amplify odpowiadam za konfigurację buildu.

I to jest prawdziwa wymiana.

To nie jest wymiana „bezpieczeństwa”. To jest wymiana typu: za co realnie chcę być odpowiedzialny?

Dla frontend developera, który sam pracuje nad prywatnym projektem, druga lista jest po prostu lepszą odpowiedzią. Przez lata udawałem, że jestem półetatowym sysadminem.

Nie jestem.

Dlaczego nie Vercel — i dlaczego AWS

Oczywistym ruchem byłby Vercel. Albo Netlify. Albo Cloudflare Pages. Dowolna platforma, gdzie podpinasz repozytorium, klikasz dwa przyciski i strona działa.

Wszystkie by się sprawdziły.

Vercel szczególnie — jest świetny do Next.js, developer experience jest bezkonkurencyjny i dla wielu frontend developerów to będzie właściwa odpowiedź.

Ja nie wybrałem żadnej z tych opcji.

Nigdy nie byłem osobą, która automatycznie wybiera najprostsze rozwiązanie.

Chciałem skonfigurować to sam.

Nie po to, żeby coś udowodnić. Chciałem zrobić trochę DevOpsu. Zrozumieć, jak naprawdę wygląda pipeline builda, kiedy trzeba go samemu zadeklarować. Co trafia do amplify.yml. Co robią katalogi cache. Jak IAM, SSL i CDN układają się w całość.

Platformy typu „kliknij dwa przyciski i gotowe” ukrywają to wszystko. I to jest ich siła.

To był też powód, dla którego ich nie wybrałem.

AWS był bardziej wyborem osobistym niż technicznym. W pracy zawsze był ktoś z backendu, kto brał na siebie część infrastrukturalną. Od dawna chciałem zrobić więcej na AWS, ale nigdy nie miałem dobrego pretekstu.

Po certyfikacji Cloud Practitioner znałem już słownictwo, ale nie miałem prawdziwego projektu.

Prywatny blog to idealny, niskoryzykowny sposób na naukę AWS — gdyby migracja poszła źle, mój blog nie działałby przez weekend. To był cały blast radius.

Nowy setup

AWS Amplify hostuje całą stronę z buildem po pushu, automatycznym SSL-em i preview deploymentami dla pull requestów albo podłączonych branchy.

Cloudflare stoi z przodu i obsługuje DNS, proxy, cache oraz reguły na edge’u.

Domena została tam, gdzie była.

Bez EC2. Bez VPS-a. Bez load balancera. Bez shella, którego muszę pilnować i patchować.

Migracja zajęła 2–3 godziny — większość tego czasu to czekanie na propagację DNS.

Usunięcie przejętego VPS-a zajęło 30 sekund.

Cała konfiguracja buildu to jeden plik

To był moment, w którym Amplify naprawdę zaczęło wyglądać jak narzędzie stworzone dla frontend developerów.

Cały deployment mieści się w jednym pliku amplify.yml:

yaml

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - node -v
        - corepack enable
        - corepack prepare pnpm@9 --activate
        - pnpm config set store-dir .pnpm-store
        - pnpm config set node-linker hoisted
        - pnpm install --frozen-lockfile --prefer-offline --ignore-scripts
    build:
      commands:
        - pnpm build
  environment:
    variables:
      NEXT_PUBLIC_SITE_URL: https://my-site
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - .pnpm-store/**/*
      - .next/cache/**/*

Kilka rzeczy, na które warto zwrócić uwagę:

pnpm przez corepack — bez globalnej instalacji pnpm. Corepack jest dostarczany z Node i aktywuje wersję, której potrzebuję.
cache dla .pnpm-store i .next/cache — kolejne buildy wykorzystują zainstalowane paczki i incremental compilation z Next.js. Pierwszy deploy jest wolny, każdy następny dużo szybszy.
--ignore-scripts przy instalacji — lifecycle scripts w zależnościach to ryzyko bezpieczeństwa i stabilności w CI. Każdy postinstall, którego naprawdę potrzebuję, trafia jawnie do fazy builda.

To jest cały deployment pipeline.

Bez serwera.

Bez koparki.

Co się poprawiło

Deploye. Push na main, Amplify buduje, strona się aktualizuje. Jeśli coś się wywali, dostaję maila z linią, która zepsuła build.

Preview environments. Branche i pull requesty mogą dostać własne URL-e. Na OVH oznaczałoby to drugi VPS albo kombinowanie z subdomenami.

SSL i CDN. Cloudflare obsługuje edge. Amplify obsługuje hosting. Przestałem myśleć o jednym i drugim.

Attack surface. Przenosząc stronę na Amplify, usunąłem maszynę, która była realnym problemem bezpieczeństwa. Nie „utwardziłem” jej jeszcze bardziej. Po prostu ją usunąłem. To najtańsza możliwa poprawa bezpieczeństwa.

Co przez chwilę bolało

Pierwszy amplify.yml zajął mi więcej czasu, niż powinien. Dokumentacja zakłada, że już wiesz, gdzie Next.js trzyma artefakty builda. Trzeba się nastawić na jakieś 30 minut prób i błędów zanim zobaczysz pierwszy zielony build.

DNS przy przełączeniu to jedyna naprawdę stresująca część. Ustawiasz rekordy i czekasz. Poprawiasz, czekasz. Pierwsze 20 minut wygląda tak, jakby migracja się nie udała.

Ale zwykle po prostu jeszcze trwa.

Rachunek

Koszt znacząco spadł.

Nie będę podawał jednej konkretnej kwoty, bo AWS rozlicza w dolarach, koszt w złotówkach zależy od kursu, a wszystko skaluje się z liczbą deployów i ruchem.

Nie chodzi jednak głównie o oszczędność.

Chodzi o to, że koszt teraz skaluje się z tym, co strona faktycznie robi, zamiast być stałą opłatą, którą płaciłem niezależnie od tego, czy ktokolwiek ją odwiedzał.

Kiedy taki setup nie ma sensu

To jest część, którą większość wpisów typu „przenieś się na AWS” pomija.

Prosta statyczna strona HTML z jednym formularzem — zwykły hosting współdzielony na OVH albo u dowolnego polskiego dostawcy nadal jest OK. Kilka złotych oszczędności nie jest warte nauki Amplify.
Deployujesz dwa razy w roku — zostań tam, gdzie jesteś. Korzyści z Amplify rosną razem z tym, jak często robisz push.
WordPress z bazą danych — zły kierunek. Sprawdź LightSail albo managed WordPress hosting.
Twój zespół nie zna AWS i nie ma planu, żeby się go nauczyć — nie migruj tylko po to, żeby migrować. Skromne oszczędności nie są warte sytuacji, w której tylko jedna osoba potrafi to naprawić.
Chcesz po prostu wypuścić projekt i nie myśleć o pipeline’ie — Vercel prawdopodobnie będzie lepszą odpowiedzią. Ja wybrałem AWS, bo chciałem zobaczyć poszczególne elementy.

Dla kogo ten tekst nie jest

Oszczędzę ci scrollowania:

Senior cloud engineers — prawdopodobnie już to wszystko wiecie. To nie jest zaawansowany wpis o infrastrukturze.
Osoby szukające głębokiego wejścia w AWS Amplify — dostajecie jeden plik amplify.yml. Głębszy opis zasługuje na osobny tekst.
Osoby, które od trzech lat są zadowolone z Vercela — nic tutaj nie zmieni waszego zdania i nie powinno. Vercel jest świetny.

Ten tekst jest dla frontend developera z zapomnianym VPS-em, certyfikatem Cloud Practitioner i poczuciem, że może istnieć lepszy sposób.

Ja byłem dokładnie w tym miejscu, zanim ta migracja wymusiła decyzję.

Co powiedziałbym innemu frontend developerowi

Jeżeli masz VPS-a, na którego nie logowałeś się od miesięcy, to nie masz serwera.

Masz zobowiązanie.

Hardening pomaga. Ale nie wystarcza. Miałem fail2ban, logowanie kluczem z długim hasłem, niestandardowy port SSH, UFW z otwartymi tylko potrzebnymi portami, automatyczne aktualizacje — i ktoś mimo wszystko się dostał.

Dowiedziałem się tylko dlatego, że provider zauważył ruch i mnie ostrzegł.

Serwer, którego aktywnie nie utrzymujesz, prędzej czy później stanie się problemem — niezależnie od tego, co skonfigurowałeś pierwszego dnia. Czas działa na korzyść atakującego.

Jeśli twój VPS istnieje dlatego, że kiedyś potrzebowałeś serwera, a ten moment już minął, właściwy ruch to go usunąć.

Nie migrować jeden do jednego. Nie robić backupu „na wszelki wypadek”. Usunąć.

To, na co migrujesz, powinno być platformą, nie kolejnym serwerem.

Prawdopodobnie nie potrzebujesz certyfikacji wyższej niż Cloud Practitioner, żeby to zrobić. Certyfikat daje słownictwo. Amplify ukrywa prawie całą resztę za UI, które wygląda znajomo, jeśli używałeś nowoczesnego frontend hostingu.

Blokada mentalna jest większa niż blokada techniczna.

Nudna wersja lekcji

Migracja była popołudniem pracy i jednym plikiem konfiguracyjnym.

Lekcja zajęła kilka miesięcy i jedną koparkę bitcoina.

Prawdziwa zmiana nie polegała na przejściu z OVH na AWS.

Polegała na przejściu z posiadania serwerów na posiadanie konfiguracji. Z uruchamiania infrastruktury na jej deklarowanie. Z odpowiedzialności za maszynę z Linuksem na odpowiedzialność za plik YAML.

To jest ta wymiana.

I kiedy raz ją zobaczysz, trudno wrócić.

Jeśli chcesz porównać realny setup, mój blog jest żywym przykładem — Next.js 15, deployment przez Amplify, serwowany za Cloudflare. Bez koparek bitcoina w środku.