Scriberr: self-hosted AI transcription in Docker, with development currently paused

The problem Scriberr solves, and who it is actually for

Cloud transcription is priced per hour and requires you to hand over the recording. Scriberr exists to remove both of those. The README says it was built after the author bought a Plaud Note and found that transcription happened on the vendor's servers, at a cost he quotes as $100 a year for 20 hours per month or $240 a year for unlimited access. The stated motivation is privacy and subscription avoidance, not features.

That makes the target user narrow and specific. You are the person who already runs a NAS, a home server or an Unraid box, who has Docker running, and who is willing to spend disk space and GPU time instead of money. If you transcribe a handful of voice memos a month, the setup cost will exceed the benefit. If you handle recordings you are contractually or ethically barred from uploading, the trade flips.

The language mix is worth noting. The server is Go (go.mod declares go 1.24.0), the front end is React built with Vite, and the actual speech recognition runs in a Python environment that the container manages for you. You are adopting three runtimes whether you like it or not.

How the Go server, the embedded UI and WhisperX fit together

The Dockerfile shows the architecture more clearly than the README does. It is a three-stage build. The first stage runs node:20-alpine, copies web/frontend/package*.json, runs npm ci and npm run build, and produces a static bundle. The second stage runs golang:1.24-bookworm, downloads Go modules, copies that front-end build into internal/web/dist, and compiles cmd/server/main.go with CGO_ENABLED=0. The same stage also cross-compiles the CLI for linux/amd64, darwin/amd64, darwin/arm64 and windows/amd64 from ./cmd/scriberr-cli.

The third stage is the one that matters operationally. It is python:3.11-slim, and it sets environment variables that define where everything lives: HOST=0.0.0.0, PORT=8080, DATABASE_PATH=/app/data/scriberr.db, UPLOAD_DIR=/app/data/uploads, WHISPERX_ENV=/app/whisperx-env. The image installs ffmpeg (the Dockerfile comment says it is there for yt-dlp) and uv, and the docker-compose file mounts two volumes, scriberr_data on /app/data and env_data on /app/whisperx-env.

That second volume is the design decision to understand. The WhisperX Python environment is not baked into the image. It is created into /app/whisperx-env at runtime and persisted across container restarts. The practical consequence is that your first start is slow and network-dependent, and that if you delete the env_data volume you pay that cost again. It also means the image stays small and the Python dependency resolution happens on your machine rather than at build time.

Persistence is SQLite through github.com/glebarez/sqlite with GORM, which is why there is no database container in the compose file. For a single-user self-hosted app that is the right call. It also means concurrent writers are not something this design is built for.

Installing Scriberr with Docker Compose and running a first transcription

The repository ships docker-compose.yml, and it is the shortest path to a running instance. It pulls ghcr.io/rishikanthc/scriberr:latest, publishes port 8080, and mounts the two named volumes described above. PUID and PGID default to 1000, so if your host user is not 1000 you should set them before starting.

services:
  scriberr:
    image: ghcr.io/rishikanthc/scriberr:latest
    ports:
      - "8080:8080"
    volumes:
      - scriberr_data:/app/data
      - env_data:/app/whisperx-env
    restart: unless-stopped

Start it with docker compose up -d, then reach the UI at http://localhost:8080. The first start is the slow part: the entrypoint has to build the WhisperX environment into /app/whisperx-env. Watch the logs rather than assuming it hung.

docker compose up -d
docker compose logs -f scriberr

There is a CUDA path as well. The repository contains Dockerfile.cuda, Dockerfile.cuda.12.9, docker-compose.cuda.yml and docker-compose.build.cuda.yml, so GPU acceleration is a supported variant rather than an afterthought. The plain docker-compose.yml is CPU-only by omission.

Once the UI loads, the workflow the README describes is upload or record, then transcribe, then read. The README states that Scriberr uses NVIDIA Parakeet and Canary models, or the older Whisper models, and produces word-level timing. It also lists a Folder Watcher that processes new files dropped into a directory, which is the feature most likely to matter if you want automation rather than manual uploads. The API reference lives at scriberr.app/api, and the docs at scriberr.app/docs.

