It generates Go boundaries, while you keep the handlers
oapi-codegen reads OpenAPI 3.0 and 3.1 specifications and writes Go models, clients, or server boilerplate. The ordinary server interface receives an HTTP request plus parsed parameters. Strict mode goes further by generating request and response objects, typed status variants, and marshaling around a smaller business-logic method. The generated layer is deliberately verbose enough to inspect instead of hiding the contract behind a large runtime framework.
Server targets cover 9 documented choices: Chi, Echo, Echo v5, Fiber, Fiber v3, Gin, gorilla/mux, Iris, and the standard library's net/http. Generated code currently needs Go 1.24 or 1.25 depending on the chosen server. Client generation supports request editors and typed response parsing, while model-only generation is available when transport code belongs elsewhere.
The 40-second checked run was genuinely clean
Our sandbox installed 56 Go packages in 31 seconds, built commit 2679cec in 33 seconds, and passed all 6 reported test targets in 7 seconds. The repository contained 1,113 files, about 146,578 lines of source, and occupied 5.9 MB at checkout. It had 7 CI workflow files, no root Dockerfile, and no tests directory.
Those measurements came from a 3-CPU, 8 GB unprivileged Debian container with no secrets. The image supplied Go 1.24, and the measured commit completed successfully there. The current development README now says Go 1.25 or newer is required to build and install oapi-codegen. Teams pinning v2.8.0 or a newer commit should follow that documented toolchain floor rather than generalizing our commit-specific result.
What happened when we ran it
Our run finished install, build, and tests without an error. Installation took 31 seconds, the build took 33 seconds, and the tests took 7 seconds. Go reported 6 passed and 0 failed out of 6. Among these 4 repositories, this was the only run that both completed its test step and reported no failure.
A passing generator suite does not prove that every private specification produces correct code. The README describes edge cases around unions, imported references, additional properties, security, custom templates, and generated dependency versions. The useful next test is to run the pinned binary on your own largest specification, compile the result, compare the generated diff, and exercise request validation at the server boundary.
OpenAPI 3.1 support still meets Go's type limits
Version 2.8.0 added initial OpenAPI 3.1 support, including webhooks, nullability expressed through a type array, and enums built from oneOf plus const. A 3.1 union such as string, number, or boolean cannot be represented directly in Go, so the generator emits any. The README also says allOf duplicate fields are resolved by letting the last schema win rather than merging every property definition.
That mapping can become a compile failure in strict mode. Open issue 2525 demonstrates a response schema that lowers to any, after which the generator declares a method on an interface-backed type that Go rejects. Issue 2107 asks for allOf property merging because the current last-definition behavior loses inherited details in a JSON Merge Patch use case. Specifications using either shape deserve dedicated fixture tests before an upgrade.
Generated security needs your authentication function
An OpenAPI security scheme does not make the generated server secure on its own. The README states that server-side output has no security validation out of the box. Teams must add the appropriate request-validation middleware and provide an AuthenticationFunc that handles the named scheme and required scopes. Client code can use supplied security providers, but credentials still come from application configuration.
Strict server generation also omits incoming-request validation unless middleware is added. When strict output imports response or request-body components from another generated package, that destination must itself enable strict-server generation or the referenced envelope type will be missing. These constraints are documented, which is good, yet they belong in the starter template because forgetting either can leave a server uncompilable or insufficiently checked.
Pin the generator, schema, and runtime together
The project recommends managing oapi-codegen as a Go tool and invoking it through go:generate with a YAML configuration file. It also recommends pinning the JSON schema used by editor tooling to the generator version. Version 2.8.0 requires oapi-codegen/runtime v1.6.0 or newer for duration handling, escaped path parameters, and typed response headers. Updating only one piece can break generated code.
The maintainers recommend committing generated files. That makes a generator or specification change visible in code review and lets downstream users build a package without running the generator. CI should regenerate and fail when the committed output drifts. The README discourages applying a project's full linter policy to generated files, since the output aims for idiomatic Go but does not promise compliance with every lint rule.
Stable configuration surrounds intentionally unstable extension points
The command line and YAML configuration are classed as stable, and compatibility flags may preserve older generated behavior after a correctness fix. The promise is narrower for code generation than for a hand-written library. Template overrides can drift with their input context, and most imports under pkg are considered unstable apart from Generate and its related Configuration surface.
Release v2.8.0 illustrates the tradeoff. It requires Go 1.25 for the generator, updates the runtime floor, and changes trailing-slash routing in net/http output so a declared path no longer behaves as a subtree catch-all. The project had 8,547 stars and 318 combined issues and pull requests when fetched, with the last push on August 28, 2026. Active maintenance is clear, and so is the need to review regenerated code.
oapi-codegen is an easy recommendation for Go teams that want contract-first code without adopting a full application framework. Our clean 40 seconds of build and testing lower the cost of trying it. The deciding evidence should come from your own spec corpus, especially strict responses, allOf combinations, multi-type 3.1 unions, authentication, and external references.