Blog · Poradniki wdrożeń

Jak wdrożyć aplikację Gin w 2026: jedno polecenie, HTTPS i Dockerfile, który zostaje u ciebie

Zespół Pethost · 10 października 2026 · Zaktualizowano 25 października 2026 · 7 min czytania

Masz aplikację Gin, która działa na twoim laptopie, i chcesz ją mieć w sieci pod adresem z HTTPS. Na Pethost to jedno polecenie, pethost deploy, uruchomione w katalogu z go.mod. Samo pisze za ciebie Dockerfile, buduje program i wypisuje jego adres. Aplikacja z quickstartu Gina za pierwszym razem zbudowała się i uruchomiła w 58 sekund, a za drugim w 2 sekundy.

Czego potrzebujesz, żeby wdrożyć aplikację Gin w 2026

Trzech rzeczy: aplikacji, polecenia pethost i konta Pethost.

Aplikacja to tutaj ta, którą zostawia quickstart Gina: go mod init my-api, go get github.com/gin-gonic/gin i ten main.go:

package main

import (
	"net/http"

	"github.com/gin-gonic/gin"
)

func main() {
	router := gin.Default()
	router.GET("/ping", func(c *gin.Context) {
		c.JSON(http.StatusOK, gin.H{
			"message": "pong",
		})
	})
	router.Run() // listens on 0.0.0.0:8080 by default
}

Polecenie to jeden program, instalowany jedną linią. Wszystkie jego polecenia są w dokumentacji CLI.

curl -fsSL https://pethost.dev/install.sh | sh      # macOS, Linux
irm https://pethost.dev/install.ps1 | iex           # Windows, in PowerShell

Konto potrzebuje planu. Jeśli nie jesteś zalogowany, pethost deploy otwiera przeglądarkę i cię loguje. Jeśli nie masz jeszcze planu, pokazuje, gdzie go wybrać, i czeka.

Wdróż aplikację Gin jednym poleceniem

Przejdź do katalogu z go.mod i uruchom pethost deploy. Oto cały ekran dla quickstartu:

$ cd my-api
$ pethost deploy
Name it [my-api]:    it will live at https://my-api.sam.pethost.app
✓ Packed 3 files, 9 KB
✓ Uploaded straight to your machine
✗ /compose.yaml: the project directory has no compose.yaml at its root: add one
✓ Go program detected, wrote Dockerfile.
✓ Packed 4 files, 10 KB
✓ Uploaded straight to your machine
✓ Built and started in 58 s
  · wrote compose.yaml for the Dockerfile: the service app, reading .env
✓ app listens on 8080 → https://my-api.sam.pethost.app
  It answers 404.

https://my-api.sam.pethost.app

Wrote .pethost (commit it). Next:   pethost logs -f   ·   pethost open

1. Pyta o jedno O nazwę projektu, która jest pierwszym słowem jego adresu. Enter bierze nazwę katalogu.
2. Maszyna nie znajduje nic do uruchomienia Linia z krzyżykiem to jej odpowiedź: projekt działa z Dockerfile albo z pliku Compose, a w katalogu nie ma jeszcze żadnego z nich.
3. pethost pisze Dockerfile Zobaczył go.mod, a obok niego package main, i wgrywa katalog jeszcze raz.
4. Maszyna buduje i uruchamia program Widzi, że program nasłuchuje na porcie 8080, i tam kieruje adres. Potem pethost sam odpytuje adres i wypisuje, co ten odpowiedział.

Odpowiedź to 404, bo quickstart nie ma trasy pod /, tylko /ping. Twoje własne API często powie to samo, a to znaczy, że program działa i odpowiada. Odpytaj trasę, która istnieje:

$ curl https://my-api.sam.pethost.app/ping
{"message":"pong"}

Plik .pethost mówi, którym projektem jest ten katalog. Zrób jego commit razem z Dockerfile, a następne wdrożenie o nic nie zapyta.

Dockerfile, który pethost pisze dla programu w Go

Oto cały plik, tak jak trafił do katalogu quickstartu:

# Written by pethost deploy for this Go program: Go 1.25 (go.mod), its program is ..
# It is yours now: change it as you like. pethost does not write it again.

FROM golang:1.25
WORKDIR /app

COPY . .

RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    go build -o /usr/local/bin/my-api .

CMD ["my-api"]

Jego pierwsza linia mówi, co pethost przeczytał w twoim katalogu. Stamtąd biorą się trzy rzeczy:

• Wersja Go to ta z linii go w go.mod.
• Program to package main w katalogu głównym modułu albo ten jeden katalog w cmd/, który go ma. Gdy w cmd/ jest ich kilka, pethost nic nie pisze i mówi dlaczego: to ty decydujesz, który program dostaną odwiedzający.
• Nazwa to ostatnia część ścieżki modułu: tak nazwałoby program polecenie go install. Procfile z linią web uruchamia program tak, jak mówi ta linia.

