Go · 1.23

Hospedagem Go 24/7

Suba uma API em net/http, um bot ou um worker de fila e deixe rodando. As dependências do go.mod são resolvidas no build, o binário sobe em container isolado e a plataforma reinicia o processo sozinha, em qualquer plano, quando ele cai.

Criar conta Ver planos

Origem

Quem desenhou o Go

No Google, o C++ compilava lento demais para o tamanho do código. Robert Griesemer, Rob Pike e Ken Thompson — este de Unix, os dois de Plan 9 — começaram o Go em 2007 para ter uma linguagem de sistemas com compilação rápida, coletor de lixo e concorrência no núcleo. A primeira versão pública saiu em 2009; a 1.0, estável o bastante para prometer compatibilidade, em 2012. A gramática ficou pequena de propósito: a complexidade deveria viver nas bibliotecas.

Robert Griesemer
Eugene Zelenko · CC BY-SA 4.0

Compilar rápido, de propósito

O Go existe porque o C++ no Google não compilava a tempo. A diferença não é “mais uma linguagem de sistemas”: é um ciclo de build que cabe no dia de quem mexe em milhões de linhas.

Um binário, um processo

O que sobe é um executável. Sem VM obrigatória, sem interpretador no meio, sem árvore de classes para empacotar. Interfaces pequenas no lugar da hierarquia.

Concorrência na gramática

Goroutine e channel não são uma biblioteca que você escolhe: são o modelo. Um serviço em Go é um processo que conversa consigo mesmo assim, não um framework de threads.

O que a plataforma faz por um projeto Go

Quase tudo aqui funciona sem configuração.

go.mod resolvido no build

As dependências saem do go.mod e do go.sum enquanto a imagem é construída, não a cada boot. O que sobe é o binário pronto, e uma falha de resolução aparece no log do build em vez de virar crash em produção.

Três versões, uma linha de config

1.23, 1.22 e 1.21 disponíveis. Trocar é mudar VERSION no vertracloud.config e subir de novo — não há imagem para escolher nem Dockerfile para manter.

Um processo, um executável

Não há interpretador nem gerenciador de pacotes rodando junto: o processo do container é o próprio binário. MEMORY no vertracloud.config define o teto de RAM que ele pode ocupar.

Auto-restart com freio

O processo que cai é reiniciado sozinho, em qualquer plano: um panic em qualquer goroutine derruba o binário inteiro, e é o container que volta em seguida. Se ele quebrar 5 vezes em 10 minutos, o auto-restart é desativado por 24 horas.

O que as pessoas rodam em Go aqui

Um binário só, dois papéis: o mesmo projeto nasce como worker sem porta e vira serviço publicado depois — publicar recria o container, então ele reinicia nesse momento.

APIs em net/http, Gin e Fiber

Publique a aplicação para receber um subdomínio em vertraweb.app com TLS. O servidor precisa escutar em 0.0.0.0:80 — ligado em localhost, o container sobe e a requisição externa dá timeout.

Bots e automações de background

Bot de Discord, agendador ou rotina de integração rodam como processo sem porta HTTP. O token vai nas variáveis de ambiente do painel, nunca num .env dentro do zip — a plataforma não lê arquivo .env.

Workers e consumidores de fila

Coletor agendado, consumidor de fila, pipeline de ETL: processos longos que só precisam ficar de pé. O auto-restart cobre a queda ocasional de rede sem intervenção.

Serviço com banco gerenciado

Um PostgreSQL 17 ou um MySQL 8.0 criado no mesmo painel atende o pgx ou o database/sql pelo host interno. TLS é obrigatório, e o certificado de cliente que você baixa no painel é o que entra no tls.Config.

Versões de Go disponíveis

1.23 é a recomendada e também a mais recente; 1.22 e 1.21 seguem disponíveis para quem depende de uma biblioteca antiga. Fixe uma delas com VERSION no vertracloud.config.

Versão	vertracloud.config	Status
1.23	VERSION=1.23	RecomendadaMais recente
1.22	VERSION=1.22
1.21	VERSION=1.21

A configuração inteira

O vertracloud.config é um arquivo INI opcional na raiz do projeto. MAIN aponta o binário; VERSION escolhe o Go; MEMORY define o teto de RAM do container.

vertracloud.config

NAME=meu-servico
MAIN=app
VERSION=1.23
MEMORY=512

Um plano para cada fase do projeto

A memória e o armazenamento mudam por plano; a linguagem, não. Compare o que cada plano libera e escolha o que cabe no projeto agora.

Comparar planos

Também roda aqui

Mesma plataforma, mesmo deploy, outra stack.

Rust

JavaScript

Java

Perguntas frequentes sobre hospedagem Go

O que o suporte mais responde sobre módulo, binário e versão em Go.

Quais versões de Go posso usar?

1.23 (recomendada e a mais recente), 1.22 e 1.21. A escolha é feita pela chave VERSION no vertracloud.config; sem ela, a aplicação sobe na recomendada.

O deploy falhou com go.mod not found. O que fazer?

O projeto precisa ser um módulo. Rode go mod init na raiz e depois go mod tidy, e inclua go.mod e go.sum no que você envia — sem esses dois arquivos o build não tem como resolver as dependências.

Compilei na minha máquina e o binário não executa. Por quê?

O binário está para outro sistema ou arquitetura. Compile para Linux com GOOS=linux GOARCH=amd64 go build, ou envie o código-fonte e deixe a compilação acontecer no build da plataforma.

Meu binário usa pouca RAM. Posso baixar o MEMORY?

Pode, e o painel mostra o uso real do container ao lado do teto. Só lembre que publicar a aplicação na web exige 512 MB de RAM alocada e plano Pro — abaixo disso a chamada é recusada.

Preciso enviar a pasta vendor no zip?

Não — e não envie. Exclua vendor do pacote: ele infla o upload e as dependências são resolvidas no build, para Linux. O limite do zip é 100 MB e o build tem 5 minutos.

Suba seu serviço Go hoje

Crie a conta, suba o código com go.mod e go.sum — ou conecte o repositório do GitHub — e veja a resolução das dependências e a compilação no terminal do painel.

Criar conta