← Back to all posts
Rox Team

Rox v2026.10.0 / v2026.10.1

We've released Rox v2026.10.0 and the follow-up patch release v2026.10.1! 🎉

This is the first stable release since v2026.7.0, about three months ago. It's mostly groundwork rather than new features: a runtime and dependency refresh, security fixes, and an important fix to the cache and delivery queue. Once v2026.10.0 actually connected to Dragonfly, a few more problems came to light, so we fixed them right away in v2026.10.1. If you're updating now, please go straight to v2026.10.1.

IMPORTANT

If you self-host Rox, review your Dragonfly flags before deploying the update: add --default_lua_flags=allow-undeclared-keys and remove --cache_mode=true. See "How to Update" below for details.

What's Changed

🐛 The Dragonfly cache and delivery queue now work (v2026.10.0, #273 / #274)

This is the most important fix in the release.

docker/compose.yml and the K8s secret passed the connection string as DRAGONFLY_URL, but the backend's cache adapter and ActivityPub delivery queue only read REDIS_URL. They silently fell back to localhost:6379, failed to connect, and caching and queued delivery were effectively disabled.

  • DRAGONFLY_URL is now read as a fallback when REDIS_URL is not set
  • Redis/Dragonfly connection failures are logged at warn instead of debug
  • BullMQ's Lua scripts touch keys they don't declare, which Dragonfly rejects by default with script tried accessing undeclared key. The bundled compose files and K8s manifests now run Dragonfly with --default_lua_flags=allow-undeclared-keys

🔌 Connection resilience and job ID fixes (v2026.10.1, #281 / #284)

Once caching and the queue really started using Dragonfly, some previously hidden problems surfaced. v2026.10.1 fixes them together.

  • Never give up reconnecting: the queue used to stop retrying after about 0.6 seconds, so a Dragonfly restart left the delivery worker stalled until the process was restarted. It now keeps reconnecting with a growing delay, capped at 5 seconds
  • Wait for the connection at startup: the first connection error used to disable the queue and cache for the life of the process. It now waits up to 15 seconds to connect, without delaying app startup
  • Logging: one warn when the connection drops and one info when it recovers
  • No more job ID collisions: the 32-bit hash is replaced by the first 128 bits of SHA-256. Distinct deliveries no longer share an ID and get dropped, and purely numeric IDs (which BullMQ rejects) can no longer occur. Jobs already in the queue are unaffected
  • Compose changes: --cache_mode=true is removed so BullMQ keys are never evicted under memory pressure (all cache entries have a TTL, so the cache won't grow without bound). The backend also waits for Dragonfly to be healthy before starting
  • .env.example: REDIS_URL is now commented out, so a .env copied from the example no longer overrides compose's DRAGONFLY_URL
  • Security: credentials in the Redis URL are redacted from startup error messages

We've confirmed on the official instance (rox.love-rox.cc) that caching and the queue are using Dragonfly and that bull:activitypub-delivery:* keys are being created.

🧰 Bun 1.4.3 (v2026.10.0, #272)

The runtime moves from Bun 1.3.14 to 1.4.3, across CI, the Dockerfiles (oven/bun:1.4), and the type definitions (bun-types / @types/bun).

📦 Major dependency upgrades (v2026.10.0, #272)

Package Change
Sentry 10 → 11 sendDefaultPii is gone and v11 collects everything by default. Rox now uses dataCollection to explicitly opt out of headers, cookies, request bodies and more
jotai 2 → 3 atomFamily moved to jotai-family
BullMQ 6 / ioredis 6 protocol: 2 keeps the RESP2 behavior
@simplewebauthn 14 No code change (ML-DSA-44 is now preferred for new registrations). v2026.10.1 drops the now-unused @simplewebauthn/types
vite-plus 1.1 Bundles vitest 5
katex 0.19 Security advisory fix

There are also minor and patch updates, including waku 1.0.0-rc.3, React 19.3, vite 8.3, Lingui 6.9, hono 4.13 and zod 4.6.

🔒 Security advisories down from 32 to 2 (v2026.10.0, #272)

bun audit findings went from 32 (2 critical / 21 high) to 2 (1 high / 1 moderate). Both remaining findings are dev-only dependencies with no upstream fix yet (braces via @lingui/cli, and an old esbuild via drizzle-kit). Neither ships in production code.

⚙️ Dev environment and CI housekeeping

  • GitHub Actions bumped to their latest versions, with the image build workflow pinned by SHA (#272)
  • format:check is now enforced in CI (#272 / #275)
  • Tags created by auto-tag no longer trigger a duplicate release (#278 / #279 / #282 / #285)
  • The devcontainer's Node.js moves from 20 to 24 (Active LTS) (#280 / #283)

Version Information

Component Version
Rox (Project) 2026.10.1
Hono Rox (Backend) 1.10.1
Waku Rox (Frontend) 1.10.1
Shared 1.10.1

How to Update

  • No database migrations in this release
  • Update your Dragonfly flags first. If you deploy the backend first, BullMQ jobs will fail with script tried accessing undeclared key as soon as the queue starts using Dragonfly
  • If you run Dragonfly with --cache_mode=true, remove it. Otherwise, pending delivery jobs can be evicted when memory fills up
# docker compose example
dragonfly:
  image: docker.dragonflydb.io/dragonflydb/dragonfly:latest
  command: >
    dragonfly
    --default_lua_flags=allow-undeclared-keys

The bundled docker/compose.yml and deploy/k8s already include these changes. If you run your own configuration, update it yourself. On K8s, apply the Dragonfly StatefulSet first, then roll out the new backend image.

If you created your .env from .env.example, make sure REDIS_URL=redis://localhost:6379 isn't still in it. If it is, it takes precedence over compose's DRAGONFLY_URL and the cache and queue can't reach Dragonfly.

git pull origin main
bun install --frozen-lockfile
bun run build

Container images are available as ghcr.io/love-rox/rox-backend:v2026.10.1 / ghcr.io/love-rox/rox-frontend:v2026.10.1.

After updating, check that the backend logs aren't repeatedly showing Redis/Dragonfly warn messages and that bull:activitypub-delivery:* keys appear in Dragonfly.

Closing

It's a quiet release, but caching and the delivery queue finally run the way the configuration always said they would — and they now survive a Dragonfly restart, too. Federation delivery should be more reliable, and load should go down.

Questions and feedback are welcome on GitHub Issues.

The Love Rocks. Rox. 🚀