How We Use Redis with BullMQ on Hetzner for Queue Management at Fotify

Agustin — Sun, 02 Nov 2025 14:33:25 +0000

At Fotify, we manage thousands of real-time photo uploads and live event interactions every week. Behind the scenes, all that speed and reliability comes down to how we handle our background jobs — and Redis + BullMQ running on Hetzner Cloud plays a big role in that.

In this post, I’ll share how we set up our queue system, the lessons learned, and a few tips for keeping it scalable and efficient.

🧠 Why We Needed Queues

When guests upload photos during an event, each upload triggers multiple asynchronous tasks:

Image optimization and metadata extraction
Upload to Cloudflare R2 for storage
AI-based content filtering
Push notifications for real-time photo walls

Doing all that directly in the request cycle would slow down the user experience. So, we moved those tasks into background queues.

⚙️ The Stack

Our setup is simple and battle-tested:

Redis (single node on Hetzner Cloud CX21)
BullMQ for queue management
NestJS workers that process the jobs
Cloudflare R2 for image storage
PostgreSQL for core app data

We use Docker Compose to deploy the entire stack on Hetzner. Redis runs in a dedicated container, while the workers and API run separately for better isolation.

🚀 How BullMQ Fits In

BullMQ gives us a clean interface to create, manage, and monitor queues.

Each feature has its own queue — for example:

photo-processing
push-notifications
analytics

In our NestJS service, we inject a queue like this:

import { InjectQueue } from '@nestjs/bullmq';
import { Queue } from 'bullmq';

@Injectable()
export class PhotoService {
  constructor(@InjectQueue('photo-processing') private queue: Queue) {}

  async handleUpload(photo: Photo) {
    await this.queue.add('optimize', { photoId: photo.id });
  }
}

This decouples our real-time uploads from heavier tasks that can safely run in the background.

⚡ Performance Tips

A few lessons learned after running this setup for months:

Use a connection pool — avoid creating new Redis connections for every queue instance.
Add retry & backoff strategies — jobs may fail due to transient network issues.
Enable metrics — we use Bull Board to monitor queue performance.
Deploy Redis close to your API — latency between the app and Redis affects throughput.

🧩 Why Hetzner

Hetzner’s servers give us excellent performance for the price. A small Redis instance on Hetzner easily handles tens of thousands of jobs per hour.

We use snapshots and weekly backups to ensure nothing gets lost.

🌐 Try Fotify

If you’re into event tech or photo-sharing platforms, check out Fotify — our real-time photo-sharing app for events. It’s built entirely with Next.js, NestJS, Redis, and BullMQ, all deployed on Hetzner.

Thanks for reading!
If you’ve built something similar or have tips for scaling Redis queues, I’d love to hear from you in the comments.

Building Fotify: Real-Time Photo Sharing for Events

Agustin — Mon, 15 Sep 2025 13:22:20 +0000

At every wedding, birthday, or corporate gathering, guests are taking pictures. The problem is that those photos end up scattered across devices and apps, making it hard for organizers to collect and share them.

That’s the problem we set out to solve with Fotify.

The Idea

Fotify is a real-time photo-sharing and RSVP platform that makes events more interactive:

Guests scan a QR code to upload photos instantly.

Hosts can display live galleries on screens during the event.

Digital invitations, RSVPs, and even multi-day itineraries are managed in the same platform.

No app downloads. No accounts for guests. Just instant memories, accessible to everyone.

The Tech Stack

Here’s how we’re building Fotify under the hood:

Frontend: Next.js
running on a Hetzner VPS.

Backend: NestJS
deployed on another Hetzner VPS.

Database: PostgreSQL, self-hosted for full control and performance.

Authentication: Google OAuth, already integrated with Passport.js.

Storage & Media: Planning Cloudflare R2 (for raw photos) and Cloudflare Images (for transformations & delivery).

Analytics: Umami
for privacy-friendly event tracking.

AI Layer: Intelligent moderation & filtering to keep galleries clean and safe.

This setup gives us full control, performance, and scalability, without locking ourselves into expensive managed services.

Lessons Learned

Hetzner is underrated. With good setup (Docker + Traefik + backups), it’s cheap, fast, and reliable.

Next.js + NestJS is a perfect combo. The separation of concerns keeps development clean and scaling easier.

Postgres beats MySQL for flexibility. Especially with JSON fields for handling dynamic event data.

Start with authentication early. Google OAuth via Passport.js made onboarding smoother for organizers.

Try It Out

If you’re a developer, photographer, or event organizer, I’d love your feedback.

👉 Check out Fotify at https://fotify.app

DEV Community: Agustin