SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Go New Added 10 September 2026

go: cannot find main module; see 'go help modules'

The command was run outside any module: there is no go.mod in the working directory or any parent. Since Go 1.16 module mode is the default, so a repository that once built from GOPATH, or a Dockerfile that copies sources without go.mod, fails here rather than falling back.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Where does Go think the module is
go env GOMOD          # /dev/null means no module was found
pwd && ls go.mod

# Start one, using the import path the repository will be fetched by
go mod init github.com/example/project
go mod tidy

# In a monorepo the go.mod may be a directory down
find . -name go.mod -maxdepth 3

# Dockerfile: copy the module files before the sources
COPY go.mod go.sum ./
RUN go mod download
COPY . .

# One off commands that need no module
go run github.com/example/tool@latest

How to diagnose Go errors

Go's runtime is unusually good at telling you what went wrong. concurrent map writes and all goroutines are asleep - deadlock! are precise diagnoses rather than vague crashes. The recurring themes are nil zero values that need explicit initialisation (maps, channels, pointers inside interfaces), unsynchronised shared state, and contexts that are cancelled upstream.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Run tests and, where possible, production builds under the race detector: go test -race ./.... It finds data races that are invisible under normal execution.
  2. Read the full panic output. Go prints every goroutine's stack, and the one that matters is usually not the first.
  3. For context canceled, walk up the call chain to find who cancelled: a client disconnect, a timeout, or a parent context that went out of scope are the three sources.
  4. Distinguish a nil interface from an interface holding a nil pointer. var p *T = nil; var i I = p makes i != nil, which is the cause of most "interface conversion: interface is nil" surprises.
  5. Use go tool pprof and runtime.NumGoroutine() to find goroutine leaks. A count that only ever grows means something is never returning.

Tools worth reaching for

  • go test -race
  • go vet
  • go tool pprof
  • GODEBUG=gctrace=1
  • delve (dlv)

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

go.dev

Related Go errors

See all 19 Go errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.