1.  [Strona główna](/) ›
2.  [Baza wiedzy](/baza-wiedzy/) ›
3.  Kong API Gateway na VPS

# Kong API Gateway na VPS - instalacja i konfiguracja

Opublikowano: 10 kwietnia 2026 · Kategoria: VPS

⚡ W skrócie · 9 min czytania

-   Kong API Gateway: instalacja Docker Compose, tryb DB-less (YAML/deck), tworzenie Service i Route, pluginy rate-limiting i key-auth, monitorowanie przez Admin API.
-   Architektura Konga.
-   Instalacja - Docker Compose (tryb DB-less).
-   Deklaratywna konfiguracja - kong.yaml.
-   Admin API - zarządzanie Kongiem.

Kiedy masz kilka mikroserwisów lub API i każdy wymaga rate limitingu, uwierzytelniania i logowania, wdrożenie tych funkcji oddzielnie w każdej aplikacji to marnotrawstwo. Kong API Gateway centralizuje te zadania - stoi przed wszystkimi serwisami i stosuje pluginy do każdego ruchu. Oparty na Nginx/OpenResty jest wydajny i może obsłużyć tysiące żądań na sekundę. Artykuł pokazuje instalację przez Docker Compose, konfigurację w trybie DB-less (bez bazy danych) i najważniejsze pluginy.

## Architektura Konga

Kong składa się z trzech warstw: serwer proxy (port 8000/8443) przyjmuje ruch od klientów, Admin API (port 8001/8444) służy do konfiguracji, a opcjonalna baza danych (PostgreSQL) persystuje konfigurację między restartami. W trybie DB-less baza nie jest wymagana.

Port

Protokół

Zastosowanie

8000

HTTP

Proxy - ruch API od klientów (HTTP)

8443

HTTPS

Proxy - ruch API od klientów (HTTPS)

8001

HTTP

Admin API - konfiguracja (tylko localhost!)

8444

HTTPS

Admin API TLS - konfiguracja (tylko localhost!)

## Instalacja - Docker Compose (tryb DB-less)

Tryb DB-less (declarative config) to najprostszy start - Kong wczytuje konfigurację z pliku YAML. Nie potrzeba PostgreSQL. Plik konfiguracyjny możesz trzymać w git i stosować przez CI/CD.

```
# docker-compose.yml - Kong DB-less

# version: "3.8"
# services:
#   kong:
#     image: kong:3.9
#     container_name: kong
#     environment:
#       KONG_DATABASE: "off"
#       KONG_DECLARATIVE_CONFIG: /kong/declarative/kong.yaml
#       KONG_PROXY_ACCESS_LOG: /dev/stdout
#       KONG_ADMIN_ACCESS_LOG: /dev/stdout
#       KONG_PROXY_ERROR_LOG: /dev/stderr
#       KONG_ADMIN_ERROR_LOG: /dev/stderr
#       KONG_ADMIN_LISTEN: "127.0.0.1:8001"
#       KONG_PROXY_LISTEN: "0.0.0.0:8000, 0.0.0.0:8443 ssl"
#     volumes:
#       - ./kong.yaml:/kong/declarative/kong.yaml:ro
#     ports:
#       - "8000:8000"
#       - "8443:8443"
#     healthcheck:
#       test: ["CMD", "kong", "health"]
#       interval: 10s
#       timeout: 10s
#       retries: 10
#     restart: unless-stopped

docker-compose up -d
docker-compose logs -f kong
```

## Deklaratywna konfiguracja - kong.yaml

Cała konfiguracja Konga w trybie DB-less jest w jednym pliku YAML. Główne obiekty: **Service** (adres backendu), **Route** (reguła dopasowania żądania do Service) i **Plugin** (funkcja stosowana do Service lub Route).

```
# kong.yaml - pelna konfiguracja DB-less
# _format_version: "3.0"
# _transform: true
#
# services:
#   - name: my-api
#     url: http://api-backend:3000
#     routes:
#       - name: api-route
#         paths:
#           - /api
#         strip_path: true     # usuwa /api z URL do backendu
#         methods:
#           - GET
#           - POST
#           - PUT
#           - DELETE
#     plugins:
#       - name: rate-limiting
#         config:
#           minute: 100
#           hour: 1000
#           policy: local
#
#   - name: public-api
#     url: http://public-backend:4000
#     routes:
#       - name: public-route
#         paths:
#           - /public
#         strip_path: false
#     plugins:
#       - name: key-auth
#         config:
#           key_names:
#             - apikey
#           key_in_header: true
#           key_in_query: false
#
# consumers:
#   - username: client-a
#     keyauth_credentials:
#       - key: "super-secret-api-key-abc123"
#
#   - username: client-b
#     keyauth_credentials:
#       - key: "another-key-xyz789"
```

