# Hummingbird Swift HTTP Server: Routes, Middleware, and Setup

> Hummingbird is a Swift web framework built on SwiftNIO for developers who want routing, middleware, request and response coding, TLS, and HTTP2 without a large core dependency set.

**hummingbird-project/hummingbird** — Lightweight, flexible HTTP server framework written in Swift

- Repository: https://github.com/hummingbird-project/hummingbird
- Website: https://hummingbird.codes/
- Stars: 1,895 · Forks: 104
- Language: Swift
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/hummingbird-project-hummingbird

## The Problem Hummingbird Addresses in Swift Services

Hummingbird addresses the need for a server-side web framework that does not force a Swift application into a large collection of built-in services. It is intended for developers building HTTP applications, APIs, and services in Swift who want conventional endpoint routing while retaining access to the lower-level SwiftNIO execution environment. The README describes Hummingbird as lightweight, flexible, and modern, with a core designed to require the minimum number of dependencies.

The value is structural rather than domain-specific. A raw SwiftNIO application must establish how inbound bytes become HTTP requests, how URLs reach application code, and how returned values become HTTP responses. Hummingbird supplies that application-facing layer with a router, middleware, and custom request and response encoding or decoding. Optional concerns have a clear boundary. Authentication, Redis, FluentKit, WebSockets, AWS Lambda execution, background jobs, and Mustache templates are associated with separate repositories rather than presented as mandatory parts of the core.

That split is the central adoption choice. Hummingbird lets an application begin with a small server framework and add only the capabilities its design requires. It also means a feature such as authentication is not automatically available merely because the project is suitable for HTTP services. Each extra capability has its own package, version, and compatibility surface.

## Router-to-Handler Request Flow in Hummingbird 2

The README example exposes a direct request flow. A `Router` is created, a GET route named `hello` is registered with a closure, and the closure receives both a request and a second, unused argument before returning `String`. The router is then passed to `Application`, which also receives a configuration containing the bind address. Finally, `app.runService()` starts the service.

The returned `String` is important because it demonstrates application-level values rather than raw NIO channels. The README lists custom encoding and decoding for requests and responses, so handler results can be converted into HTTP output through the framework rather than by manually serializing every response inside the route. Request-side coding provides the corresponding mechanism for structured input. The README does not describe converter types or their default behavior in detail, so projects with binary payloads or custom media types should consult the reference documentation before assuming a particular format.

Middleware provides another stage around handlers. According to the README, middleware can process requests before they reach handlers and process responses returned by those handlers. This makes it relevant to cross-cutting behavior such as request processing and response handling, but the README does not supply a middleware ordering example or an error-mapping recipe. The repository also offers `HummingbirdRouter`, an alternative router based on result builders. That gives Hummingbird two router approaches without changing the underlying service model.

## Installing Hummingbird 2 with SwiftPM

The documented installation target is Swift 6.1 or later. For an existing Swift package, the README offers a command that adds the Hummingbird package from version `2.0.0`. Replace `MyApp` with the executable target already present in the package. The command modifies the package configuration rather than installing a separate server binary.

```swift
swift package add-dependency https://github.com/hummingbird-project/hummingbird.git --from 2.0.0
swift package add-target-dependency Hummingbird MyApp --package hummingbird
```

After these commands, `Package.swift` should contain the Hummingbird dependency and the `Hummingbird` product as a dependency of the application target. The dependency floor is `2.0.0`, while the recent release information lists `2.28.0` as the newest published release. Those are different version constraints. The former means the resolver may select a compatible 2.x release, not that the README requires exactly `2.28.0`.

Applications that manage `Package.swift` directly can add the same package and product manually. The README shows this package dependency form:

```swift
dependencies: [
    .package(url: "https://github.com/hummingbird-project/hummingbird.git", from: "2.0.0")
],
targets: [
  .executableTarget(
    name: "MyApp",
    dependencies: [
        .product(name: "Hummingbird", package: "hummingbird")
    ])
]
```

This is SwiftPM configuration inside `Package.swift`, not a shell command. The project documentation also points to the `hummingbird-examples` repository for additional application structures.

## Starting a Real Hummingbird HTTP Service

A first service can stay close to the README example. Add an executable source file to the target configured with the Hummingbird dependency, then create one route and run the application. The configuration binds to `127.0.0.1` on port `8080`, which limits the listener to the local machine.

```swift
import Hummingbird

let router = Router()
router.get("hello") { request, _ -> String in
    return "Hello"
}

let app = Application(
    router: router,
    configuration: .init(address: .hostname("127.0.0.1", port: 8080))
)

try await app.runService()
```

The route name is `hello`. The README comment describes this as a GET route, so a client can address it using the route at the configured host and port with the corresponding `/hello` path. The handler returns the string `Hello`; Hummingbird's response coding layer is responsible for turning the application return value into an HTTP response.

The listener address deserves attention before copying the example. A hostname bound to `127.0.0.1` is a local demonstration, not a documented public deployment configuration. The README does not provide commands for container execution, reverse proxies, production process management, graceful shutdown, or environment-based binding. Those deployment details must therefore come from the project documentation or an application-specific setup rather than an assumed modification to this example.

