Blog · Guias de deploy

Como fazer deploy de um app Gin em 2026: um comando, HTTPS e um Dockerfile que fica com você

Pela equipe da Pethost · 10 de outubro de 2026 · Atualizado em 25 de outubro de 2026 · 9 min de leitura

Você tem um app Gin que roda no seu notebook e quer colocá-lo no ar em um endereço com HTTPS. No Pethost, isso é um comando, pethost deploy, rodado na pasta que tem o go.mod. Ele escreve o Dockerfile para você, faz o build do programa e mostra o endereço dele. O app do quickstart do próprio Gin teve o build feito e foi iniciado em 58 segundos na primeira vez, e em 2 segundos na segunda.

O que você precisa para fazer deploy de um app Gin em 2026

Três coisas: o app, o comando pethost e uma conta no Pethost.

O app aqui é o que o quickstart do Gin deixa pronto: go mod init my-api, go get github.com/gin-gonic/gin e este 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
}

O comando é um programa, instalado com uma linha. Todos os comandos dele estão na referência da CLI.

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

A conta precisa de um plano. Se você não entrou, o pethost deploy abre o seu navegador e faz o seu login. Se você ainda não tem um plano, ele mostra onde escolher um e espera.

Faça o deploy do app Gin com um comando

Vá até a pasta que tem o go.mod e rode pethost deploy. Esta é a tela inteira, para o 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. Ele pergunta uma coisa O nome do projeto, que é a primeira palavra do endereço. Enter usa o nome da pasta.
2. A máquina não encontra nada para rodar A linha com o X é a resposta dela: um projeto roda a partir de um Dockerfile ou de um arquivo Compose, e a pasta ainda não tem nenhum dos dois.
3. O pethost escreve o Dockerfile Ele viu o go.mod e um package main ao lado, e envia a pasta de novo.
4. A máquina faz o build e o inicia Ela vê que o programa escuta na 8080 e manda o endereço para lá. Depois o pethost acessa o próprio endereço e mostra o que ele respondeu.

A resposta é 404 porque o quickstart não tem rota em /, só em /ping. Uma API sua muitas vezes vai dizer o mesmo, e isso quer dizer que o programa está no ar e respondendo. Acesse a rota que existe:

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

O arquivo .pethost diz qual projeto é esta pasta. Faça o commit dele junto com o Dockerfile, e o próximo deploy não pergunta nada.

O Dockerfile que o pethost escreve para um programa Go

Este é o arquivo como foi escrito na pasta do quickstart, inteiro:

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

A primeira linha dele diz o que o pethost leu na sua pasta. Três coisas vêm de lá:

• A versão do Go é a da linha go do go.mod.
• O programa é o package main na raiz do módulo, ou a única pasta de cmd/ que tem um. Quando cmd/ tem vários, o pethost não escreve nada e diz por quê: qual programa os visitantes recebem é você quem decide.
• O nome é a última parte do caminho do módulo, como o go install o chamaria. Um Procfile com uma linha web inicia o programa como essa linha diz.

As duas montagens de cache guardam os módulos e o cache de build do Go na sua máquina entre um deploy e outro. É por isso que o segundo deploy levou 2 segundos. Se a máquina não consegue fazer o build ou iniciar o Dockerfile que o pethost escreveu, o pethost tira o arquivo da sua pasta e diz o que falhou.

Defina o GIN_MODE e outras variáveis de ambiente

O Gin inicia em modo debug: as linhas de log dele começam com [GIN-debug]. O log também diz qual porta ele usou:

$ 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

Uma variável é um comando. Ela vai para o arquivo .env do projeto na máquina, que todo deploy seguinte mantém, e o app reinicia com ela:

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

Só o nome, sem valor, faz o comando pedir o valor sem mostrá-lo, que é o jeito certo para um segredo: pethost env set DATABASE_URL. Você não precisa definir a PORT: com router.Run() o Gin usa a 8080, e com router.Run(":3000") a máquina encontra a 3000 do mesmo jeito.

Altere o código e faça o deploy de novo

Edite um handler e rode o mesmo comando. A máquina guarda as camadas do build e os caches do 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

Para fazer o deploy a cada push, conecte o repositório uma vez:

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

O Pethost lê só os repositórios que você deu ao GitHub App dele. Se um deploy der errado, pethost rollback coloca de volta a versão anterior, e a sua máquina guarda as três versões antes da atual. Um agente de IA pode fazer tudo isso por você pelo servidor MCP do Pethost: como um agente faz o deploy de um projeto e cuida dele. O mesmo comando faz o deploy de um app Fiber.

Use seu próprio domínio na API

Qualquer nome sob o domínio da sua conta já é um endereço na hora, com HTTPS. Um domínio seu leva um comando e um registro DNS:

pethost domain add api.example.com

O comando mostra o registro a criar: um CNAME do seu nome para o nome da sua máquina. O certificado chega sozinho assim que o nome resolve, e se renova sozinho.

O que você recebe pelo preço

O Pethost custa € 9,99 por mês por tudo o que você hospeda, com 2 vCPU, 3 GB de memória e 30 GB de disco. Um programa Gin é um binário pequeno, então a máquina tem espaço para o banco de dados dele, um worker e os seus outros projetos. Não há taxa por projeto e nada é medido: uma segunda API não custa nada a mais, e um Postgres ao lado dela entra no mesmo preço.

• € 9,99 por mês por todos os seus projetos, nada medido
• 58s para fazer o build e iniciar o quickstart, na primeira vez
• 2s para o deploy seguinte

O que já vem feito para você: HTTPS com certificados que se renovam sozinhos, deploys a partir do GitHub, backups noturnos guardados por 14 dias, SSH em qualquer container, e cada requisição contada. O painel mostra os caminhos mais acessados e a taxa de erros dos últimos 30 dias, que para uma API é a lista das rotas que as pessoas realmente chamam. A máquina está sempre ligada, então uma requisição nunca espera um cold start. Os planos estão na parte de preços da página inicial.

As telas são deploys do app que o quickstart do Gin escreve, com o Gin 1.12.0, o Go 1.25 e o pethost 0.2.1, em uma máquina de teste nossa que nunca tinha feito build de nada. A conta nelas é a de exemplo, sam.

1. Gin: quickstart
2. Gin: deploy
3. pethost, a linha de comando do Pethost