Go · 1.23
Hosting Go 24/7
Sube una API en net/http, un bot o un worker de cola y déjalo funcionando. Las dependencias del go.mod se resuelven durante el build, el binario arranca en un contenedor aislado y la plataforma reinicia el proceso sola, en cualquier plan, cuando se cae.
Quién diseñó Go
En Google, C++ compilaba demasiado lento para el tamaño del código. Robert Griesemer, Rob Pike y Ken Thompson — este de Unix, los dos de Plan 9 — empezaron Go en 2007 para tener un lenguaje de sistemas con compilación rápida, recolector de basura y concurrencia en el núcleo. La primera versión pública salió en 2009; la 1.0, bastante estable para prometer compatibilidad, en 2012. La gramática quedó pequeña a propósito: la complejidad debía vivir en las bibliotecas.
Robert Griesemer
Eugene Zelenko · CC BY-SA 4.0
Rob Pike
Chlor · CC BY-SA 3.0
Ken Thompson
A.C.Diller · CC BY-SA 4.0
Compilar rápido, a propósito
Go existe porque C++ en Google no compilaba a tiempo. La diferencia no es “otro lenguaje de sistemas”: es un ciclo de build que cabe en el día de quien toca millones de líneas.
Un binario, un proceso
Lo que arranca es un ejecutable. Sin VM obligatoria, sin intérprete en el medio, sin árbol de clases que empaquetar. Interfaces pequeñas en lugar de jerarquía.
Concurrencia en la gramática
Goroutine y channel no son una biblioteca que eliges: son el modelo. Un servicio en Go es un proceso que habla consigo mismo así, no un framework de hilos.
Lo que la plataforma hace por un proyecto Go
Casi todo funciona sin configuración.
go.mod resuelto en el build
Las dependencias salen del go.mod y del go.sum mientras se construye la imagen, no en cada arranque. Lo que sube es el binario listo, y un fallo de resolución aparece en el log del build en vez de convertirse en un crash en producción.
Tres versiones, una línea de config
1.23, 1.22 y 1.21 disponibles. Cambiar es modificar VERSION en vertracloud.config y volver a desplegar — no hay imagen que elegir ni Dockerfile que mantener.
Un proceso, un ejecutable
No hay intérprete ni gestor de paquetes corriendo al lado: el proceso del contenedor es el propio binario. MEMORY en vertracloud.config define el techo de RAM que puede ocupar.
Auto-reinicio con freno
El proceso que cae se reinicia solo, en cualquier plan: un panic en cualquier goroutine tumba el binario entero, y es el contenedor el que vuelve. Si se rompe 5 veces en 10 minutos, el auto-reinicio se desactiva durante 24 horas.
Lo que la gente ejecuta en Go aquí
Un solo binario, dos papeles: el mismo proyecto nace como worker sin puerto y se vuelve servicio publicado después — publicar recrea el contenedor, así que se reinicia en ese momento.
APIs en net/http, Gin y Fiber
Publica la aplicación para recibir un subdominio en vertraweb.app con TLS. El servidor tiene que escuchar en 0.0.0.0:80 — atado a localhost, el contenedor arranca y la petición externa da timeout.
Bots y automatización en segundo plano
Un bot de Discord, un programador de tareas o una rutina de integración corren como proceso sin puerto HTTP. El token va en las variables de entorno del panel, nunca en un .env dentro del zip — la plataforma no lee archivos .env.
Workers y consumidores de cola
Recolector programado, consumidor de cola, pipeline de ETL: procesos largos que solo necesitan mantenerse en pie. El auto-reinicio cubre la caída ocasional de red sin intervención.
Servicio con base de datos gestionada
Un PostgreSQL 17 o un MySQL 8.0 creado en el mismo panel atiende a pgx o database/sql por el host interno. TLS es obligatorio, y el certificado de cliente que descargas en el panel es el que entra en tls.Config.
Versiones de Go disponibles
La 1.23 es la recomendada y también la más reciente; la 1.22 y la 1.21 siguen disponibles para quien depende de una biblioteca antigua. Fija una con VERSION en el vertracloud.config.
| Versión | vertracloud.config | Estado |
|---|---|---|
| 1.23 | VERSION=1.23 | RecomendadaMás reciente |
| 1.22 | VERSION=1.22 | |
| 1.21 | VERSION=1.21 |
La configuración entera
vertracloud.config es un archivo INI opcional en la raíz del proyecto. MAIN apunta al binario; VERSION elige el Go; MEMORY define el techo de RAM del contenedor.
NAME=meu-servico
MAIN=app
VERSION=1.23
MEMORY=512Un plan para cada etapa del proyecto
La memoria y el almacenamiento cambian según el plan; el lenguaje, no. Compara lo que abre cada plan y elige el que le sirve al proyecto hoy.
Comparar planesTambién corre aquí
Misma plataforma, mismo deploy, otro stack.
Preguntas frecuentes sobre hosting Go
Lo que soporte más responde sobre módulo, binario y versión en Go.
¿Qué versiones de Go puedo usar?
1.23 (recomendada y la más reciente), 1.22 y 1.21. La elección se hace con la clave VERSION en vertracloud.config; sin ella, la aplicación arranca en la recomendada.
El despliegue falló con go.mod not found. ¿Qué hago?
El proyecto tiene que ser un módulo. Ejecuta go mod init en la raíz y luego go mod tidy, e incluye go.mod y go.sum en lo que subes — sin esos dos archivos el build no puede resolver las dependencias.
Compilé en mi máquina y el binario no se ejecuta. ¿Por qué?
El binario apunta a otro sistema o arquitectura. Compila para Linux con GOOS=linux GOARCH=amd64 go build, o sube el código fuente y deja que la compilación ocurra en el build de la plataforma.
Mi binario usa poca RAM. ¿Puedo bajar el MEMORY?
Puedes, y el panel muestra el uso real del contenedor junto al techo. Solo recuerda que publicar la aplicación en la web exige 512 MB de RAM asignada y plan Pro — por debajo, la llamada se rechaza.
¿Tengo que subir la carpeta vendor en el zip?
No — y mejor no lo hagas. Deja vendor fuera del paquete: infla la subida y las dependencias se resuelven en el build, para Linux. El límite del zip es 100 MB y el build tiene 5 minutos.
Sube tu servicio Go hoy
Crea la cuenta, sube el código con go.mod y go.sum — o conecta el repositorio de GitHub — y observa la resolución de dependencias y la compilación en la terminal del panel.
Crear cuenta