# fukamachi/woo: A Non-Blocking Common Lisp HTTP Server > Woo is a beta-quality Common Lisp HTTP server built on libev for UNIX systems. It supports direct startup, Clack integration, worker processes, and optional HTTPS, with documented requirements and production warnings. **fukamachi/woo** — A fast non-blocking HTTP server on top of libev - Repository: https://github.com/fukamachi/woo - Website: http://ultra.wikia.com/wiki/Woo_(Kaiju) - Stars: 1,406 · Forks: 100 - Language: Common Lisp - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/fukamachi-woo ## Why Woo Exists in the Common Lisp Stack Woo targets developers who want an HTTP server that does not use a conventional blocking request model. Its README describes it as a fast, non-blocking Common Lisp server built on libev. The documented environment is specific: GNU Linux, Mac, and BSD systems are named, SBCL is the Common Lisp implementation, and libev must be available. OpenSSL or LibreSSL is optional when HTTPS is needed. Woo is not presented as a complete web application framework. The direct `woo:run` interface accepts a Lack app, so an application author needs to follow Lack's conventions for constructing handlers. Developers already using Clack can keep the application expressed as a Clack handler and select Woo through the server option. These interfaces support different integration choices, although both serve Common Lisp applications that return response lists. The README says Woo aims to be the fastest web server written in any programming language and points to `benchmark.md` for details. That is a project claim, not an independently established result in this review. The repository metadata also contains no GitHub releases, so a named release cannot be used as a stable upgrade target from the documented release history. This makes Woo most relevant to Common Lisp services that fit the Lack or Clack ecosystem. The README does not document HTTP/2, HTTP/3, WebSocket upgrades, streaming responses, request-size controls, access logging, virtual hosting, or a standalone routing layer. Its documented role is narrower: accept an application and provide the HTTP server process around it. ## Woo's libev and Worker Process Architecture The event-driven foundation is libev. Woo is written in Common Lisp but uses libev as its event foundation. The README does not expose the internal connection lifecycle, parser stages, buffer strategy, or event callback design, so those details are not confirmed. The response structure is visible in the examples. An application accepts an environment and returns a Common Lisp list. Its first value is the HTTP status, followed by headers and the response body. The simplest handler returns `200`, sets `:content-type` to `text/plain`, and supplies `Hello, World` as the body. This compact interface depends on Lack's conventions for converting the application return value into an HTTP response. Woo can run with multiple worker processes. Passing `:worker-num 4` to `woo:run` starts the documented example with four workers. The README does not explain work distribution, socket inheritance, load balancing, or worker replacement after a failure. It confirms only that the worker count can be supplied through this argument. Signal handling is documented for the master process. A `QUIT` signal requests graceful shutdown and waits for active requests to finish. `INT` and `TERM` cause immediate shutdown. This distinction affects deployment scripts, because an immediate signal does not provide the documented wait for outstanding requests. The README does not document shutdown timeouts or special handling for long-running requests. Another operational constraint is debugger mode. The README says debugger mode is on by default and can bring down the server after an internal error. It directs production users to pass `:debug nil`. The README does not describe the resulting HTTP error response, retry policy, diagnostic logging, or process supervision behavior. ## Installing Woo and Starting the First Server Woo expects a UNIX system, SBCL, and libev before the Common Lisp system can load successfully. Quicklisp is the documented installation path. In a Common Lisp REPL, load the system with this expression: ```lisp (ql:quickload :woo) ``` After Quicklisp loads Woo, the smallest direct example starts `woo:run` with a function that receives the request environment and returns a response list: ```lisp (woo:run (lambda (env) (declare (ignore env)) '(200 (:content-type "text/plain") ("Hello, World")))) ``` The response list contains the HTTP status, a header collection, and the body. The README does not give a port in this example, so a reader should not assume one. It also does not document a command-line executable, a service unit, a health endpoint, or a log location. A deployment with four worker processes uses the documented `:worker-num` argument: ```lisp (woo:run (lambda (env) (declare (ignore env)) '(200 (:content-type "text/plain") ("Hello, World"))) :worker-num 4) ``` Production deployments also need `:debug nil`. The README identifies that setting as necessary to avoid the documented debugger shutdown behavior. Because the README does not provide a production configuration file or a complete deployment command, the example remains a starting point rather than a full operations guide. ## Using Clack and Optional HTTPS Support Clack provides a different startup approach from calling `woo:run` directly. It abstracts the server behind `clack:clackup`, while `:server :woo` selects Woo. The documented example disables the default middleware set: ```lisp (ql:quickload :clack) (clack:clackup (lambda (env) (declare (ignore env)) '(200 (:content-type "text/plain") ("Hello, World"))) :server :woo :use-default-middlewares nil) ``` This route is relevant to applications already organized around Clack. Direct `woo:run` is the more specific interface for an application that does not need Clack's server abstraction. The README does not compare the behavior or performance of these two startup paths. Woo supports HTTPS through certificate, private-key, and optional password arguments. For direct startup, the documented shape is: ```lisp (woo:run app :ssl-cert-file #P"path/to/cert.pem" :ssl-key-file #P"path/to/key.pem" :ssl-key-password "password") ``` The README states that `clack:clackup` accepts the same SSL key arguments. Applications that do not need HTTPS can omit the CL+SSL dependency by adding `woo-no-ssl` to `cl:*features*` before loading Woo. The documentation does not specify certificate renewal, supported protocol versions, cipher policy, or client certificate verification. OpenSSL or LibreSSL is listed as an optional requirement. This means an HTTPS deployment must account for both Woo's Common Lisp dependencies and the system TLS library, while a deployment without HTTPS can avoid that optional SSL path. ## Limitations, Alternatives, and Maintenance The most direct limitation is the README's beta-quality warning. The repository is not archived, and its last push was on 2026-10-08. That date records recent repository activity, but it does not establish that the beta warning is obsolete or that production readiness has been declared. There are no GitHub releases in the repository metadata. The README does not provide a version pin, migration guide, changelog, or rollback procedure. Quicklisp is the documented acquisition method, but a deployment team cannot use a named GitHub release as its upgrade boundary based on the information shown here. The supported platform list is also narrow. GNU Linux, Mac, and BSD systems are named, while Windows is absent. SBCL is explicitly required. A Windows user or another Common Lisp implementation user therefore has no documented setup path in the README and should not treat the project as portable across every Common Lisp environment. Clack is a real integration alternative, not a competing HTTP server in this repository's documentation. Direct `woo:run` exposes Woo's server API; `clack:clackup` places Woo behind Clack's server-neutral interface. Lack is the application layer expected by Woo, while libev is the underlying event library. The README does not provide enough detail to compare their runtime costs or failure behavior. Woo is licensed under the MIT License. The repository includes `LICENSE.txt`, and teams using or modifying it should preserve the applicable license text. The README does not provide legal guidance or describe compatibility with linked components. Upgrade checks should focus first on SBCL and libev compatibility, then on the absence of a documented release and rollback path. ## Conclusion Common Lisp developers using SBCL, libev, Lack, or Clack should consider Woo after verifying its platform and dependency requirements. Developers needing a documented Windows path, GitHub releases, or rollback guidance should avoid it for now. The first adoption check is loading it through Quicklisp with `:debug nil`, then confirming that the intended HTTP response and graceful shutdown behavior fit the service. ## FAQ ### What does fukamachi/woo use for non-blocking event handling? Woo is built on libev. The README does not document the internal event callback or socket-handling details. ### How do I install fukamachi/woo? Install it through Quicklisp with `(ql:quickload :woo)`. The documented runtime requirements are a UNIX system, SBCL, and libev. ### Does fukamachi/woo support HTTPS? Yes. The README documents `:ssl-cert-file`, `:ssl-key-file`, and `:ssl-key-password` for both `woo:run` and `clack:clackup`. OpenSSL or LibreSSL is optional. ## Sources - [fukamachi/woo on GitHub](https://github.com/fukamachi/woo) - [Issues](https://github.com/fukamachi/woo/issues) - [License: MIT](https://github.com/fukamachi/woo/blob/master/LICENSE) - [Project website](http://ultra.wikia.com/wiki/Woo_(Kaiju)) - [README](https://github.com/fukamachi/woo/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fukamachi-woo