Oracle Cloud Free Tier: jak hostuję produkcyjne aplikacje webowe za 0 USD miesięcznie (na zawsze)

Dlaczego istnieje Oracle Cloud Free Tier (i dlaczego jest legalny)

Odniosę się do słonia w pokoju: tak, to naprawdę jest za darmo. Na zawsze. Nie "za darmo przez 12 miesięcy" jak w AWS. Nie "za darmo z kredytem 200 dolarów, który wygasa" jak w Azure. Warstwa Always Free Oracle to stała alokacja, która nie wygasa, nie aktualizuje się automatycznie i nie zaskakuje cię rachunkiem.

Dlaczego Oracle to robi? Bo spóźnili się do wyścigu chmurowego i potrzebują, aby programiści wypróbowali ich platformę. Ich zakład polega na tym, że jakiś odsetek przeskaluje się do płatnych warstw. Ale nawet jeśli nigdy nie wydasz ani grosza, zasoby Always Free pozostają twoje.

Oto, co dostajesz:

2 mikro-VM-y AMD - po 1 OCPU i 1 GB RAM każdy (lub 1 VM ARM z maksymalnie 4 OCPU i 24 GB RAM na Ampere A1)
200 GB łącznego magazynu blokowego na wszystkich VM-ach
10 TB/miesiąc wychodzącego transferu danych
Publiczny adres IPv4 w zestawie
2 autonomiczne bazy danych (po 20 GB każda)
10 GB magazynu obiektowego

Dla osobistego portfolio, projektu pobocznego, środowiska staging czy nawet aplikacji produkcyjnej o niskim ruchu - to więcej niż wystarczy.

Krok 1: Utwórz konto i maszynę wirtualną

Zarejestruj się na cloud.oracle.com. Będziesz potrzebować karty kredytowej do weryfikacji tożsamości, ale nie zostaniesz obciążony, a na warstwie Always Free możesz pozostać bezterminowo.

Utwórz instancję obliczeniową:

Przejdź do Compute → Instances → Create Instance
Wybierz Ubuntu 22.04 (lub 24.04) jako obraz
Wybierz kształt VM.Standard.E2.1.Micro (kwalifikujący się do Always Free) lub VM.Standard.A1.Flex (Ampere ARM, do 4 OCPU za darmo)
W sekcji sieci upewnij się, że zaznaczono Assign a public IPv4 address
Prześlij własny publiczny klucz SSH (więcej o tym poniżej)
Kliknij Create

Maszyna wirtualna będzie gotowa w około 60 sekund. Zanotuj publiczny adres IP - to stały adres Twojego serwera.

Krok 2: Klucze SSH – wgraj własny (to kluczowe)

Oracle daje Ci opcję wygenerowania pary kluczy SSH podczas tworzenia maszyny wirtualnej i pobrania klucza prywatnego. Nie używaj tej opcji.

Dlaczego? Trzy powody:

Klucze generowane w przeglądarce mają skłonność do psucia się. Wielu użytkowników zgłaszało, że klucze SSH wygenerowane przez Oracle przestają działać po pewnym czasie - czasami po ponownym uruchomieniu maszyny wirtualnej, czasami losowo. Gdy Twój klucz przestanie działać, a szeregowe połączenie konsolowe będzie Twoim jedynym rozwiązaniem awaryjnym, pożałujesz, że nie użyłeś własnego klucza.
Powinieneś być właścicielem swoich kluczy. Twój prywatny klucz SSH powinien znajdować się w ~/.ssh/ na Twoim komputerze, wygenerowany przez Ciebie, zabezpieczony kopią zapasową przez Ciebie. Klucz wygenerowany w przeglądarce, pobrany raz i zapisany w folderze Pobrane to incydent bezpieczeństwa czekający, aby się wydarzyć.
Integracja CI/CD. Jeśli chcesz, aby GitHub Actions wdrażał kod na Twoim serwerze (a chcesz), potrzebujesz klucza prywatnego przechowywanego jako sekret GitHub. Rozpoczęcie od własnego klucza czyni to prostym.

Wygeneruj parę kluczy na swoim lokalnym komputerze, jeśli jeszcze jej nie masz:

# Wygeneruj klucz ED25519 (nowoczesny, szybki, bezpieczny)
ssh-keygen -t ed25519 -C "your-email@example.com"

# Albo RSA 4096, jeśli potrzebujesz szerszej kompatybilności
ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

# Skopiuj klucz publiczny (wklej go do formularza Oracle)
cat ~/.ssh/id_ed25519.pub

Wklej zawartość swojego pliku .pub do pola klucza SSH podczas tworzenia maszyny wirtualnej. To wszystko. Twój klucz, Twoja kontrola, żadnych niespodzianek.