Dwa montowania cache trzymają moduły Go i cache builda na twojej maszynie między wdrożeniami. Dlatego drugie wdrożenie trwało 2 sekundy. Jeśli maszyna nie zbuduje albo nie uruchomi Dockerfile napisanego przez pethost, pethost usuwa ten plik z twojego katalogu i mówi, co się nie udało.

Ustaw GIN_MODE i inne zmienne środowiskowe

Gin startuje w trybie debug: jego linie logu zaczynają się od [GIN-debug]. Log mówi też, który port wziął:

$ pethost logs
2026-10-10T11:15:22Z	app	[GIN-debug] GET    /ping                     --> main.main.func1 (3 handlers)
2026-10-10T11:15:22Z	app	[GIN-debug] Environment variable PORT is undefined. Using port :8080 by default
2026-10-10T11:15:22Z	app	[GIN-debug] Listening and serving HTTP on :8080

Zmienna to jedno polecenie. Trafia do pliku .env projektu na maszynie, który zachowuje każde kolejne wdrożenie, a aplikacja uruchamia się z nią od nowa:

$ pethost env set GIN_MODE=release
my-api (.pethost)
✓ /.env has GIN_MODE now. Deployed in 4 s.

Sama nazwa pyta o wartość, nie pokazując jej, i tak podaje się sekret: pethost env set DATABASE_URL. Nie musisz ustawiać PORT: z router.Run() Gin bierze 8080, a z router.Run(":3000") maszyna tak samo znajduje 3000.

Zmień kod i wdróż ponownie

Zmień handler i uruchom to samo polecenie. Maszyna przechowuje warstwy builda i cache Go:

$ pethost deploy
my-api (.pethost)
✓ Packed 5 files · uploaded · built and started in 2 s
  · kept the project's .env
  · wrote compose.yaml for the Dockerfile: the service app, reading .env
  · kept the project's x-pethost
  It answers 404.
https://my-api.sam.pethost.app

Żeby zamiast tego wdrażać po każdym pushu, podłącz raz repozytorium:

pethost github sam/my-api          # from now on, every push deploys itself

Pethost czyta tylko repozytoria udostępnione jego GitHub App. Jeśli wdrożenie pójdzie źle, pethost rollback przywraca wersję sprzed niego, a twoja maszyna trzyma trzy wersje sprzed bieżącej. Agent AI może zrobić to wszystko za ciebie przez serwer MCP Pethost: jak agent wdraża projekt i o niego dba. To samo polecenie wdraża aplikację Fiber.

Użyj własnej domeny dla API

Każda nazwa pod domeną twojego konta od razu jest adresem, z HTTPS. Domena, którą masz, to jedno polecenie i jeden rekord DNS:

pethost domain add api.example.com

Polecenie wypisuje rekord do utworzenia: CNAME z twojej nazwy na nazwę twojej maszyny. Certyfikat pojawia się sam, gdy tylko nazwa zacznie się rozwiązywać, i sam się odnawia.

Co dostajesz za tę cenę

Pethost kosztuje 9,99 € miesięcznie za wszystko, co hostujesz, na 2 vCPU, 3 GB pamięci i 30 GB dysku. Program w Ginie to jedna mała binarka, więc na maszynie zostaje miejsce na jego bazę danych, workera i twoje inne projekty. Nie ma opłaty za projekt ani żadnych liczników: drugie API nic więcej nie kosztuje, a Postgres obok niego jest w tej samej cenie.

• 9,99 € miesięcznie za wszystkie twoje projekty, bez liczników
• 58 s na zbudowanie i uruchomienie quickstartu za pierwszym razem
• 2 s na kolejne wdrożenie

Co jest już zrobione za ciebie: HTTPS z certyfikatami, które same się odnawiają, wdrożenia z GitHuba, nocne backupy trzymane przez 14 dni, SSH do każdego kontenera i każde żądanie policzone. Panel pokazuje najczęściej odwiedzane ścieżki i odsetek błędów z ostatnich 30 dni, a w przypadku API to lista tras, które ludzie naprawdę wywołują. Maszyna działa cały czas, więc żądanie nigdy nie czeka na zimny start. Plany są w cenniku na stronie głównej.

Ekrany to wdrożenia aplikacji, którą pisze quickstart Gina, z Gin 1.12.0, Go 1.25 i pethost 0.2.1, na naszej maszynie testowej, która wcześniej niczego nie budowała. Konto na nich to przykładowe sam.

1. Gin: quickstart
2. Gin: wdrażanie
3. pethost, narzędzie wiersza poleceń Pethost