io_uring
Linux 5.10+Completion-based async I/O with multishot accept/recv, provided buffer rings and zero-copy sendfile. The lowest-latency path on modern kernels.
Fastest Go framework in 26/29 scenarios
High-performance
High-performance
HTTP for Go.
Celeris bypasses net/http with its own io_uring & epoll event loop —
a zero-allocation engine built for best-in-class throughput that stays fast
and stays up under extreme, sustained load, with the routing and middleware API you already know.
Built for extreme throughput
1.38M peak req/s · v1.5.8
1.2 ms Celeris p99 · v1.5.8
26/29
Go scenarios won
up to+109%
vs next framework
0
hot-path allocs
52
servers benchmarked
quickstart
Hello, world — in the API you know.
A familiar Gin/Echo-style surface over an engine that does the hard part. Handlers
return error; the rest is routing, groups and middleware.
$ go get github.com/goceleris/celeris@latest
- One import, one
Config— no codegen, no build tags - Runs the standard library's
http.Handlertoo - Linux gets io_uring/epoll; everything else gets a clean fallback
main.go
package main
import (
"log"
"github.com/goceleris/celeris"
)
func main() {
s := celeris.New(celeris.Config{Addr: ":8080"})
s.GET("/hello", func(c *celeris.Context) error {
return c.String(200, "Hello, World!")
})
log.Fatal(s.Start())
}The net/http ceiling is real.
Go's standard server is excellent — until a flood of traffic hits a syscall and scheduler wall and throughput plateaus. Celeris replaces the I/O layer with a completion-driven event loop that pushes throughput far higher and holds it steady under sustained, extreme load — while your handler code stays untouched.
01 · engines
Three engines. One port.
Pick a path — or let Celeris pick for you, live. Any protocol runs on any engine.
epoll
Linux 3.10+Edge-triggered, per-core event loops with CPU pinning. Proven, broad kernel support — and at throughput parity with io_uring.
adaptive
defaultRuns both engines and switches at runtime on live telemetry. You get the best path for the box without choosing one.
02 · what you get
Built for production, not just throughput.
Zero-allocation hot path
Pooled contexts, pre-encoded HPACK, inline param & handler buffers. No interface boxing on the critical path.
HTTP/1.1 + h2c
RFC-9112 H1 and full HTTP/2 cleartext with stream multiplexing, flow control and a zero-alloc HEADERS fast path.
SIMD parser
SSE2 (amd64) and NEON (arm64) request parsing with a SWAR fallback — and smuggling / rapid-reset hardening built in.
Batteries-included middleware
Auth, CORS, CSRF, rate-limit, circuit-breaker, compress, cache, metrics, OTel, WebSocket, SSE — production-ready, in-tree.
Familiar API
Route groups, hierarchical middleware, named routes and error-returning handlers. The Gin/Echo model you already know.
Graceful everything
Zero-downtime restart via socket inheritance, draining shutdown, load-shedding overload control and connection hooks.
routes.go
s := celeris.New(celeris.Config{Addr: ":8080"})
s.Use(recovery.New(), logger.New())
api := s.Group("/api")
api.GET("/users/:id", func(c *celeris.Context) error {
return c.JSON(200, store.Find(c.Param("id")))
})
// Blocking I/O? Move it off the event loop with .Async()
api.POST("/users", createUser).Async() 03 · ergonomics
Route, group, compose.
Hierarchical middleware, named routes, content negotiation and per-route async dispatch — choose inline-on-worker for CPU/cache routes, or a goroutine for blocking I/O.
- Static,
:paramand*wildcardroutes - Structured
HTTPError+ recovery - Streaming, SSE, WebSocket & hijacking
04 · benchmarked & validated
Numbers you can re-run.
probatorium benchmarks Celeris on a dedicated cluster — weekly and on demand — against a broad field of frameworks and scenarios; browse every result here, averaged across runs. Separately, nightly and weekend-soak validation hammers it with realistic traffic, fuzzing and connection & WebSocket torture.
Open the dashboard →1.38M
peak req/s · v1.5.8 · averaged over all runs