Go · 1.23

Go hosting, 24/7

Ship a net/http API, a bot or a queue worker and leave it running. Dependencies from go.mod are resolved during the build, the binary starts in an isolated container, and the platform restarts the process on its own, on every plan, when it crashes.

Create account See plans

Origin

Who designed Go

At Google, C++ compiled too slowly for the size of the codebase. Robert Griesemer, Rob Pike and Ken Thompson — the last from Unix, the two from Plan 9 — started Go in 2007 to get a systems language with fast compiles, garbage collection and concurrency in the core. The first public release was 2009; 1.0, stable enough to promise compatibility, in 2012. The grammar stayed small on purpose: complexity was meant to live in libraries.

Robert Griesemer
Eugene Zelenko · CC BY-SA 4.0

Fast compiles, on purpose

Go exists because C++ at Google did not compile in time. The difference is not “another systems language”: it is a build cycle that fits the day of someone touching millions of lines.

One binary, one process

What runs is an executable. No mandatory VM, no interpreter in the middle, no class tree to package. Small interfaces instead of hierarchy.

Concurrency in the grammar

Goroutines and channels are not a library you pick: they are the model. A Go service is a process that talks to itself that way, not a threading framework.

What the platform does for a Go project

Almost all of it works with no configuration.

go.mod resolved at build time

Dependencies come from go.mod and go.sum while the image is built, not on every boot. What starts is the finished binary, and a resolution failure shows up in the build log instead of becoming a crash in production.

Three versions, one config line

1.23, 1.22 and 1.21 are available. Switching means changing VERSION in vertracloud.config and deploying again — there is no image to pick and no Dockerfile to maintain.

One process, one executable

There is no interpreter or package manager running alongside it: the container process is the binary itself. MEMORY in vertracloud.config sets the RAM ceiling it may take.

Auto-restart with a brake

A process that crashes is restarted on its own, on every plan: a panic in any goroutine takes the whole binary down, and it is the container that comes back. If it breaks 5 times in 10 minutes, auto-restart is disabled for 24 hours.

What people run in Go here

One binary, two roles: the same project starts as a worker with no port and becomes a published service later — publishing recreates the container, so it restarts at that moment.

APIs in net/http, Gin and Fiber

Publish the application to get a vertraweb.app subdomain with TLS. The server has to listen on 0.0.0.0:80 — bound to localhost, the container starts and external requests time out.

Bots and background automation

A Discord bot, a scheduler or an integration routine runs as a process with no HTTP port. The token goes in the environment variables tab, never in a .env inside the zip — the platform does not read .env files.

Workers and queue consumers

Scheduled collector, queue consumer, ETL pipeline: long-lived processes that only need to stay up. Auto-restart covers the occasional network drop without anyone stepping in.

A service with a managed database

A PostgreSQL 17 or MySQL 8.0 created in the same dashboard serves pgx or database/sql over the internal host. TLS is mandatory, and the client certificate you download in the dashboard is the one that goes into tls.Config.

Available Go versions

1.23 is both the recommended and the latest; 1.22 and 1.21 stay available for projects tied to an older library. Pin one with VERSION in vertracloud.config.

Version	vertracloud.config	Status
1.23	VERSION=1.23	RecommendedLatest
1.22	VERSION=1.22
1.21	VERSION=1.21

The entire configuration

vertracloud.config is an optional INI file at the root of the project. MAIN points to the binary; VERSION picks the Go release; MEMORY sets the container's RAM ceiling.

vertracloud.config

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

A plan for every stage of the project

Memory and storage change with the plan; the language does not. Compare what each plan unlocks and pick the one that fits the project today.

Compare plans

Also runs here

Same platform, same deploy, a different stack.

Rust

JavaScript

Java

Frequently asked questions about Go hosting

What support answers most about modules, binaries and versions in Go.

Which Go versions can I use?

1.23 (recommended and the latest), 1.22 and 1.21. The choice is made with the VERSION key in vertracloud.config; without it, the application starts on the recommended one.

My deploy failed with go.mod not found. What now?

The project has to be a module. Run go mod init at the root and then go mod tidy, and include go.mod and go.sum in what you upload — without those two files the build cannot resolve dependencies.

I compiled on my machine and the binary will not run. Why?

The binary targets a different operating system or architecture. Build for Linux with GOOS=linux GOARCH=amd64 go build, or upload the source and let the compilation happen in the platform build.

My binary uses very little RAM. Can I lower MEMORY?

You can, and the dashboard shows the container's real usage next to the ceiling. Just remember that publishing the application to the web requires 512 MB of allocated RAM and the Pro plan — below that the call is refused.

Should I upload the vendor folder in the zip?

No — and please do not. Leave vendor out of the package: it inflates the upload and dependencies are resolved during the build, for Linux. The zip limit is 100 MB and the build has 5 minutes.

Deploy your Go service today

Create an account, upload the source with go.mod and go.sum — or connect your GitHub repository — and watch dependency resolution and compilation in the dashboard terminal.

Create account