Apache Traffic Server: CDN caching proxy with no prebuilt releases on GitHub

Forward proxy, reverse proxy and CDN cache in one daemon

Apache Traffic Server covers three deployment shapes that operations teams often run as separate services. As a reverse proxy, it sits in front of origin servers and handles requests before they reach the backend, optionally caching responses so the origin does not have to answer every client directly. As a forward proxy, it routes outbound HTTP traffic from clients to external destinations through a single monitored point. In CDN cache mode, responses from upstream servers are stored and served to later clients, removing the need for another round-trip to the origin when a fresh copy is already held. All three modes are first-class targets: the repository topics list forwardproxy, reverseproxy and cdn together, alongside http2, http3 and quic.

Its own description calls the project a high-performance building block for cloud services. That framing points at infrastructure teams operating at the edge of a large network, not at teams looking for the simplest way to terminate TLS in front of a few services. A plugin API extends that scope: according to the description, ATS has support for plugins to build large scale web applications, so custom behavior can be compiled into the proxy process itself rather than living in a separate layer.

License is Apache-2.0, which permits commercial deployments without royalty obligations to the Apache Software Foundation.

HTTP/2 is in the description; HTTP/3 and QUIC appear only in the repository topics

The project description says Traffic Server is HTTP/1.1 and HTTP/2 compliant. Going a step further, the repository topics include http3 and quic, indicating HTTP/3 over QUIC is part of the codebase even if the formal description has not been updated to say so.

HTTP/2 and HTTP/3 use different transports. HTTP/2 runs over TCP and uses HPACK for header compression. Inside lib/, the repository bundles ls-hpack, a third-party HPACK compression library, showing the HTTP/2 header path is implemented in-tree. HTTP/3 runs over QUIC, which is UDP-based, and uses QPACK for compression rather than HPACK.

Another bundled library, highway, provides portable SIMD and vector intrinsics. It sits in lib/ alongside ls-hpack, fastlz and yamlcpp. Highway lets the codebase use CPU vector instructions for data-intensive operations without scattering platform-specific intrinsic calls through the source.

Supporting multiple protocol versions at a single entry point matters for an edge cache. A client on HTTP/1.1 and a client on HTTP/3 can send requests to the same Traffic Server instance, and the proxy has to negotiate each connection's protocol during the TLS handshake.

Version 10 dropped autotools for cmake, and out-of-source builds are required

The README opens its developer section with a clear statement: as of version 10, ATS has transitioned to cmake as its build system. That version boundary matters. Anyone working with an older branch will find that the cmake instructions do not describe the build process for it.

A cmake build puts compiled output in a separate directory. All examples in the README use build as that directory name. Configuring with defaults:

cmake -B build

To set a custom install prefix or include experimental plugins at build time:

cmake -B build -DCMAKE_INSTALL_PREFIX=/tmp/ats -DBUILD_EXPERIMENTAL_PLUGINS=ON

Building all targets after configuration:

cmake --build build

To build only the traffic_server binary and skip the rest:

cmake --build build -t traffic_server

Installing after a clean build:

cmake --install build

The test suite runs through ctest. Move into the build directory and run ctest to exercise the regression tests. Build system module files live under cmake/ in the source tree. ccmake, when installed, gives an interactive interface to the same cache variables without requiring all flags on the command line.

CMakePresets.json groups configuration into named presets for repeatable builds

Traffic Server ships CMakePresets.json in the repository root to group build configurations into named presets. A named preset lets a developer invoke a full configuration with a short name:

cmake --preset dev

For a custom setup, create CMakeUserPresets.json in the same directory and inherit from entries in CMakePresets.json. The example in the README defines a user preset that inherits from both a clang preset and the dev preset:

{
  "name": "mydev",
  "displayName": "my development",
  "description": "My Development Presets",
  "binaryDir": "${sourceDir}/build-dev-clang",
  "inherits": ["clang", "dev"]
}

With that file present:

cmake --preset mydev

The binaryDir field in the example is ${sourceDir}/build-dev-clang rather than the default build/, so multiple preset builds can coexist on one machine without their output interfering. The README suggests starting a user presets file by copying CMakePresets.json and removing all entries from the configurePresets array before writing custom ones.

Allocators, LuaJIT and OpenSSL each follow different cmake variable conventions

Three memory allocators are selectable at configure time: ENABLE_JEMALLOC, ENABLE_MIMALLOC and ENABLE_MALLOC_ALLOCATOR. The example user preset in the README sets ENABLE_JEMALLOC to true and ENABLE_MALLOC_ALLOCATOR to true, while leaving ENABLE_MIMALLOC false. These are compile-time choices, not runtime switches, so a binary has its allocator baked in at build time.