Krok 3: Otwórz porty (część, którą Oracle robi zagmatwaną)

W tym miejscu większość ludzi utyka. Zalogujesz się przez SSH do swojej maszyny wirtualnej, zainstalujesz nginx i odkryjesz, że port 80 jest nieosiągalny ze świata zewnętrznego. Powód: Oracle ma dwie zapory sieciowe i musisz otworzyć obie.

Zapora 1: Listy zabezpieczeń Oracle Cloud (poziom VCN)

To zapora na poziomie chmury. Przejdź do:

Networking → Virtual Cloud Networks → twoja VCN
Security Lists → Default Security List
Add Ingress Rules:

# Reguła wejściowa dla HTTP
Source CIDR:   0.0.0.0/0
IP Protocol:   TCP
Destination Port Range: 80

# Reguła wejściowa dla HTTPS
Source CIDR:   0.0.0.0/0
IP Protocol:   TCP
Destination Port Range: 443

Zapora 2: iptables wewnątrz maszyny wirtualnej

Obrazy Ubuntu od Oracle dostarczane są z regułami iptables, które blokują cały ruch przychodzący z wyjątkiem SSH. Nawet po otwarciu listy zabezpieczeń chmury Twój serwer będzie odrzucał połączenia HTTP, dopóki nie otworzysz zapory na poziomie systemu operacyjnego:

# Otwórz port 80 (HTTP) i 443 (HTTPS)
sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 443 -j ACCEPT

# Zapisz reguły, aby przetrwały ponowne uruchomienia
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save

Obie zapory muszą być otwarte. To potyka każdego za pierwszym razem. Jeśli Twoja witryna się nie ładuje, sprawdź najpierw listę zabezpieczeń chmury, a następnie iptables.

Krok 4: Pełna konfiguracja serwera (jeden skrypt)

Oto skrypt bootstrapujący, którego używam. Instaluje Pythona, nginx, konfiguruje Gunicorn jako usługę systemd i ustawia nginx jako reverse proxy - wszystko w jednym uruchomieniu:

#!/usr/bin/env bash
set -euo pipefail

# Install Python 3.12
sudo add-apt-repository -y ppa:deadsnakes/ppa
sudo apt-get update -qq
sudo apt-get install -y python3.12 python3.12-venv \
    python3.12-dev build-essential nginx

# Open firewall
sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 443 -j ACCEPT
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save

# Clone your project
APP_DIR="$HOME/myapp"
git clone git@github.com:you/your-repo.git "$APP_DIR"

# Create virtualenv and install dependencies
python3.12 -m venv "$APP_DIR/.venv"
"$APP_DIR/.venv/bin/pip" install -r "$APP_DIR/requirements.txt"

# Create a systemd service for Gunicorn
sudo tee /etc/systemd/system/myapp.service > /dev/null <<EOF
[Unit]
Description=My App (Gunicorn)
After=network.target

[Service]
User=ubuntu
Group=www-data
WorkingDirectory=$APP_DIR
EnvironmentFile=$APP_DIR/.env
ExecStart=$APP_DIR/.venv/bin/gunicorn myapp.wsgi:application \\
    --workers 2 --bind unix:/run/myapp.sock
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

# Configure nginx reverse proxy
sudo tee /etc/nginx/sites-available/myapp > /dev/null <<EOF
server {
    listen 80;
    server_name _;
    client_max_body_size 20M;

    location /static/ {
        alias $APP_DIR/staticfiles/;
        expires 30d;
    }

    location / {
        proxy_pass http://unix:/run/myapp.sock;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
    }
}
EOF

sudo ln -sf /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx

# Enable and start
sudo systemctl enable myapp && sudo systemctl start myapp
echo "Done. Visit http://$(curl -s ifconfig.me)"

Krok 5: SSL z Let's Encrypt (darmowy HTTPS)

Gdy DNS twojej domeny wskazuje już na publiczny IP VM-a Oracle, dodanie HTTPS zajmuje dwie komendy:

sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com

# Auto-renewal is set up automatically via systemd timer
# Verify with:
sudo certbot renew --dry-run

Certbot modyfikuje twoją konfigurację nginx tak, aby nasłuchiwała na porcie 443 z certyfikatem i przekierowywała port 80 na HTTPS. Darmowy SSL, automatycznie odnawiany co 90 dni, zero konserwacji.

Krok 6: CI/CD z GitHub Actions

Ostatni element: zautomatyzowane wdrożenia przy każdym pushu do main. Dodaj swój prywatny klucz SSH jako sekret GitHub (DEPLOY_SSH_KEY), a następnie utwórz ten workflow:

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: your-server-ip
          username: ubuntu
          key: ${{ secrets.DEPLOY_SSH_KEY }}
          script: |
            cd ~/myapp
            git pull origin main
            bash scripts/deploy.sh

