A compiled Go binary serving its own HTTP
A compiled Go binary serving its own HTTP. Like Node it is the web server as well as the application, and like Node it replaces PHP-FPM and Nginx rather than joining them. In front of it is the platform's proxy, which terminates TLS and routes the hostname; behind it, whatever the project chose.
The image is the upstream Go image, so the toolchain your build steps run is
the one the binary is built with. Choose the version with runtime.go in
vallic.yaml:
version: 1
type: golang
runtime:
go: '1.27'
build:
steps:
- go build -o bin/server ./cmd/server
start: bin/server
port: 8080
start is required. Nothing can guess what your binary is called, and a
container with nothing to run starts and exits. It runs in the release, at
/var/www/html/current (WEB_ROOT), which is read-only.
Your binary listens on PORT, which is 8080 unless port says otherwise.
Go's module and build caches are kept between builds for you, so a second build
does not download or compile what the first one did.
Uploads and anything else written at runtime go under /mnt/files
(VALLIC_PUBLIC_DIR, VALLIC_PRIVATE_DIR), which outlive the release. See
Node.js and Go for a fuller example.
| Version | Status |
|---|---|
1.27.0 |
Supported, and the default |
1.26.7 |
Supported |
1.26.6 |
Supported |
Pin the version, not the build: name 1.27.0 and the platform matches it to the
current build, so a security rebuild reaches you without anybody editing a
repository.
In vallic.yaml — what each one does is on Service settings:
services:
- golang:
version: '1.27.0'
environment:
GOMEMLIMIT: …
GOMAXPROCS: …
Anything not on this list refuses the deploy, naming the variable — rather than being accepted and quietly ignored.