Welcome, Start Shipping Now! Learn more

All projects

CConvertrilo

Media Encoding & Transcoding App

Convertrilo is a video conversion and transcoding SaaS I built and operate end to end. It pairs Next.js, Fastify, and PostgreSQL with distributed self-hosted Rust workers and BullMQ queues to encode AV1, H.265, and H.264 efficiently on on-premise infrastructure.

Convertrilo video encoding and transcoding website

Overview

Convertrilo is a video conversion and transcoding SaaS application that I built and operate. It provides straightforward video encoding and transcoding with modern codecs, and it runs on on-premise workers to keep processing efficient and cost effective.

The application is live at convertrilo.com and covers the full path from upload to download.

Key Features

  • Application stack

    I built the application on Next.js, Fastify, TypeScript, PostgreSQL with Drizzle, Redis and BullMQ, FFmpeg, and S3.

  • Background processing

    Encoding runs through worker based job queues built on Redis and BullMQ.

  • Codec support

    Convertrilo supports AV1 , H.265 , and H.264 .

  • File handling

    Temporary files are managed deliberately.

  • User flow

    The flow is intentionally short, with no extra steps between the user and the encoded file:

Tech Stack

Typescript
Next.js
Fastify
Rust
Postgresql
Drizzle
Tailwindcss
Tanstack Query
Zustand

Architecture

The interface, API, queue and self-hosted workers handle the path from upload to download.

  1. FrontendNext.js
  2. APIFastify
  3. QueueRedis / BullMQ
  4. WorkersRust / FFmpeg
  5. StorageS3
  6. OutputDownload
View infrastructure details

Application stack

I built the application on Next.js, Fastify, TypeScript, PostgreSQL with Drizzle, Redis and BullMQ, FFmpeg, and S3. The goal was a stack that is solid and maintainable, with each piece doing a job it is well suited to: Next.js for the interface, Fastify for the API, Drizzle over PostgreSQL for typed data access, and S3 for storage.

Background processing

Encoding runs through worker based job queues built on Redis and BullMQ. This keeps long running jobs out of the request cycle and gives reliable background processing for the encodes themselves. The workers are distributed and self-hosted, written in Rust, which is what allows the encoding capacity to run on my own infrastructure rather than being tied to hosted encoding services.

Codec support

Convertrilo supports AV1, H.265, and H.264. FFmpeg handles the encode step, and the queue layer routes each job to a worker with the codec and options the user selected. Covering these three codecs lets the app serve a wide range of media needs, from broad compatibility to newer, more efficient formats.

File handling

Temporary files are managed deliberately. Inputs are deleted after processing completes, so uploaded source files do not accumulate. Outputs stay available for download and can be removed by the user at any time.

User flow

The flow is intentionally short, with no extra steps between the user and the encoded file:

  1. Upload the source video.

  2. Set the encoding options.

  3. Convert.

  4. Download the result.

The Challenge

Encoding video is not a request that can be handled in a normal web request cycle. Files are large, jobs run for a long time, and the work has to continue reliably even when the user has closed the browser tab.

At the same time, the product needed to stay narrow and practical: support modern codecs across a wide range of media, run the encoding work on on-premise workers so the process stays cost effective, and handle files responsibly so that inputs are not left sitting around and outputs remain under the user's control.

Outcomes

Convertrilo is built and running. The delivered application provides video encoding and transcoding in AV1, H.265, and H.264, backed by distributed self-hosted Rust workers and worker based queues on Redis and BullMQ. It runs on on-premise infrastructure, it deletes inputs after processing, and it gives users control over removing their outputs.

What I would point to as the core result is the architecture rather than a single feature: separating the interface, the API, the queue, and the workers means encoding capacity can run on my own hardware while the web application stays responsive, and each part of the system can be changed without disturbing the others.

My role

Convertrilo is my own product, and I built it end to end. That covered the stack choice, the API, the job queue architecture, the distributed self-hosted workers written in Rust, and the upload to download flow in the interface.

Let’s build

Have a project in mind?

Let’s discuss how we can turn your idea into a real product.

Get in touch