Wypchnij zmiany na main, GitHub łączy się przez SSH z Twoją maszyną wirtualną Oracle, pobiera kod, uruchamia migracje, zbiera pliki statyczne i ponownie uruchamia Gunicorna. Pełne CI/CD za 0 $.

Oracle Free Tier kontra AWS EC2 t2.micro: prawdziwe porównanie

AWS oferuje t2.micro w swojej darmowej warstwie — ale tylko przez 12 miesięcy. Potem płacisz. Porównajmy te dwie opcje uczciwie:

Oracle Free Tier    AWS t2.micro
                        ────────────────    ────────────
Cena po 1. roku         0 USD (na zawsze)   ~8,50 USD/mies.
vCPU                    1 OCPU              1 vCPU
RAM                     1 GB (lub 24 GB ARM) 1 GB
Pamięć masowa           50 GB boot + 150 GB 8 GB (30 GB za darmo)
Transfer wychodzący     10 TB/mies.         100 GB/mies. (potem 0,09 USD/GB)
Publiczne IPv4          W zestawie          3,75 USD/mies. (od lut 2024)
Always Free             Tak                 Nie (tylko 12 miesięcy)
Opcja ARM (24GB RAM)    Tak (Ampere A1)     Nie (Graviton jest płatny)

Liczby mówią same za siebie. Oracle daje ci więcej pamięci masowej, 100-krotność przepustowości, darmowy publiczny adres IP, a do tego to nigdy nie wygasa. Warstwa darmowa AWS już wcześniej była skąpa, a odkąd w lutym 2024 zaczęli pobierać 3,75 USD/miesiąc za publiczne adresy IPv4, uruchomienie nawet zatrzymanej instancji EC2 kosztuje pieniądze.

Prawdziwym hitem jest kształt Ampere A1 ARM. W warstwie Always Free możesz przydzielić do 4 OCPU i 24 GB pamięci RAM. To nie jest maszyna hobbystyczna - to pełnoprawny serwer, który może jednocześnie obsługiwać bazę danych, aplikację Django i cache Redis.

Pułapki, o których nikt ci nie mówi

Oracle Free Tier jest znakomity, ale ma swoje ostre krawędzie:

Bezczynne instancje są odzyskiwane. Oracle zastrzega sobie prawo do zatrzymania instancji Always Free, które są „bezczynne” (konsekwentnie poniżej 10% zużycia CPU i 10% pamięci). Uruchomienie lekkiego serwera WWW zwykle utrzymuje Cię powyżej progu, ale miej to na uwadze.
Dostępność jest ograniczona. Maszyny wirtualne Free Tier są popularne. Jeśli Twój region jest zapełniony, nie utworzysz nowej instancji. Wypróbuj inne domeny dostępności lub regiony. Niektórzy skryptują API tworzenia, aby ponawiać próby aż zwolni się miejsce.
Klucze SSH wygenerowane przez Oracle są zawodne. Mówiłem to już wcześniej i powiem jeszcze raz: prześlij własny klucz.
Podwójna zapora sieciowa. Lista zabezpieczeń chmury + iptables systemu operacyjnego. Otwórz obie albo spędzisz godzinę na debugowaniu, dlaczego nginx jest nieosiągalny.
Brak wysyłania e-maili. Oracle blokuje wychodzący SMTP (port 25) w Free Tier. Zamiast tego użyj transakcyjnej usługi e-mail, takiej jak Mailgun, SendGrid lub Resend.

Co uruchamiam na moim darmowym VM-ie w Oracle

Ta właśnie strona - portfolio i blog, które czytasz w tej chwili - działa na maszynie wirtualnej Oracle Cloud Free Tier. Stos technologiczny:

Django 5.x + Wagtail 6.x - warstwa CMS i aplikacji
Gunicorn z 2 workerami, zarządzany przez systemd
Nginx jako reverse proxy z obsługą plików statycznych
SQLite jako baza danych (całkowicie wystarczająca dla strony osobistej)
Let's Encrypt dla darmowego SSL
GitHub Actions dla wdrożeń bez ingerencji

Całkowity koszt miesięczny: 0 USD. Całkowity koszt roczny: 0 USD. Jedynym płatnym elementem jest nazwa domeny.

Strona ładuje się szybko, obsługuje cały ruch, którego potrzebuję, i wdraża się automatycznie, gdy pushuję do main. Dla portfolio dewelopera, bloga, projektu pobocznego lub środowiska staging Oracle Cloud Free Tier to najlepsza oferta w chmurowych usługach obliczeniowych. Bez gwiazdek.

Najtańszy serwer to taki, który nic nie kosztuje. Najlepszy serwer to taki, który w pełni kontrolujesz. Oracle Free Tier jest jednym i drugim.