8mb.local: a self-hosted target-size video compressor with GPU encoding

The problem is a size cap, not a codec preference

Most video tools ask you to pick a bitrate or a quality level and then tell you what came out. 8mb.local inverts that. The README describes it as a fire-and-forget compressor: you drop a file, choose a target size such as 8 MB, 25 MB, 50 MB or 100 MB, and the system produces an output that fits. The project name and the stated inspiration, 8mb.video, point at the same use case, which is the upload limit rather than the viewing experience. Anyone who has re-encoded a screen recording three times to get under a portal's attachment cap will recognise the workflow being automated. The audience is narrow and identifiable: people running their own hardware who want that loop to happen locally, without uploading source footage to a third-party service. The README also lists a Projects section for public instances, with fits.video given as an example of a free and open source online compressor, so the intended deployment range runs from a single desktop to a shared instance.

FastAPI, Celery, Redis and SSE in the Docker path

The repository is one source tree for four artefacts: the frontend, the backend, the worker, and the Windows packages plus the Docker image. In the Docker deployment the README names a SvelteKit UI, a FastAPI backend, a Celery worker and a Redis broker, with progress pushed to the browser over Server-Sent Events. The Windows installer ships the same UI, API and worker code but swaps the broker for a local in-process queue, which removes Redis from the dependency list at the cost of the distributed topology. Encoding itself is FFmpeg, driven toward a size target rather than a fixed bitrate. The README states that if the output exceeds the target by more than 2 percent, the job is re-encoded with an adjusted bitrate. That is the central mechanism: an encode, a size check, and a corrective pass. Progress is reported from output size, time processed, bitrate and wall-clock estimates, and the raw FFmpeg log is streamed live alongside it. Hardware paths are NVIDIA NVENC, Intel Quick Sync, Windows AMD AMF and Linux VAAPI including AMD, with CPU software encoders as the fallback.

Encoder validation is the part worth reading twice

The README claims robust encoder validation at startup that tests actual encoder initialisation rather than mere availability. That distinction matters more than any feature list entry here. A host can report an NVENC-capable card and still fail to open a session, whether because of driver version, a session limit, or a container that has not been given the device. If validation only checked for the presence of a device node, every job would fail at the FFmpeg step instead of at boot. The repository also carries a screenshot labelled Encoder Validation Tests, which suggests the results are surfaced rather than logged and forgotten. The README additionally describes configurable codec visibility, letting you enable or disable specific codecs in the Settings page. Combined with the validation step, that gives an operator a way to hide a codec that validates but produces poor results on their hardware, rather than removing it from the build. I would treat the validation screen as the first thing to open on a new host, because it is the only place the project's own claims about hardware support become checkable on your machine.

Running it: the release script and the Python test environment

The README documents a local release workflow rather than a one-line install. The root VERSION file is described as the single active application-version source, with generated UI and backend version modules synchronised by scripts\set-version.ps1 and verified by scripts\check-version.ps1. One PowerShell command runs the automated checks and builds the portable EXE, the installer EXE, the Store MSIX and the local Docker image: .\release-local.ps1 -Version 142.0.0.0. Stage flags are documented: -DryRun validates tools and prints the plan without changing versions or building, -SkipDocker and -SkipWindows select one artefact family, -SkipMsix drops the Store package, -OutputDir chooses another output folder, -KeepTemp preserves temporary files, and -Overwrite may reuse only a release directory previously created and marked by the script. The README states that arbitrary existing directories, source directories and ancestor paths are protected from overwrite, which is a deliberate guard rather than a convenience. -SkipTests is described as troubleshooting-only and marks the result incomplete. Outputs default to dist\release\<version>\ and include 8mblocal.exe, 8mblocal-Setup.exe, 8mblocal_<version>_x64.msix, 8mblocal-docker.tar, SHA256SUMS.txt, BUILD-MANIFEST.json and TEST-RESULTS.md. Tool requirements depend on the stages selected and are listed as Python 3.11 to 3.13, Node.js, npm, Docker with Compose, Inno Setup, Windows SDK MakeAppx, and 7-Zip when the Windows build must download its tested FFmpeg bundle. The README says the script checks tools before building and fails with a clear missing-tool message rather than installing unrelated software. The documented test-environment preparation is python -m venv .venv followed by .\.venv\Scripts\python.exe -m pip install -r requirements.txt httpx==0.27.2. Note what this workflow is not: the README states it never pushes its Docker image, publishes a release, deploys the application or submits the MSIX, and that Microsoft Partner Center submission stays manual. The supplied material stops mid-command in the checksum verification section, so the exact verification command is not available here.

