Velocity Engine 1.8.0 is our production-maturity release. Every visitor gets the page meant for them, every purge lands, and the proxy stays inside the limits you give it, with integrations for Magento, Shopware, Sylius, WooCommerce, PrestaShop, Symfony, Laravel, Django and Rails.
Magento
Shopware
Sylius
WooCommerce
PrestaShop
Symfony
Laravel
Django
RailsWhy 1.8.0
Velocity Engine 1.8.0 doesn't add one headline feature. It makes everything Trident already does correct under real traffic, and brings the same guarantees to every platform and framework you build on.
A cache proxy earns its place by being invisible. Shoppers get fast pages, merchants see their changes straight away, and nobody has to wonder whether the page a visitor saw was meant for them. For 1.8.0 we went through every part of Trident with that bar in mind (cache identity, purges, request coalescing, resource limits, configuration and packaging) and fixed everything that didn't meet it.
Then we tested it harder than any release before: more than 289 million HTTP requests across our qualification runs, 13,050 automated tests, and a continuous 72-hour endurance campaign.
The right page for every visitor
Cache identity now follows exactly what your application sees. Cookie names are matched exactly, so a cookie your framework reads under another spelling can't slip past the cache key. Explicit Host ports and the scheme your trusted edge forwards are part of the key, so HTTP and HTTPS, or two ports on one host, never share a page.
Query strings get the same care. The order and repeats of values under one parameter now count, because many applications answer ?sort[]=price&sort[]=name differently from its reverse. Where order really doesn't matter, the new per-parameter schemas tell Trident so, and you win the hit rate back:
[cache.key.params]
# facet: order and repeats don't matter
"color" = { kind = "set" }
# sort selector: only the last value counts
"product_list_order" = { kind = "singleton" }
# signature: keep the bytes exactly
"sig" = { kind = "raw" }
# campaign tracking: not part of the key
"utm_*" = { kind = "noise" }When a request carries something the key can't represent safely, such as an ambiguous cookie or an unkeyed forwarding header, Trident passes it to the origin and tells you why in X-Trident-Why. A shared page is never a guess.
Purges that always land
A purge that never arrives is worse than no cache: the old price stays up and nobody notices. In 1.8.0 our integrations deliver purges through a durable outbox. Each purge is written in the same database transaction as the change that caused it. It counts as delivered only when Trident acknowledges it, and it's retried with backoff until then. A token rotation, a restart or a network blip no longer loses an invalidation.
- Several Trident instances. Every purge goes to each configured instance and is tracked per instance.
- Purges block fills in flight. Tag, wildcard and regex purges bar responses whose origin fetch started before the purge, so purged content can't come back as fresh.
- Complete tags or no cache. A response whose tags were cut off is served uncached rather than stored where a purge can't reach it. The default limit rises to 200 tags per entry.
- Monitoring built in. For example,
bin/magento trident:purge:statusexits non-zero when purges are stuck.
One origin fetch, even when things go wrong
Request coalescing is what stops a traffic spike from turning into an origin outage: a hundred visitors asking for the same page cost one origin fetch. 1.8.0 makes that hold in the hard cases.
- Under
Vary. Each waiting visitor gets the variant it actually asked for, including on streamed responses. - When the first visitor leaves. If the visitor who triggered an ESI fragment fetch disconnects, the visitors waiting on it take the fetch over and still get the block.
- When the origin fails mid-response. A truncated body triggers one shared retry, not one per visitor.
- When serving stale. stale-if-error picks the variant each request selected, just like a fresh hit.
Bounded by design
Every resource Trident holds now has an explicit owner and an explicit budget: uploads, buffers, streamed bodies, connections, pending TLS handshakes and queued requests. Budgets are charged for what actually arrives (a request body counts the bytes received, not the size it promised) and are released on completion and cancellation alike.
Cache admission reserves entry bytes atomically, including entries still being written, so concurrent fills can't push the cache past its entry budget. A response too large to store is simply served to the visitor uncached instead of failing.
Configuration you can trust
A setting that silently does nothing is a trap. 1.8.0 refuses settings that ask for behaviour Trident doesn't have, and names the replacement in the error. Before you deploy, run the new binary against your real configuration:
trident --config /etc/trident/config.toml --check --strictRefresh concurrency now does what worker_count says, and a new max_concurrent_per_backend cap stops one slow origin taking the whole budget. Every configuration reload reports whether it applied, and reload work runs off the request path.
Secure out of the box, hardened at the edge
- Admin API protected from the first start. With no token configured, Trident generates a secret that
trident-clireads automatically. - Private configuration. Configuration files are installed readable only by root and the service, because they can hold tokens and secrets.
- Safer upgrades. Packages are signed, and from 1.8 on an upgrade checks your configuration with the new binary before restarting. If the new version would refuse the configuration, the running service keeps serving.
- Request smuggling closed off. Ambiguous HTTP/1 framing is rejected before parsing, on every listener.
- Honest headers and rules. Headers named in
Connectionare removed in both directions, and request rules match the canonical path, so/%61dminno longer slips past a rule on/admin. - Know what you run.
GET /admin/statusreports the exact source commit of the build.
Warming and revalidation
The cache warmer accepts explicit URL lists and sitemaps, including gzip-compressed ones, for both scheduled and manual runs. A synchronous 304 Not Modified refreshes the cached entry in place, and parsed ESI hole-punch templates are reused across requests.
Every stack, one contract
Trident speaks HTTP, so it works in front of anything. But the details that make caching safe live in your application: which responses can be shared, which tags a page carries, how a purge gets delivered. 1.8.0 ships integrations that get those details right for the platforms and frameworks our customers run.
They're built on three shared libraries (qoliber/trident-php, the TypeScript SDK and the Python library), and every library passes the same contract test vectors. A purge from Magento, a Django signal and a Node.js service behave exactly the same way. The commerce platforms and the Symfony, Laravel and Django packages each have a live end-to-end suite that runs a real application against a real Trident.
Commerce platforms
Magento 2Shopware 6SyliusWooCommercePrestaShopWeb frameworks
SymfonyLaravelDjangoRailsLanguage SDKs
PHP
TypeScript
Python
RubyWorking in another language? The admin API ships a complete OpenAPI specification, so you can generate a typed client for any stack.
Tested at scale
We don't ship on hope. Before release, Velocity Engine 1.8.0 went through the largest test effort in its history.
The request count is conservative: 289,245,706 completed responses across candidate builds, reference comparisons and platform and SDK runs, deduplicated, with failed runs, origin fan-out and unmetered history left out. The endurance run kept live traffic flowing for 72 hours while we injected origin outages, applied configuration reloads under load and forced restarts, and every engine lifetime passed its memory checks.
Endurance figures were measured on the release-candidate build and describe that workload, not a guarantee for production traffic.
Get Velocity Engine 1.8.0
Signed packages for Debian, Ubuntu, Fedora, RHEL-compatible distributions, openSUSE, Alpine and FreeBSD 14/15, release tarballs for Linux, macOS and FreeBSD, and multi-arch Docker images.
Debian / Ubuntu
curl -fsSL https://pkg.trident-cache.com/gpg.key \
| sudo gpg --dearmor -o /usr/share/keyrings/trident-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/trident-archive-keyring.gpg] \
https://pkg.trident-cache.com/apt stable main" \
| sudo tee /etc/apt/sources.list.d/trident.list
sudo apt update && sudo apt install tridentAny Linux, macOS or FreeBSD
curl -sSL https://get.trident-cache.com/install.sh | shDocker
docker pull docker.trident-cache.com/trident:v1.8.0--check --strict before switching it, configure an admin token in your shop module first (the admin API now requires a credential), and plan for a cold cache after the restart. The upgrade guide in the documentation walks through every step. Ready to try it? Start the 14-day trial.