Go - InstaPods

The Go preset compiles your source on the pod and runs the resulting binary as a systemd service. Unlike the interpreted presets, there is a real build step — your code is compiled on every deploy.

Available Versions

Version	Status
Go 1.25	Supported
Go 1.26	Default

Select a version when creating your pod. If not specified, Go 1.26 is used.

instapods pods create my-app -p go --version 1.25

What’s Included

Component	Version	Details
Go toolchain	1.25 or 1.26 (your choice)	Installed at `/usr/local/go`, on `PATH`
systemd	—	Process manager (`app` service)
git	Latest	Version control
SSH	OpenSSH	Access via dedicated port

Pre-installed utilities: curl, wget, vim, htop, unzip.

Directory Structure

/home/instapod/app/
├── go.mod
├── main.go             # package main
└── app                 # Compiled binary (this is what runs)

App Root: /home/instapod/app
App Port: 8080 (your app must listen on this port)
Binary: /home/instapod/app/app

How the App Service Works

Your Go app runs as a systemd service called app. It:

Runs the compiled binary /home/instapod/app/app directly (no interpreter)
Starts automatically on boot
Restarts on crash (on-failure policy)
Logs to the system journal
Runs as the instapod user

The service expects your app to listen on port 8080. Traffic from your pod’s public URL is proxied to this port.

Your app must bind to 0.0.0.0 (not localhost or 127.0.0.1) on port 8080, otherwise it won’t be reachable from the public URL.

The Build Step

Go is compiled, so uploading source files alone changes nothing — the previously compiled binary keeps serving until a new build succeeds. Both pods reload and a git deploy run:

go mod download          # when go.mod is present
go build -o app .        # produces /home/instapod/app/app

If the build fails, the deploy fails and returns the compiler error. Your previous binary keeps running, so a broken commit does not take your app down.

Main package outside the root

The default build target is the module root (.). If your package main lives elsewhere — a common layout is cmd/server — set a custom build command in the pod’s Git settings:

go build -o app ./cmd/server

The binary must always end up at /home/instapod/app/app, since that is what the service runs.

Deploying Your App

Upload and Reload

# Sync your project
instapods files sync my-go-app --local ./my-project

# Reload (compiles + restarts)
instapods pods reload my-go-app

Example App

// main.go
package main

import (
	"fmt"
	"net/http"
	"os"
)

func main() {
	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
	}
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintln(w, "Hello from InstaPods!")
	})
	http.ListenAndServe("0.0.0.0:"+port, nil)
}

// go.mod
module app

go 1.26

Background Workers

A Go program that is not a web server — a queue consumer, a bot, a scheduled job — works on this preset too. Because it never binds the web port, mark the pod as a worker so it isn’t health-checked as a website (otherwise its public URL returns 502 and the pod is flagged down). The Deploy Doctor detects this and offers a one-click convert to worker fix.

Plan Sizing

Compiling is the most memory-hungry thing a Go pod does — the link step in particular. New Go pods therefore default to the Build plan rather than Launch. A small service will run comfortably on Launch once built, but the compile itself may not fit.

Viewing Logs

instapods logs my-go-app -s app

Adding a Database

instapods services add my-go-app -s postgresql -w
instapods services creds my-go-app -s postgresql

Database services require the Build plan or higher.

Use Cases

HTTP APIs and microservices (net/http, Gin, Echo, Fiber, chi)
Background workers, queue consumers, and bots
Webhook receivers
CLI tools and scheduled jobs

Getting Started

Dashboard

Presets

Services

SSH & Files

Guides

Partners

Support

Go

Available Versions

What’s Included

Directory Structure

How the App Service Works

The Build Step

Main package outside the root

Deploying Your App

Upload and Reload

Example App

Background Workers

Plan Sizing

Viewing Logs

Adding a Database

Use Cases

​Available Versions

​What’s Included

​Directory Structure

​How the App Service Works

​The Build Step

​Main package outside the root

​Deploying Your App

​Upload and Reload

​Example App

​Background Workers

​Plan Sizing

​Viewing Logs

​Adding a Database

​Use Cases

Available Versions

What’s Included

Directory Structure

How the App Service Works

The Build Step

Main package outside the root

Deploying Your App

Upload and Reload

Example App

Background Workers

Plan Sizing

Viewing Logs

Adding a Database

Use Cases