External dependencies outside the system search paths follow a _ROOT naming convention, with one exception. Pointing cmake at a custom jemalloc installation and a custom OpenSSL build:

cmake -B build -Djemalloc_ROOT=/opt/jemalloc -DOPENSSL_ROOT_DIR=/opt/boringssl

The README explicitly calls out that OpenSSL breaks the pattern: its variable is OPENSSL_ROOT_DIR, not openssl_ROOT, and failing to use that name causes cmake to look in the wrong location. The example supplies BoringSSL as the value, confirming the variable accepts drop-in forks.

LuaJIT appears as a fourth compile-time option, ENABLE_LUAJIT, which the example preset sets to false. The README does not describe what it activates inside Traffic Server, so its role in the proxy is undocumented at the source level. Its presence as an opt-in flag rather than a required dependency means a build that omits it is still complete.

Tracking which combination of allocator flags was used matters in production: two binaries built from the same source commit can behave differently under memory pressure if they used different allocators.

Stable and experimental plugins live in separate directories with separate build flags

Two directories hold plugins in the source tree. plugins/ contains the stable, core plugins. plugins/experimental/ holds ones that have not yet reached stable status. Building the experimental directory is opt-in: the BUILD_EXPERIMENTAL_PLUGINS cmake variable must be set to ON, as shown in the configure step covered earlier. Without that flag, cmake skips the experimental directory entirely.

The example/ directory at the top level sits apart from both: it holds example plugins for developers learning the API, and it is the entry point the developer documentation references.

The distinction between stable and experimental is expressed through directory layout rather than a runtime switch. An operations team evaluating an experimental plugin has to build it in, track how it interacts with the rest of the proxy, and accept that its interface may change.

Plugin development documentation lives under doc/developer-guide in the source tree. That section appears in the layout alongside doc/admin-guide, Graphviz source diagrams under doc/dot, and UML diagrams under doc/uml. doc/developer-guide is the starting point before writing a new plugin or auditing an experimental one.

No GitHub releases, and the CI matrix names eleven specific platforms

The repository has no GitHub releases. No binary artifact or versioned archive is attached to any tag on GitHub, so building from source is the documented path. Version information lives in the cmake configuration rather than in a release entry. Teams that require an immutable artifact tied to a specific version have to build it themselves or use what the Apache Traffic Server project distributes through its own infrastructure at trafficserver.apache.org.

The CI matrix is visible in the badge list at the top of the README: CentOS 7, Debian 11, Debian 12, Fedora 39, Fedora 40, FreeBSD, macOS, macOS arm64, Rocky Linux 8, Rocky Linux 9 and Ubuntu 22.04 each have a dedicated Jenkins job at ci.trafficserver.apache.org. A platform absent from that list has no project-maintained evidence that a cmake build succeeds on it. Windows does not appear in the matrix.

The last push to the master branch was on 2026-10-06. The repository is not archived.

One structural note: the repository root contains a memory-bank/ directory labeled as AI assistant context documentation. That directory does not appear to affect the build or the installed artifact.

When Traffic Server is the wrong fit and what simpler tools cover instead

Traffic Server is built for cases where a proxy must cache at CDN scale, handle multiple HTTP protocol versions simultaneously and run plugins compiled into the same process. Teams with narrower requirements will find the build process and configuration surface larger than their problem needs.

For a team that wants only TLS termination and basic reverse proxying in front of a small set of backends, tools like Nginx ship as prebuilt packages for most Linux distributions and require no source compilation at all. Those tools do not replicate the CDN-oriented caching semantics, HTTP/3 and QUIC support, or in-process plugin API that Traffic Server describes. Where they offer binary availability and a smaller configuration surface, ATS trades that simplicity for a fuller caching and protocol stack.

The plugin architecture marks the clearest separation. If custom logic must run inside the proxy process (to inspect or rewrite headers, route requests by content, or handle authentication at the edge), the ATS plugin API provides that in a way that requires no external process. For setups that do not need any of that, starting with a simpler tool avoids the source build and the heavier configuration surface from the start.

Editorial conclusion

Apache Traffic Server suits teams building CDN edge infrastructure that requires HTTP/1.1, HTTP/2 and HTTP/3 support alongside a plugin API for custom logic inside the proxy process. Avoid it when prebuilt binaries are required or when a simple TLS-terminating reverse proxy is the whole job: the build-from-source path and the configuration surface are heavier than that use case needs. Before deploying, confirm that your target platform appears in the CI matrix (CentOS 7, Debian 11, Debian 12, Fedora 39, Fedora 40, FreeBSD, macOS, Rocky Linux 8, Rocky Linux 9 or Ubuntu 22.04), and consult the admin-guide under doc/ for the specific deployment topology you plan to run.

Frequently asked questions

Official sources

1. apache/trafficserver on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README