first commit

Dockerfile

@@ -0,0 +1,50 @@
+# ---- Stage 1: build ----
+# This stage has the full Go toolchain and is only used to compile the
+# binary. It is discarded entirely after the build - none of its ~800MB+
+# footprint ends up in the final image.
+FROM golang:1.26 AS builder
+
+WORKDIR /app
+
+# Copy just the module files first and download dependencies before
+# copying the rest of the source. Docker caches each instruction as a
+# layer; as long as go.mod/go.sum don't change, this layer (and the
+# downloads it triggers) is reused on every subsequent build, even if
+# application code changes constantly. If we copied all source first, any
+# code edit would invalidate this cache and force a full re-download every
+# single build.
+COPY go.mod go.sum* ./
+RUN go mod download
+
+COPY . .
+
+# CGO_ENABLED=0 produces a fully static binary with no dynamic library
+# dependencies, which is what lets it run on the minimal Alpine base image
+# in stage 2 below without missing shared libraries. GOOS=linux ensures we
+# cross-compile for Linux even if you're building this image on macOS or
+# Windows.
+RUN CGO_ENABLED=0 GOOS=linux go build -o /app/bin/server ./cmd/api
+
+# ---- Stage 2: run ----
+# A tiny (~7MB) base image that receives ONLY the compiled binary from
+# stage 1 - no compiler, no source code, no build tools. Smaller image,
+# smaller attack surface.
+FROM alpine:3.20
+
+# Alpine's minimal base doesn't include root CA certificates by default.
+# Without these, any outbound HTTPS call this app makes (Google's OAuth2
+# token exchange and userinfo endpoints) would fail with a certificate
+# verification error. --no-cache avoids leaving package-manager cache
+# files behind in the image.
+RUN apk add --no-cache ca-certificates
+
+WORKDIR /app
+
+# Pull just the compiled binary out of the builder stage - this is the
+# actual multi-stage mechanism: --from=builder reaches back into the FIRST
+# image just for this one file.
+COPY --from=builder /app/bin/server .
+
+EXPOSE 8080
+
+CMD ["./server"]