## Admin API - zarządzanie Kongiem

W trybie z PostgreSQL (nie DB-less) Kong udostępnia REST API do dynamicznej konfiguracji. Admin API słucha wyłącznie na localhost - nigdy nie wystawiaj portu 8001 na publiczne IP!

```
# Sprawdz status Konga
curl http://localhost:8001/

# Lista serwisów
curl http://localhost:8001/services

# Dodaj Service (tryb DB)
curl -X POST http://localhost:8001/services \
  -d name=my-api \
  -d url=http://backend:3000

# Dodaj Route do Service
curl -X POST http://localhost:8001/services/my-api/routes \
  -d "paths[]=/api" \
  -d "methods[]=GET" \
  -d "methods[]=POST"

# Dodaj plugin rate-limiting do Service
curl -X POST http://localhost:8001/services/my-api/plugins \
  -d name=rate-limiting \
  -d config.minute=60 \
  -d config.policy=local

# Dodaj plugin key-auth
curl -X POST http://localhost:8001/services/my-api/plugins \
  -d name=key-auth \
  -d config.key_names=apikey

# Dodaj consumera
curl -X POST http://localhost:8001/consumers \
  -d username=my-client

# Nadaj klucz consumerowi
curl -X POST http://localhost:8001/consumers/my-client/key-auth \
  -d key=my-secret-key-abc123

# Test - request z kluczem
curl http://localhost:8000/api/endpoint \
  -H "apikey: my-secret-key-abc123"

# Test - przekroczony limit (odpowiedz 429)
for i in {1..70}; do
  curl -s -o /dev/null -w "%{http_code}\n" \
    http://localhost:8000/api/endpoint \
    -H "apikey: my-secret-key-abc123"
done
```

## Przegląd kluczowych pluginów

Plugin

Zastosowanie

Kluczowe parametry

`rate-limiting`

Ograniczenie liczby żądań per consumer/IP

minute, hour, day, policy (local/redis)

`key-auth`

Uwierzytelnianie kluczem API

key\_names, key\_in\_header, key\_in\_query

`jwt`

Weryfikacja tokenów JWT

claims\_to\_verify, secret\_is\_base64

`oauth2`

Serwer OAuth2 (authorization\_code, client\_credentials)

scopes, provision\_key

`request-transformer`

Modyfikacja nagłówków/body przed przekazaniem do backendu

add.headers, remove.headers, replace

`response-transformer`

Modyfikacja odpowiedzi z backendu

add.headers, remove.headers

`http-log`

Wysyłanie logów do zewnętrznego serwera HTTP

http\_endpoint, method, timeout

`cors`

Obsługa CORS dla API

origins, methods, headers

`ip-restriction`

Biała/czarna lista IP

allow, deny (CIDR obsługiwane)

## Plugin request-transformer - modyfikacja nagłówków

```
# Dodaj naglowek X-API-Version do kazdego requestu do backendu
curl -X POST http://localhost:8001/services/my-api/plugins \
  -d name=request-transformer \
  -d "config.add.headers[]=X-API-Version:v2" \
  -d "config.remove.headers[]=X-Internal-Token" \
  -d "config.add.headers[]=X-Forwarded-By:kong"

# Dodaj parametr query
curl -X POST http://localhost:8001/routes/api-route/plugins \
  -d name=request-transformer \
  -d "config.add.querystring[]=format:json"
```

## Monitorowanie i metryki

```
# Statystyki przez Admin API
curl http://localhost:8001/status
# latencies: {proxy: X, kong: Y, request: Z}

# Plugin Prometheus (dodaj do Konga)
# config: {}  - brak wymaganych parametrow
curl -X POST http://localhost:8001/plugins \
  -d name=prometheus

# Metryki dostepne na porcie 8001
curl http://localhost:8001/metrics
# kong_http_requests_total
# kong_latency_bucket
# kong_bandwidth_bytes

# Skonfiguruj Prometheus scrape config
# scrape_configs:
#   - job_name: kong
#     static_configs:
#       - targets: ["localhost:8001"]
#     metrics_path: /metrics
```

## Najczęstsze pytania

Czym jest Kong API Gateway i do czego służy? +

