A self-hosted transcription server is one machine you control running a speech model behind a web endpoint, so your laptops, phones and scripts send audio to it and get text back. It is a sensible build if you already run an always-on box with a decent GPU, several devices or automated jobs need one shared endpoint, and you enjoy running infrastructure. For most individuals and small teams it is more work than it saves: you take on security, upkeep and a network hop, and the audio still leaves the device it was recorded on.
The reason people used to need a server was that phones and thin laptops could not run a good speech model. That has changed. Recent iPhones and Apple silicon Macs transcribe on the device itself. This page walks through what a server really involves and costs, what it does and does not buy you for privacy, and the alternative of transcribing where the recording already is.
What a self-hosted transcription server is
Every design has the same shape. A client sends a recording to the server. The server keeps a speech model loaded in memory, decodes the audio, and returns plain text, JSON or subtitles.
Two consequences follow. The box becomes a single point of failure: it goes down for a system upgrade, a power cut or a service that did not restart, and every device that depends on it stops transcribing. It also becomes a single point of access: anything that can reach it can spend your compute and read what it receives. Authentication and a fallback plan belong in the design from day one.
What building one involves
This is the honest outline, without the manual.
- A server program and a model. Open-source options range from a single binary with a model file, to a packaged web service in a container, to servers that copy the request format of popular commercial speech APIs so existing client code can be pointed at them. Each has its own options, defaults and gaps (upload limits, word timing, speaker labels).
- Drivers and runtimes. A GPU server needs the right graphics drivers and container runtime support; a mismatch between versions is the most common reason a setup that worked last month stops.
- Encryption and authentication. A reverse proxy with TLS certificates, and either passwords or a long random token per client. Most transcription servers ship with no authentication at all.
- Remote access. Either an open port you harden, or a private network overlay (a VPN) that puts your devices on one private address range wherever they are. The overlay is less work and far safer.
- Keeping it running. Restart on failure and on boot, a volume for model files so they are not downloaded again after every update, capped log files so the disk does not fill, and monitoring that posts a known recording on a schedule, because a model that failed to load can return empty text and still look healthy.
- Clients. Every device needs a way to send audio and receive the result, which on a phone usually means a shortcut or a small app of your own.
The skills are ordinary Linux administration, networking and some scripting. The time is a day or two to build it properly, then a few hours a year for upgrades, plus being the person others call when it stops.
Hardware and throughput
Read speed as a multiple of real time: 12x means an hour of audio finishes in five minutes.
- A consumer graphics card with 8 GB of memory runs a large Whisper-class model comfortably. Published benchmarks for an optimized implementation put that at roughly 12 times real time for one file, and around 45 times with batching.
- A modern desktop CPU suits a small model and overnight batches, at roughly 5 to 15 times real time depending on precision and batching. It is hopeless for a large model at volume.
- Memory. Allow 3 to 6 GB of graphics memory for a large model depending on quantization, more with batching. How much memory a Mac needs covers the Apple side.
- Apple silicon sits in between. A Mac mini makes a quiet always-on host for native software, while container-based servers run badly there because containers on a Mac do not get the GPU.
Concurrency is where people go wrong. One loaded model decodes one request at a time, and extra workers load extra copies of the weights, so two large models on an 8 GB card fail rather than share. A queue is an inconvenience; running out of graphics memory is an outage.
Security, plainly
An unauthenticated transcription endpoint on the open internet will be found and abused, because scanners sweep the address space continuously and free GPU time is worth taking. If you build one:
- Listen only on the machine itself or your private network, never on every interface by default.
- Put TLS and authentication in front of it, one credential per client.
- Prefer a private overlay network to an open port.
- Set request size and rate limits.
What it costs
| Setup | Cost shape |
|---|---|
| Existing always-on box, CPU only | Electricity only. 100 W continuous is about 73 kWh a month, roughly $15 at $0.20 per kWh |
| Desktop with a consumer GPU, left on | Higher idle and load draw, plus the card |
| Rented cloud GPU, left running | Billed by the hour whether busy or idle. Smaller data-centre GPUs list at roughly $0.50 to $1.50 an hour, which is several hundred dollars a month if you never turn it off |
| Metered speech API | Per minute of audio, nothing when idle. See cloud transcription API pricing |
The costs that are not money are usually bigger: a day or two to build, hours a year for upgrades and versions that move underneath you, and being on call for something other people depend on.
What self-hosting does and does not buy you for privacy
What changes is real: no third-party transcription account, no retention policy you did not write, no subprocessor list, no default that quietly allows a vendor to train on your recordings.
What does not change is that the audio leaves the device and crosses a network. The question moves rather than disappears, from what a vendor does with it to who can reach this machine: anyone with shell access, anyone on the network if you skipped encryption, whoever holds the backups, and the proxy logs. A rented instance swaps a transcription vendor for an infrastructure vendor, a different trade rather than a better one. On-device versus cloud transcription covers that spectrum. If your obligations are professional, check them with your own advisor.
The alternative: transcribe on the devices you already own
If the goal is "my recordings turned into text, without handing them to a transcription service", the shortest path often skips the server entirely. Transcribing on the iPhone, iPad or Mac that made the recording removes the network hop, the endpoint to secure and the box to maintain. It also works on a plane, in a basement and in a room with bad Wi-Fi.
That is what ThinkScribe does. It sets up the speech model on each device for you, with nothing to install or convert, and it has no account. Your recordings and transcripts are never sent to us.
How to transcribe on your own devices with ThinkScribe
- Install ThinkScribe on the devices you record with: iPhone and iPad (iOS and iPadOS 26 or later) or Mac (Apple silicon, macOS 26 or later).
- Choose the spoken language: the language chip on the iPhone Record screen, or Settings > Language for the default. There are 28 languages.
- Record or import. On iPhone, tap record or Import Audio File; on a Mac, ⌘R to record or ⌘I to import several files at once. An Apple Watch can record too; its audio goes to your iPhone and is transcribed there.
- Read the transcript with speakers separated, and play from any line to check it against the audio.
- If you want your transcripts on every device, turn on Settings > iCloud Sync > Sync Across Devices. Sync is off by default, uses your own iCloud account and is provided by Apple.
- Export what you need: text, subtitles, JSON, Markdown, PDF, Word or CSV.
The sync guide and the audio to text use case go further, and the complete voice to text guide covers live text and voice typing.
When a server still makes sense
Be fair to the server. It is the right tool for automated pipelines over recordings that already live in your own storage, for devices that cannot run a model (older Windows laptops, Linux thin clients), for a large archive you want processed while you sleep on hardware you already own, and for organizations that need one controlled endpoint for many services.
Frequently asked questions
Can I run a self-hosted transcription server on a Mac?
Yes. Native speech model software runs well on Apple silicon and uses the GPU, so a Mac mini can make a quiet always-on host. Container-based servers are weaker on a Mac because containers there do not get GPU access. If the only reason for the server is your own iPhone and Mac, transcribing on those devices directly is simpler.
How much GPU memory does a self-hosted Whisper server need?
Published benchmarks show a large Whisper-class model using about 3 to 5 GB of graphics memory depending on precision, and around 6 GB with batching. An 8 GB card handles one large model; 12 GB or more leaves room for batching. Two instances double the requirement, so queue requests instead.
Is self-hosting cheaper than paying a per-minute API?
It depends on volume and on whether the hardware already exists. On a machine you already run, the extra cost is mostly electricity. Renting a GPU for the purpose is not cheap, because it bills every hour whether it transcribes or idles. Transcribing on your own phone or Mac has no per-minute bill at all.
Do I need a server to transcribe recordings on my iPhone?
No. Recent iPhones can run a speech model themselves. In ThinkScribe you record or import audio, pick the spoken language, and the transcript is made on the phone after you stop, with speakers separated. It works offline and needs no account.
How do I get my transcripts on all my devices without a server?
ThinkScribe can sync transcripts, summaries, collections and speaker names through your own iCloud account. Turn on Settings > iCloud Sync > Sync Across Devices; audio is synced only if you also turn on Sync Audio to iCloud. iCloud is provided by Apple and sync is off by default.
