Servekit's examples are a guided tour, not a random pile of demos. Start with the shortest useful service, then see the shared Opskit composition path before moving outward into telemetry, route-level policy, lifecycle, customization, and raw HTTP escape hatches.
If you want the short directory index instead, use Servekit Examples.
The examples/ directory includes a guided index, and the source comments in each example main.go explain the key ideas in place.
This is the first example to read.
It shows the main Servekit promise in one place:
NewHandleRun- built-in operational endpoints
- JSON encoding, IDs, access logs, and panic recovery by default
- built-in OTel middleware that uses application-owned global providers
If this example does not feel compelling, the rest of the package probably will not either.
This is the smallest Kit Series presentation example.
It shows:
- one application-owned Opskit registry
- required and informational component registration
- Opskit-backed
/readyz - authenticated
/admin/componentsinventory - authenticated
/admin/components/{name}status and inspection snapshots - cached readiness state changing without an active check on the probe path
The example imports only Servekit and Opskit. Domain kits join this surface by implementing Opskit contracts and being registered by the application; Servekit never needs to know which package produced a component.
This is the canonical single-service composition for the currently available kits.
It shows:
- typed Configkit state registered with Opskit
- cached Dependkit readiness refreshed by a Workerkit check-group loop
- Workerkit runtime state registered with the same Opskit registry
- Servekit
/readyzand authenticated/admin/componentspresentation - one small application route reading current typed configuration
- explicit Workerkit startup and shutdown around the Servekit server
- active Workerkit HTTP controls intentionally left to focused Workerkit examples
The example has its own nested Go module so the sibling kits do not appear in
Servekit's published module graph. Its local replace directive builds against
the checked-out Servekit source, and repository verification tests both modules.
Shows the stronger telemetry story directly:
- global tracer and meter providers
- process-wide stdout exporters used only by this example
- request spans through Servekit's default OTel middleware
- request metrics through Servekit's default OTel middleware
- server connection metrics on the
Run(...)path
Read this when you want proof that Servekit's telemetry story is real, not just configurable.
Shows the custom-middleware and route-level policy story:
WithMiddleware(...)WithAuthCheck(...)WithAuthGate(...)WithEndpointMiddleware(...)WithBodyLimit(...)WithEndpointTimeout(...)- route-local observability suppression
Read this when a service mostly wants the default server but needs a little application-owned global policy and a few routes with different local behavior.
Shows how a service can keep the Servekit model while enforcing a custom response contract:
- global success encoder override
- global error encoder override
- per-endpoint success encoder override
HTTPError-based status control
Shows the standalone lifecycle story for a small service without Opskit:
- a lightweight readiness predicate over local state
- explicit warmup behavior
- custom
/healthz - shutdown drain delay
Shows the logging story:
- custom
sloglogger - explicit
http.Server.ErrorLog - request ID access from context
- panic recovery behavior
Shows opt-in browser integration:
WithCORSConfig(...)- preflight behavior
- actual CORS response headers
- credentialed origin allowlists
Shows how Servekit composes with pre-existing HTTP infrastructure:
WithMux(...)Handler()- externally owned
http.Server - explicit
SetReady(...)
This is one of the most important advanced examples because it proves Servekit does not have to own the full runtime.
Shows what a more heavily customized Servekit service can still look like without abandoning the main model:
- custom success and error encoders
- custom
slogandhttp.Server.ErrorLog - standalone local readiness predicates and explicit readiness control
- custom
/healthz - CORS config
- telemetry provider and labeling overrides
- global middleware plus route-level overrides
- one raw
HandleHTTP(...)route inside the same service
This is the late-stage reference example to read when you want to see many advanced hooks composed together in one runnable program.
Shows why HandleHTTP exists for streaming:
- server-sent events
http.Flusher- long-lived response flow
This is the dedicated example to read if you want to see http.Flusher used through Servekit's raw handler path.
Shows proxy-style raw handler integration:
httputil.ReverseProxy- request rewriting
- response rewriting
- upstream error handling
Shows one of the package's subtler implementation details:
- implicit
200capture when handlers never callWriteHeader - response byte counting for logs and metrics
- preserved
http.Flusher - preserved
http.Hijacker
This example is less about "how to build an app" and more about "why the raw Servekit path is technically credible." It also contains the concrete http.Hijacker route in the example set.
Run ordinary examples directly from the repository root with:
go run ./examples/<name>
# for example
go run ./examples/basic
go run ./examples/operations
go run ./examples/endpoint-controls
go run ./examples/streamingThe telemetry and Kit Series composition examples use isolated modules to keep application-only dependencies out of Servekit's root module graph:
go -C examples/telemetry run .
go -C examples/kit-series-composition run .Each example prints suggested curl commands on startup.