Plugins and buildmode Pitfalls

Updated

September 8, 2026

Plugins and buildmode Pitfalls

Overview

buildmode=plugin looks like a dynamic extension story. In production it is usually a trap: brittle ABI, limited platforms, and operational pain. Prefer processes, Wasm, or explicit interfaces.

Diagram: Prefer process plugins

  need extension point?
       │
       ├── side process + RPC     (preferred)
       ├── Wasm sandbox
       └── buildmode=plugin       (fragile: skew, platforms)

Reality Check

Issue Detail
Platforms Not universal
Version skew Plugin must match main toolchain/deps closely
Dependency bloat Duplicated modules risk
Debugging Harder stacks and deploys
Security Loading code = trust boundary

Prefer Alternatives

  1. Side process + RPC (gRPC/HTTP) — isolation, language freedom
  2. Wasm plugins — sandboxing story
  3. Compile-time interfaces + separate binaries
  4. HashiCorp go-plugin style (subprocess) if you need polyglot

If You Must

go build -buildmode=plugin -o plug.so ./plug
# open via plugin.Open; lookup symbols

Pin exact Go version + go.mod policy; test load on the identical base image as production.

Experiment

Skip coding plugins by default. Instead document a design choice:

feature flag -> separate binary -> RPC
vs
plugin.Open

Write a 10-line ADR in your repo choosing RPC.

Try next: Read go help buildmode end-to-end once; note which modes you actually need (usually exe only).