## TLS, HTTP2, Testing, and External Hummingbird Packages

Hummingbird separates several common server requirements from its core. `HummingbirdTLS` supplies TLS support, `HummingbirdHTTP2` supplies HTTP2 upgrade support, and `HummingbirdTesting` provides helper functions for testing Hummingbird projects. Their separate extension names make the packaging decision visible in application dependencies and imports.

Other capabilities are maintained as separate repositories. `HummingbirdAuth` provides authentication, `HummingbirdRedis` integrates Redis through RediStack, and `HummingbirdWebSocket` adds WebSocket support. `HummingbirdFluent` provides an integration with Vapor's FluentKit ORM. `HummingbirdLambda` runs a Hummingbird application on AWS Lambda, while the separate `Jobs` project provides a job queue framework and `Mustache` provides a Mustache templating engine.

This design avoids turning every capability into a mandatory dependency, but it also creates package selection work. A service that needs authentication, persistence, Redis, and WebSockets is not limited to the core repository. The README does not state how these packages are version-pinned against the Hummingbird release, so compatibility should be checked in each extension's own package metadata before the main dependency set is approved.

## When a Lower-Level SwiftNIO Service Is the Better Choice

A direct SwiftNIO server is the clearest alternative because Hummingbird itself runs on a SwiftNIO-based implementation. The difference is the abstraction level. Hummingbird supplies a web application router, middleware hooks, handler-facing request values, and response coding. A direct SwiftNIO implementation keeps the application closer to channels, protocol handlers, byte buffers, and the server pipeline. That approach can fit code whose transport or protocol design is already expressed at NIO level, but the README does not document a specific lower-level Hummingbird configuration for bypassing those abstractions.

There are also functional boundaries. Hummingbird is the wrong choice for an application that expects all standard web facilities to ship in one repository. WebSockets, Redis, database integration, authentication, jobs, and Lambda deployment are all separate packages according to the README. A team unwilling to manage that extension graph may prefer a framework whose selected application features are available as one integrated distribution, although the README does not compare dependency graphs or release coordination for another framework.

Another unsupported case is a developer seeking a hosted, managed service. Hummingbird is a library framework embedded in a Swift application. The examples control configuration through Swift code, and the README does not prescribe a hosting provider or a production runtime service.

## Maintenance Signals and Apache-2.0 Upgrade Work

The repository is not archived. Its last push was on 2026-10-13, and the release information lists versions `2.28.0`, `2.27.1`, and `2.27.0` on 2026-10-13, 2026-10-09, and 2026-09-21 respectively. These facts indicate recent code and release activity, but they do not by themselves establish long-term compatibility policy or the support window for any release line.

Hummingbird is licensed under Apache-2.0, with the license and notice files stored at `LICENSE.txt` and `NOTICE.txt`. Apache-2.0 is a permissive open source license, but this review does not provide legal advice. An adopting organization still needs to account for the license text, copyright and notice requirements, dependency licenses, and its own distribution practices. Separate extension packages also need their license checks rather than inheriting a conclusion from this repository alone.

Upgrades involve more than changing one package string when an application adopts extensions. The core package is resolved from `2.0.0` or later within its permitted compatibility rules, while authentication, persistence, Redis, WebSocket, deployment, jobs, and template packages may have their own release constraints. The repository contains tests, CI configuration, contribution documentation, security documentation, and a Dockerfile. The Dockerfile builds with `swift:6.4`, resolves dependencies, copies the repository, and executes `swift test --sanitize=thread`. It is a contributor and CI-oriented build definition, not a documented production application image.

## Conclusion

Hummingbird is a practical fit for Swift developers who want direct control over routing and middleware on SwiftNIO. It is a weaker choice when an application needs capabilities available mainly through separate packages, or when adopting another server architecture would remove more complexity than Hummingbird introduces. Before adoption, verify the required Hummingbird extension, the Swift 6.1 or later requirement, the deployment model, and the Apache-2.0 obligations that apply to the project.

## FAQ

### What is Hummingbird used for in Swift?

Hummingbird is used to build server-side Swift HTTP applications on top of SwiftNIO. It provides endpoint routing, middleware, and request and response coding, with capabilities such as TLS, HTTP2, and testing provided through extensions.

### How do I install Hummingbird in a Swift package?

The README documents adding the package from `2.0.0` and adding the `Hummingbird` product to the application target with SwiftPM. It also shows the equivalent package configuration for direct editing of `Package.swift`.

### Does Hummingbird include Redis, authentication, and WebSockets in its core?

No. The README lists `HummingbirdRedis`, `HummingbirdAuth`, and `HummingbirdWebSocket` as separate repositories. An application must evaluate and add those packages when it needs those capabilities.

## Sources

- [hummingbird-project/hummingbird on GitHub](https://github.com/hummingbird-project/hummingbird)
- [License: Apache-2.0](https://github.com/hummingbird-project/hummingbird/blob/main/LICENSE)
- [Project website](https://hummingbird.codes/)
- [README](https://github.com/hummingbird-project/hummingbird/blob/main/README.md)
- [Releases](https://github.com/hummingbird-project/hummingbird/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hummingbird-project-hummingbird