Kit Series

Most Go HTTP services need the same operational pieces before the first real endpoint matters: probes, request IDs, access logging, panic recovery, graceful shutdown, JSON handling, and telemetry.

Servekit packages that baseline around net/http without replacing the standard library model. You still write normal handlers. Servekit owns the reusable HTTP service shell.

It is meant for APIs and microservices that should behave well from the first request, not after the first production incident.

Workers deserve a runtime, not just a goroutine.

Workerkit is for services where long-running workers are part of the system’s behavior, not incidental background code. A worker might poll an API, watch an external system, process domain events, seed data, run maintenance work, or expose operational commands.

The business loop stays ordinary Go. Workerkit provides the runtime around it: lifecycle control, readiness, graceful shutdown, worker-owned commands, status, and failure handling.

Workerkit is not a workflow engine, queue, scheduler, or application framework. The worker owns the domain. Workerkit owns the operational shell.

Configuration should become runtime state deliberately, not accidentally.

Configkit is for services where configuration is production state: typed values, source metadata, defaults, validation, redaction, checksums, reload attempts, status, inspection, and last-known-good behavior.

The application owns the config struct, source choices, validation rules, defaults, redaction policy, and business meaning. Configkit owns the reusable mechanics around loading, publishing, inspecting, and reloading that value.

Configkit is not a secrets manager, feature flag system, policy engine, or distributed configuration control plane. It keeps configuration ordinary Go and gives it a clear operational boundary.

Dependency health should be visible operational state, not scattered readiness logic.

Most services already know how to call their databases, caches, queues, APIs, storage systems, and control planes. What they often lack is a clean way to track which dependencies exist, which ones affect readiness, when they were last checked, what failed, and whether the current result is stale.

Dependkit gives services a dependency-health registry with application-owned checks, readiness policy, stale-state detection, last success and failure records, status snapshots, observer events, and optional Servekit, Workerkit, and OpenTelemetry adapters.

The application owns the clients, protocols, authentication, dependency definitions, and business behavior. Dependkit owns the reusable operational mechanics around dependency health and readiness.

Dependkit is not a service mesh, discovery system, load balancer, circuit breaker, retry layer, client framework, monitoring backend, or alerting system. It keeps dependency health ordinary Go and gives it a clear operational boundary.