Blog · Deploy guides

How to deploy a Gin app in 2026: one command, HTTPS and a Dockerfile you keep

By the Pethost team · 10 October 2026 · 8 min read

You have a Gin app that runs on your laptop, and you want it online at an address with HTTPS. On Pethost that is one command, pethost deploy, run in the folder that has go.mod. It writes the Dockerfile for you, builds the program and prints its address. Gin's own quickstart was built and started in 58 seconds the first time, and in 2 seconds the second.

What you need to deploy a Gin app in 2026

Three things: the app, the pethost command and a Pethost account.

The app here is the one Gin's quickstart leaves: go mod init my-api, go get github.com/gin-gonic/gin, and this 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
}

The command is one program, installed by one line. Every command it has is in the CLI's reference.

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

The account needs a plan. If you are not signed in, pethost deploy opens your browser and signs you in. If you have no plan yet, it shows you where to choose one, and waits.

Deploy the Gin app with one command

Go to the folder that has go.mod and run pethost deploy. This is the whole screen, for the quickstart:

$ 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. It asks one thing The project's name, which is the first word of its address. Enter takes the folder's name.
2. The machine finds nothing to run The line with the cross is its answer: a project runs from a Dockerfile or a Compose file, and the folder has neither yet.
3. pethost writes the Dockerfile It saw go.mod and a package main beside it, and uploads the folder again.
4. The machine builds and starts it It sees that the program listens on 8080 and sends the address there. Then pethost asks the address itself, and prints what it answered.

The answer is 404 because the quickstart has no route at /, only /ping. An API of your own will often say the same, and it means the program is up and answering. Ask the route that exists:

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

The file .pethost says which project this folder is. Commit it with the Dockerfile, and the next deploy asks nothing.

The Dockerfile that pethost writes for a Go program

This is the file as it was written into the quickstart's folder, whole:

# 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"]

Its first line says what pethost read in your folder. Three things come from there:

• The Go version is the one on the go line of go.mod.
• The program is the package main at the module's root, or the one folder of cmd/ that has one. Where cmd/ has several, pethost writes nothing and says why: which program visitors get is yours to say.
• The name is the last part of the module's path, as go install would name it. A Procfile with a web line starts the program as that line says.

The two cache mounts keep Go's modules and build cache on your machine between deploys. That is why the second deploy took 2 seconds. If the machine cannot build or start the Dockerfile pethost wrote, pethost takes the file back out of your folder and says what failed.

Set GIN_MODE and other environment variables

Gin starts in debug mode: its log lines begin with [GIN-debug]. The log also says which port it took:

$ 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

A variable is one command. It goes into the project's .env file on the machine, which every later deploy keeps, and the app starts again with it:

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

A bare name asks for the value without showing it, which is the way for a secret: pethost env set DATABASE_URL. You do not have to set PORT: with router.Run() Gin takes 8080, and with router.Run(":3000") the machine finds 3000 the same way.

Change the code and deploy again

Edit a handler and run the same command. The machine keeps the build's layers and Go's caches:

$ 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

To deploy on every push instead, connect the repository once:

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

Pethost reads only the repositories you gave its GitHub App. If a deploy goes wrong, pethost rollback puts the version before it back, and your machine keeps the three versions before the current one. An AI agent can do all of this for you through Pethost's MCP server: how an agent deploys and looks after a project. The same command deploys a Fiber app.

Use your own domain for the API

Any name under your account's domain is an address at once, with HTTPS. A domain you own takes one command and one DNS record:

pethost domain add api.example.com

The command prints the record to make: a CNAME from your name to your machine's name. The certificate comes by itself once the name resolves, and renews itself.

What you get for the price

Pethost is €9.99 a month for everything you host, on 2 vCPU, 3 GB of memory and 30 GB of disk. A Gin program is one small binary, so the machine has room for its database, a worker and your other projects. There is no fee per project and nothing metered: a second API costs nothing more, and a Postgres beside it is part of the same price.

• €9.99 a month for the whole machine
• 58 s to build and start the quickstart, the first time
• 2 s for the deploy after it

What is already done on it: HTTPS with certificates that renew themselves, deploys from GitHub, nightly backups kept for 14 days, SSH into any container, and every request counted. The panel shows the busiest paths and the error rate of the last 30 days, which for an API is the list of routes people really call. The machine is always on, so a request never waits for a cold start. The plans are on the pricing part of the first page.

The screens are deploys of the app that Gin's quickstart writes, with Gin 1.12.0, Go 1.25 and pethost 0.2.1, on a test machine of ours that had built nothing before. The account in them is the example one, sam.

1. Gin: quickstart
2. Gin: deployment
3. pethost, the command line of Pethost