VERT

Last reviewed Aug 26, 2026 · 710 words

Vert does its conversions inside the browser tab. Drop a 40 MB WAV on the page and the FLAC comes back without the file ever reaching a server, which is the entire privacy pitch and the reason it climbed to 15,401 GitHub stars within a year of its 2025 debut. The self-hosted instance is therefore a static front end that serves WebAssembly to your browser; the only time your server does real work is video, which is offloaded to a separate daemon called vertd. Understand that split and the rest of the setup is a 10-minute job.

Nothing leaves the tab, except video

Image, audio and document conversions run as WebAssembly builds of familiar tools compiled into the page, so the speed you get is your laptop's, not your server's, and a Raspberry Pi can host the front end with 256 MB of RAM and no complaints. Video is the exception because transcoding in the browser is impractically slow and memory-hungry, so Vert ships vertd, a server-side component that wraps ffmpeg and does the heavy work, using a GPU when the host has one. If you never convert video, you never need vertd, and the front end tells you so when you drop an MP4 on it.

Docker: the front end is easy, vertd is a decision

The front end is published as ghcr.io/vert-sh/vert and runs as a single container behind whatever reverse proxy you already use. The README's compose file is about 10 lines; put Caddy or Traefik in front and give it a hostname, because the WebAssembly modules are several megabytes and you want them cached by the browser over HTTPS rather than re-fetched. vertd is a second container, and where you put it matters: a video queue can pin a CPU for minutes, so on a shared homelab box I run it with a CPU limit, or on the machine that already has a GPU for Jellyfin transcoding. Point the front end at your vertd instance through its environment settings, and only publish that endpoint on your LAN or VPN, since an open transcoding daemon is a free compute donation to the internet.

What it converts well, and what it is not

Images between PNG, JPEG, WebP, AVIF, HEIC and the other common formats, with quality settings. Audio between WAV, FLAC, MP3, OGG, AAC and friends. Documents between the formats a pandoc-style converter handles, which means Markdown, DOCX, HTML and similar text-bearing files. It is fast and it is private, and that is the whole product. It is not a PDF editor: merging, splitting, OCR and redaction belong to Stirling PDF, which is the right tool for that job and pairs well beside Vert on the same host. It is not a batch pipeline either; there is no watch folder or API for converting 3,000 files overnight, so a script around ffmpeg or ImageMagick still owns that job. And it is not a file-sharing tool, despite the catalogue listing it near ProjectSend; converted files download straight back to the browser and nothing is stored.

Young project, moving quickly

First released in 2025, Vert is developed in the open under AGPL-3.0, with a Svelte codebase and a small team. Format support has widened release by release and the interface changes visibly between versions, which is good news for features and a mild irritation if you pinned an image tag six months ago. Watch the release notes for changes to vertd's protocol, because the front end and daemon are versioned together, and a mismatch shows up as video conversions silently failing rather than a clear error.

What I'd do

Run the front end on any box with a reverse proxy; it costs nothing to keep. Add vertd only if you convert video more than once a month, put it on the GPU machine, and keep it LAN-only behind Tailscale. Keep Stirling PDF alongside for anything PDF-shaped. For most households this replaces every "free online converter" tab, and the difference is that the 200 MB of holiday photos you shrink to WebP never touch a stranger's disk.