Configuration Options

Plumego does not define a global configuration system.

This is intentional.

Instead of prescribing how configuration should be loaded,
Plumego defines what configuration it consumes — and leaves the rest to the application.

This document describes:

• Which configuration values Plumego cares about
• Where those values are expected to be applied
• What Plumego explicitly ignores

Design Contract

The configuration contract is simple:

Plumego consumes configuration only at construction and wiring time.
It never reads configuration implicitly at runtime.

Implications:

• No environment variables are read by Plumego
• No global config registry exists
• No hot-reload mechanism is assumed
• No runtime lookups occur inside handlers

All configuration must be loaded and injected explicitly by the application.

Configuration Scope

Plumego configuration applies only to:

• Application setup
• Middleware construction
• Router behavior
• Response helpers (minor defaults)

Plumego does not consume configuration for:

• Business logic
• Authorization rules
• Validation policies
• Persistence schemas
• External service credentials

Those belong to application and infrastructure layers.

App-Level Configuration

The Plumego App itself accepts no mandatory configuration.

Construction is explicit and minimal:

app := plumego.New()

Optional behavior is introduced via:

• Middleware
• Router registration
• Explicit helpers

There is no hidden “app config” object.

HTTP Server Configuration (External)

HTTP server configuration is explicitly outside Plumego.

Examples include:

• Listen address
• TLS settings
• Timeouts
• Max header size

These are applied to http.Server, not to Plumego:

server := &http.Server{
	Addr:         cfg.HTTP.Addr,
	ReadTimeout:  cfg.HTTP.ReadTimeout,
	WriteTimeout: cfg.HTTP.WriteTimeout,
	Handler:      app,
}

Plumego never reads or modifies these values.

Middleware Configuration

Middleware is the primary consumer of configuration.

Typical configurable middleware includes:

• Logging
• Authentication
• Rate limiting
• CORS
• Timeouts
• Tracing

Pattern:

logger := NewLogger(cfg.Logging)

app.Use(
	LoggingMiddleware(logger),
	AuthMiddleware(cfg.Auth),
)

Rules:

• Configuration is injected at middleware construction time
• Middleware behavior does not change at runtime unless explicitly designed to
• Middleware must not read global configuration

Router-Related Configuration

Plumego routing has no runtime configuration.

Routes are defined in code:

app.GET("/health", HealthHandler)

There are no supported configuration options for:

• Route discovery
• Auto-registration
• Convention-based routing
• Dynamic route loading

If routing behavior changes, code must change.

Context Configuration

The Plumego Context has no configuration.

It is constructed per request and contains:

• Request
• Response writer
• Request-scoped storage

Context behavior must not depend on environment or configuration values.

Any behavior change must happen before Context creation, via middleware.

Response Helper Defaults

Response helpers (such as ctx.JSON) may apply minor, documented defaults, such as:

• Content-Type header
• Character encoding

These defaults:

• Are deterministic
• Are not configurable globally
• Can be overridden manually in handlers

Example:

ctx.ResponseWriter().Header().Set("Content-Type", "application/custom+json")

Plumego does not provide response configuration knobs.

Unsupported Configuration Patterns

The following patterns are explicitly unsupported:

Global Config Access

plumego.GetConfig()

No such API exists and will not be added.

Environment Variable Lookups Inside Framework Code

Plumego never calls os.Getenv.

Runtime Configuration Mutation

Changing framework behavior mid-request via config is undefined behavior.

Implicit Defaults Based on Environment

There is no “production mode” or “debug mode” in Plumego.

If behavior differs by environment, it must be wired differently.

Configuration Validation

Configuration validation is the responsibility of the application.

Plumego assumes:

• Configuration is valid when passed in
• Invalid configuration should fail at startup
• Runtime errors are not configuration errors

This keeps framework behavior simple and predictable.

Configuration and Testing

Because configuration is injected explicitly:

• Tests can construct minimal configs
• No environment mocking is required
• Behavior is deterministic

Example:

cfg := Config{
	Auth: AuthConfig{
		Enabled: false,
	},
}

Tests should never depend on real environment variables.

Configuration and Multiple Plumego Apps

When embedding or running multiple Plumego apps:

• Each app should receive its own configuration slice
• Shared config should be passed explicitly
• No global config should be assumed

This avoids cross-app coupling.

Summary

Plumego’s configuration model is defined by what it refuses to do:

• No global config
• No environment lookups
• No runtime mutation
• No implicit defaults

Instead:

• Configuration is loaded by the application
• Injected explicitly
• Applied at construction time
• Visible in wiring code

If behavior is not visible in wiring,
it is not part of Plumego’s configuration model.

Related Reference Pages

• App — application construction and wiring
• Middleware — configurable execution behavior
• HTTP Server — server-level configuration (external)

This page defines the limits of configuration —
and those limits are what keep Plumego predictable.