FFmate puts a REST API, a queue and a webhook layer in front of FFmpeg

A service around FFmpeg rather than a wrapper around it

FFmate is described as a modern automation layer built on top of FFmpeg, and the project's own framing is the useful part: it is not only a way to simplify transcoding but also an extensible engine for custom media workflows. The audience is named in the same breath. If you are building custom media processing pipelines, integrating transcoding into existing systems, or writing tools that use FFmpeg, FFmate is the foundation for that. The difference from calling ffmpeg yourself is not the encoding, which FFmpeg still does, but everything around it. A transcoding call in a script has no identity, no state, no queue and no way to tell another system that it finished. FFmate gives each job those things, which is what makes it usable as a backend rather than as a tool.

The feature list is a list of integration surfaces

The core features are best read as a set of ways for another system to talk to FFmate. The REST API submits and manages FFmpeg tasks programmatically, and the webhooks deliver real-time notifications for task events so the caller learns about status changes rather than polling. The built-in queue manages task execution with priority control and what the project calls smart concurrency handling, which is where a burst of jobs stops turning into a machine that falls over. Presets are ready made, pre-configured transcoding settings for common cases, so a job can name a preset instead of carrying a long command line. Watchfolders process files automatically when they are dropped into a directory, dynamic wildcards automate file naming and folder structures, and pre and post processing runs your own scripts before or after each task, which is the extension point that turns a transcoder into a pipeline. Cluster support lets several FFmate instances run together sharing the same database, for scaling and redundancy, and a web UI lets you watch and control jobs without a terminal.

Pre and post processing is where custom logic lives

The pre and post processing hooks are the mechanism the project leans on hardest, and the API reference is short about them. You implement scripts in whatever language you prefer, the README suggests Python, Bash or Node.js, and you point a task or preset at them by defining scriptPath and sidecarPath in your API calls. The sidecar path is the interesting half, because it is where a script can hand structured state to the next stage. That is the difference between a transcoder with hooks and a pipeline: the script does not merely run before the encode, it can rewrite the command, write metadata next to the output, or trigger a follow-up job. Anyone building an ingestion workflow will end up here, so it is worth knowing that the extension point is a filesystem path rather than a plugin interface.

The REST API and the WebSocket are the public contract

The extension guide names the three endpoints that matter for a first integration. Jobs go in through /api/v1/tasks, status comes back through /api/v1/webhooks, and automated ingestion is built on /api/v1/watchfolders combined with presets. The web UI itself is built on the public REST API and WebSockets, which the project points out as a deliberate choice: if you want your own dashboard, you can build it the same way. The WebSocket is served from /ws on the same port as the API, and it provides real-time updates for tasks and logs. That last detail matters for anything user-facing, because a dashboard that polls the API for job status will feel slow in a way that a WebSocket does not, and you would otherwise have to build that yourself.

Two ways to run it

FFmate is a Go application, and the README gives two installation paths with different intentions. The first is for integration and extension, using a pre-compiled binary from the GitHub releases, and the second is for core contribution or deeper customisation, building from a clone.

        git clone https://github.com/welovemedia/ffmate.git
        cd ffmate

        go mod tidy
        # or go get ./...

        go build -o ffmate main.go

The compiled binary lands in the root of the ffmate directory, and the server is started with the server subcommand.

        ./ffmate server
        # For development, consider enabling debug for relevant namespaces:
        # ./ffmate server --debug="api:webhook:queue:ffmpeg:sev"

That debug flag takes a colon separated list of namespaces, which is a good hint at how the codebase is divided: API, webhook, queue, ffmpeg and the severity level are separate logging scopes. With the server up, the API answers on port 3000.

Services on top of core, with SQLite through GORM

The internal diagram in the README is a good map of the codebase. Requests arrive at the REST API, which is built on the Gin web framework, from either your application or the web UI, which is described as Vue, React or static. Below the API sits a services layer under ./internal/services with a task service, a preset service, a watchfolder service and a webhook service. Below that is the core logic under ./internal/core and ./internal/ffmpeg, containing the task queue processor, the pre and post processing engine and the ffmpeg binary wrapper, with the actual ffmpeg binary called as an external system call. The database is SQLite through GORM, and the webhook service reaches your endpoint through an event bus or a direct call. The module path is github.com/welovemedia/ffmate/v2, and the direct dependencies list tells you what else is running: the fyne systray library for a desktop tray, Prometheus client libraries for metrics, go-selfupdate for updating the binary in place, cobra and viper for the command line and configuration, and the goyave framework. The module line and the Go directive are worth reading directly.

module github.com/welovemedia/ffmate/v2

go 1.25.1

AGPL-3.0, cluster mode and an unfinished version promise

The licence is AGPL-3.0, which is the point to consider first for anything you intend to run as a service on a network, because the copyleft obligation attaches to modified versions that you offer to others over a network. The release record shows 2.0.14 on 2025-10-01, 2.0.15 on 2025-10-07 and 2.0.18 on 2026-02-20, with the last push on 2026-09-01, so the repository is being worked on ahead of the tags. Two details in the documentation are worth a second look before you plan a deployment. The prerequisites say Go 1.24 or newer, while the go.mod file declares go 1.25.1, so a machine with 1.24 installed will not build the current tree. And cluster support, which the feature list describes as instances sharing the same database, is the point where the SQLite choice stops being a simplification, so read that section before you scale out.

Editorial conclusion

FFmate fits a team that already depends on FFmpeg and needs transcoding to be a service: something a job system can submit to, something that reports back over webhooks, and somewhere to hang custom scripts around each job. It does not fit a person who wants a simpler ffmpeg command line, because the queue, the database and the API are the product. Before you adopt it, check the AGPL-3.0 licence against how you plan to deploy it, confirm that FFmpeg is on the PATH of the machine that runs the server, and decide whether you need cluster mode, since that is where the SQLite and shared database arrangement starts to matter.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. welovemedia/ffmate on GitHub