If you want to run from source rather than the image, the Makefile has a dev target that installs air for live reload, creates placeholder files in internal/web/dist so the Go embed directive is satisfied, starts the backend, and starts Vite from web/frontend. That target is for contributors, not for deployment.

The limitation that matters most: development is paused

The README carries an update from the maintainer stating that he was affected by layoffs at eBay and that development is paused, in his words, but definitely not abandoned. He explicitly invites the community to contribute or help move the project forward. The last push to the repository was on 2026-06-01, and the most recent tagged release is v1.2.0 from 2025-12-17.

This is not an archived project, and the licence is permissive, so you can fork it. But anyone evaluating Scriberr for production use should read that status paragraph before reading the feature list. A paused project still installs and still transcribes. What it does not give you is a maintainer triaging bug reports, merging fixes for upstream model changes, or cutting releases on a schedule.

There is a second, structural limitation that is independent of maintenance. The WhisperX environment is built at runtime inside the container. That means model downloads and Python dependency resolution happen on your hardware, on your network, at first start. On an air-gapped machine, or behind a proxy that blocks PyPI, the container will come up but transcription will not work. The README does not document an offline pre-seeding procedure for that environment, and neither does the compose file.

A third constraint is the single SQLite database. It is fine for one user and a few thousand transcripts. It is not a multi-tenant design, and nothing in the repository suggests it is meant to be.

Scriberr versus hosted APIs and versus running WhisperX yourself

The obvious alternative is a hosted transcription API, and the README itself points at one: Recall.ai, listed as a sponsor for meeting transcription. The difference in approach is not subtle. Recall.ai joins Zoom, Google Meet and Microsoft Teams calls, pulls the speaker data and separate audio streams from the meeting platform, and the README claims that produces 100% accurate speaker diarization with actual speaker names. Scriberr cannot do that, because it never sees the meeting platform. It receives a file you give it and runs diarization on the audio itself. If accurate speaker labels on multi-party calls are your requirement, Scriberr is the wrong tool and a platform-integrated API is the right one.

The other alternative is running WhisperX directly, which is what Scriberr does under the hood. If you go that route you own the queue, the storage layout, the retry logic, the web UI and the search. Scriberr's contribution is the Go server, the embedded React UI, the SQLite job store, the Folder Watcher and the API around that Python environment. If you already have a pipeline and only need the model, the extra layer is overhead. If you do not want to write any of it, the layer is the product.

Licence, upgrade cost and what a fork would inherit

Scriberr is MIT licensed. That is about as permissive as it gets: you can run it commercially, modify it, and redistribute it, provided the copyright notice and permission notice travel with it. The LICENSE file is at the repository root. None of this is legal advice, and if you plan to redistribute a modified Scriberr inside a product, have someone qualified read the actual file.

Upgrading is where the runtime-built environment bites. Because /app/whisperx-env is a named volume, changing the image tag does not necessarily rebuild the Python side. The compose file mounts env_data at that path, so a pull-and-restart cycle replaces the Go binary and the UI but leaves the WhisperX environment in place. Whether that is the behaviour you want depends on what changed. If a release bumps the Python dependencies, keeping the old volume may leave you running mismatched code, and the README does not document a rollback or migration procedure for that case.

For a fork, the cost is the cross-platform CLI build in the Dockerfile and the Go module set in go.mod, which is modest and mostly indirect dependencies. The real inheritance is the Python environment management, which is the part most likely to break as upstream packages move.

Editorial conclusion

Adopt Scriberr if you already run Docker on your own hardware, you object to uploading recordings to a cloud service, and you can accept a project whose README says development is paused. Do not adopt it if you need a vendor SLA, guaranteed releases, or a maintainer who answers issues within days. Before committing, verify three things: that the ghcr.io/rishikanthc/scriberr:latest image pulls on your architecture, that the WhisperX environment installs inside the container on first run, and that the built-in recorder initialises in your browser, since that is the failure users search for most.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rishikanthc/Scriberr on GitHub