Where the target-size approach breaks down

Size-targeted encoding is a control loop, and control loops have costs the README does not quantify. The documented >2 percent threshold means a job that overshoots is encoded again. On a short clip that is invisible. On a long recording with a low target, the corrective pass can approach the cost of the first encode, and the README gives no figure for how often the second pass is needed or how many iterations are permitted. The output also cannot be predicted from the input alone: the same source at 8 MB and at 100 MB will differ in ways a viewer may notice in motion-heavy scenes, and the tool offers no quality floor to stop it from degrading a difficult clip to hit the number. Resolution control, video trimming and advanced options such as codec, container, tune and audio bitrate are listed, so there is manual control available, but the default path is the size target. The Windows installer path also carries a real constraint: it runs the same worker code with an in-process queue, so a long batch occupies the process that serves the UI. And the Docker path depends on Redis and Celery being healthy; the README devotes a section to reverse proxy configuration, which is a signal that SSE streaming through a proxy is a known friction point rather than a solved one.

How it differs from a plain FFmpeg wrapper

The obvious alternative is a hand-written FFmpeg command with a two-pass encode and a bitrate calculated from the duration and the target size. That approach is deterministic, scriptable and needs no Redis, no Celery and no web server. It also has no GPU abstraction, no validation step, no queue, no history and no browser UI. The trade is control against convenience. A two-pass CPU encode gives you a known bitrate before you start and one pass over the file; 8mb.local gives you a hardware encoder, a live log, a queue you can cancel jobs from, batch processing, job history and auto-download both enabled by default, and a size check after the fact. If your inputs are predictable and your host has no usable GPU, the script is the better tool. If your inputs vary, your host has an NVENC or QSV encoder, and you want the size guarantee without writing the loop yourself, the project is doing work you would otherwise repeat. The README's own Projects table, listing fits.video as a free and open source online compressor, indicates the author expects the same code to run as a shared service, which a personal shell script does not.

Versioning, maintenance and the licence gap

The release cadence visible in the material is fast. v140, v141 and v142 all landed within roughly ten days in August 2026, and their titles describe behaviour changes rather than cosmetic ones: RAM uploads, folder watch and a 20 MB Discord default in v140; adaptive concurrency and direct API support in v141; faster hardware encoding, GPU detection changes and improved job recovery in v142. Fast iteration on encoder detection and job recovery is what you want from a project whose main failure modes live in drivers and interrupted jobs. It also means the surface moves. The README ties the UI, backend API, EXE metadata, installer metadata, MSIX manifest, Docker metadata and tag, artifact names and release directory to a single four-part version, and the check-version script exists to catch drift between them, which is the right place to spend effort in a repository that ships four artefacts from one tree. Two caveats belong here. First, the licence is recorded as NOASSERTION, meaning the repository metadata does not state a recognised licence, and the README's License section is not included in the material supplied. That is not a detail to resolve after deployment if you plan to redistribute the Docker image or the MSIX, and it is not something I can resolve for you. Second, the release script's protection against overwriting arbitrary directories, and the explicit statement that it does not push, publish or deploy, means upgrades are a manual sequence you own rather than something the tooling handles.

Editorial conclusion

Adopt 8mb.local if you regularly need local files under a fixed size cap (Discord, email, upload portals) and you have an NVIDIA, Intel or AMD GPU whose encoder you are willing to validate at startup. Do not adopt it if you need frame-accurate quality control, per-title tuning or an audited licence position, because the repository is NOASSERTION and the encoder path is chosen by hardware availability and a size target rather than by content. Before relying on it, run the encoder validation screen once on the target host, confirm which of AV1, HEVC and H.264 your driver actually initialises, and watch one job through the >2% re-encode pass to see how many iterations your hardware needs.

Official sources

1. Issues
2. JMS1717/8mb.local on GitHub
3. Project website
4. README
5. Releases