Build‑Time Plugin Architecture in Go: Leveraging Build Tags and go generate

Clarifying the Need for Dynamic Plugins

Many teams mistakenly assume that plugin systems require runtime dynamic loading, but most real‑world needs can be satisfied with compile‑time selection, allowing different environments to enable or disable capabilities without incurring runtime overhead.

Trim capabilities per environment

Enable modules per deployment

Keep plugins decoupled and independently evolvable

Core Go Features Used

Go provides two native mechanisms that are often underutilized:

1️⃣ Build tags – decide whether code is compiled

//go:build plugin_a
// +build plugin_a

2️⃣ go generate – generate source files that wire plugins together

//go:generate go run ./cmd/gen-plugins

Build tag controls existence; generate controls composition.

Desired Plugin System Characteristics

No direct dependencies between plugins

Plugins can be started or stopped independently

Registration is automatic, no manual maintenance

Build output is fully predictable

Practical Example – Controlling Plugins with Build Tags

1️⃣ Plugin implementation

// plugins/auth/auth.go
package auth

func Init() {
    // auth init logic
}

2️⃣ Build‑tag file that enables the plugin

// plugins/auth/auth_tag.go
//go:build plugin_auth
// +build plugin_auth

package auth

func Enabled() bool { return true }

If the tag plugin_auth is not supplied, this file is excluded from the build.

3️⃣ Building with selected plugins

go build -tags "plugin_auth plugin_metrics"

Unneeded plugins are omitted from the binary

Trimming happens at compile time, incurring no runtime cost

Automatic Registration via go generate

Problem with manual registration

func init() {
    auth.Init()
    audit.Init()
    metrics.Init()
}

Issues: missed registrations, uncontrolled order, high refactor cost.

Solution – Directory‑as‑rule generator

// cmd/gen-plugins/main.go
for each plugin dir {
    generate import + init call
}

The generator produces registry_gen.go:

// Code generated by gen-plugins. DO NOT EDIT.

func InitPlugins() {
    auth.Init()
    audit.Init()
    metrics.Init()
}

Triggering generation

//go:generate go run ./cmd/gen-plugins

Combining Build Tags and go generate

Plugin existence → build tag

Plugin composition → generate

Unified entry point for invocation

Pluginization is not about dynamism; it is about being cuttable, governable, and controllable.

Typical CI / Multi‑environment Usage

1️⃣ Build different capabilities per environment

# Internal environment
go build -tags "plugin_auth plugin_metrics"

# Minimal deployment
go build -tags "plugin_auth"

2️⃣ CI validation of generated code

go generate ./...
git diff --exit-code

When Not to Use Build‑Tag Pluginization

Plugin set changes at runtime

Need for hot‑load / hot‑unload

Highly coupled plugin logic

Build tags are suitable for product‑level trimming, not for runtime extension.

Three Hard‑Earned Rules for Plugin Systems

Plugins must not depend on other plugins

Expose only the minimal interface

The entire plugin set must be removable

Statically cuttable systems are often more reliable than seemingly flexible ones.

Conclusion

Go’s simplicity encourages a restrained plugin approach: use build tags to decide inclusion and go generate to assemble the system, resulting in predictable builds, controlled complexity, and a maintainable architecture.