Standard Library First

A Go web toolkit that stays close to net/http.

Plumego is a stdlib-first toolkit for building explicit HTTP services in Go. Routing, middleware, transport contracts, and application wiring stay visible in code instead of being hidden behind framework conventions.

Get Started View Reference App

Go 1.24+
stable roots + x/* extensions
agent-friendly repo control plane

stable roots small public surface

core, router, contract, and the rest of the long-lived API stay narrow on purpose.

extensions optional capability families

x/* keeps fast-moving features out of the kernel and out of the default learning path.

reading path reference app → module boundary → extension family

Built for explicit services, not framework magic.

Each section below describes a deliberate repository choice: keep the HTTP model familiar, keep boundaries visible, and keep control-plane intent inspectable.

HTTP model

Stay on the standard library

Plumego keeps the net/http model intact so handlers, middleware, and tests remain familiar.

Ownership

Keep boundaries visible

Stable roots own narrow responsibilities. Fast-moving capabilities live under x/* instead of leaking into the kernel.

Workflow

Make repository intent legible

Docs, specs, manifests, and task cards make ownership easier to classify for both humans and coding agents.

One stable core, optional capability packs.

The public surface stays small on purpose. Stable roots define the long-lived API, while x/* families carry optional or faster-evolving features.

Stable Roots

Long-lived public packages with explicit responsibilities.

contract
core
router
middleware
security
store
health
log
metrics

x/* Extensions

Optional or faster-moving families that should not redefine the core path.

x/tenant
x/fileapi
x/messaging
x/gateway
x/rest
x/websocket
x/frontend
x/observability
x/resilience
x/data
x/ai

Default routing rule: kernel and transport changes stay in stable roots; capability work starts in the owning x/* family.

Start from one canonical path.

Begin with reference/standard-service. It shows the directory shape, bootstrap flow, and route wiring Plumego treats as the canonical application layout.

Read the Reference App Guide

bootstrap

Read main.go first

Confirm where the application starts and how the server is assembled.

wiring

Open internal/app/app.go

Inspect the app-local constructor and keep dependencies explicit.

routes

Finish in internal/app/routes.go

Check route registration before touching handlers or deeper modules.

reference/standard-service/
  main.go
  internal/app/app.go
  internal/app/routes.go
  internal/handler/health.go

Docs for humans. Specs for tools. Tasks for execution.

Plumego keeps prose, machine-readable rules, and execution cards separate so repository changes can stay inside explicit boundaries.

docs/

Explain intent, architecture, and the canonical path.

specs/

Carry machine-readable ownership, routing, and dependency rules.

tasks/

Define execution cards and milestone sequencing for change work.

Read the docs, inspect the reference app, then build your own service.

The shortest path into Plumego is to follow the documented reference flow first and only expand outward when the ownership boundary is clear.

Read Docs Open GitHub