Kong to open-source API Gateway oparty na Nginx/OpenResty - stoi przed Twoimi serwisami i centralizuje zadania przekrojowe: rate limiting, uwierzytelnianie (klucze API, JWT, OAuth2), logowanie, transformacje requestów i odpowiedzi, load balancing. Zamiast implementować te funkcje w każdej mikrosłużbie osobno, konfiguruje się je raz w Kong jako pluginy. Kong obsługuje tysiące requestów na sekundę na skromnym VPS.

Czym różni się tryb DB-less od trybu DB (PostgreSQL)? +

Tryb DB (z PostgreSQL) pozwala modyfikować konfigurację w czasie działania przez Admin API i zmiany są persystowane. Tryb DB-less (declarative config) ładuje całą konfigurację z pliku YAML przy starcie - idealny do GitOps (konfiguracja w repo git, CI/CD stosuje zmiany). DB-less jest prostszy w operacji (brak PostgreSQL do utrzymania), ale wymaga restartu Konga po każdej zmianie konfiguracji. Na małym VPS DB-less jest rekomendowany - mniej zużycia pamięci.

Jak działa plugin rate-limiting w Kong? +

Plugin rate-limiting w Kong liczy żądania per consumer (klucz API) lub per IP w oknie czasowym (sekunda/minuta/godzina/dzień). Gdy limit zostanie przekroczony, Kong zwraca HTTP 429 Too Many Requests z nagłówkiem Retry-After. Liczniki są przechowywane lokalnie (w pamięci) lub w Redis (dla klastra wielu nodów Konga). Konfiguracja jest prosta: przy dodaniu pluginu do Route lub Service podajesz limit i okno czasowe.

Czy Kong zastępuje Nginx jako reverse proxy? +

Kong może zastąpić Nginx w roli reverse proxy, ale ma inną filozofię. Nginx konfiguruje się przez pliki .conf - czytelne, ale statyczne. Kong konfiguruje się przez REST API lub YAML - dynamiczne, ale wymaga nauki. Kong jest uzasadniony gdy masz wiele serwisów API wymagających uwierzytelniania, rate limitingu i logowania. Dla prostych stron statycznych lub jednej aplikacji Nginx jest wystarczający i prostszy w utrzymaniu.

## Sprawdź oferty pasujące do tego scenariusza

Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.

Contabo

VPS z dużym RAM dla Kong + PostgreSQL + kilku backendowych serwisów

API Gateway

[Aktywuj rabat →](/out/contabo/#reklama "Contabo")

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/contabo/)

Mikr.us

Mały VPS do testowania Konga w trybie DB-less - bez bazy danych

DB-less Dev

[Aktywuj rabat →](/out/mikrus/#reklama "Mikr.us")

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/mikrus/)

CyberFolks

Hosting z LiteSpeed - zarządzany alternatywnie dla prostych API

Managed

[Aktywuj rabat →](/out/cyberfolks/#reklama "CyberFolks")

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/cyberfolks/)

## Powiązane strony

-   [Gdzie kupić VPS - ranking
    
    Aktualne ceny VPS z pełnym kosztem 2-letnim (TCO) i bez ukrytych opłat odnowienia.
    
    ](/vps/)
-   [Nginx load balancer - konfiguracja upstream](/baza-wiedzy/nginx-load-balancer-konfiguracja/)
-   [Docker na VPS - instalacja i Docker Compose](/baza-wiedzy/docker-na-vps/)
-   [Bezpieczeństwo VPS - checklist](/baza-wiedzy/bezpieczenstwo-vps-checklist/)
-   [Nginx - konfiguracja virtual hostów](/baza-wiedzy/nginx-vhost-konfiguracja/)
-   [Wszystkie artykuły](/baza-wiedzy/)
-   [Jaki VPS wybrać?](/jaki-vps-wybrac/)

Autor: [Redakcja HostGrade.pl](/autorzy/) Zespół redakcyjny · Aktualizacja: 10 kwietnia 2026

Artykuły HostGrade.pl przygotowuje i aktualizuje redakcja serwisu. Ceny startowe, ceny odnowienia i warunki planów sprawdzamy w cennikach i regulaminach dostawców, a potem liczymy całkowity koszt za 2 lata (cena startowa plus odnowienia). Zasady zbierania danych i liczenia kosztów opisujemy na stronie Metodologia. Linki partnerskie oznaczamy jako #reklama.

[O redakcji i metodologii →](/autorzy/)