Deploy Go on Nodion

Deploy Go step by step

1. Listen on PORT Nodion sets PORT for the web process; listen on it on all interfaces. Gin's r.Run() without an address already uses PORT. With Echo, Fiber or Chi, pass ":" + port yourself. main.go

   package main
   
   import (
   	"log"
   	"net/http"
   	"os"
   )
   
   func main() {
   	port := os.Getenv("PORT")
   	if port == "" {
   		port = "8080"
   	}
   	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
   		w.Write([]byte("ok"))
   	})
   	log.Fatal(http.ListenAndServe(":"+port, nil))
   }

2. One binary per cmd/ folder Without a cmd/ folder, Nodion builds the module root into one binary. Each cmd/<name> with Go files becomes its own binary instead, and the root package is then not built. The web process runs the only binary, else the one named server, api, web or app, else the first; every other binary becomes a process type of the same name.

   cmd/server/main.go
   cmd/worker/main.go
   cmd/migrate/main.go

3. Check the build settings Binaries build with CGO_ENABLED=0 and -ldflags "-s -w". If a dependency needs cgo, such as mattn/go-sqlite3, set CGO_ENABLED=1 with the Build flag on the Environment tab. A Build variable GOFLAGS_LDFLAGS replaces the ldflags, so include -s -w there if you want to keep them.
4. Create the app In the dashboard, create an application from your GitHub, GitLab, Bitbucket or Gitea repository, pick the branch and the region EU Central. Keep the build strategy on Buildpacks; if the repository has a Dockerfile, the form picks Dockerfile instead.
5. Attach PostgreSQL and run migrations Attach a database from the same region on the Environment tab; DATABASE_URL arrives on the next deploy, and PostgreSQL drivers such as pgx accept it as it is. Your binaries are on the PATH at runtime, so a cmd/migrate binary can run as the release step, once per build before the new version starts. Procfile

   release: migrate

Good to know

• Workers without a ProcfileA binary from cmd/worker becomes the process type worker. Add a process named worker without a port on the Processes tab and leave its command empty; it runs that binary. Name the web binary server, api, web or app so the web process does not pick another one.
• Always the newest GoThe go line in go.mod and a .go-version file do not select an older toolchain: every build uses the newest Go release Nodion has built. Run your CI against the newest Go as well.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Why We Built Our Own Buildpacks on Ubuntu 26.04 Our buildpacks follow the Cloud Native Buildpacks spec, but the stack, the language packs and the runtime versions are ours. Here is why.
• Dockerfile vs Buildpacks: Which One Should You Use? Both turn your code into a container image. What differs is who writes the build steps, and that decides control, maintenance and security updates.

Go on Nodion: questions and answers