Thinking of building your own MediaRecorder-based recorder?
Here is what you need to build, and then keep running, before the first recording reaches production.
Seven things to build.
MediaRecorder is where the work starts, not where it ends.
In the browser
Recording client
It needs to work on all major browsers, desktop and mobile, including Safari and Firefox. It has to size and scale correctly, and preferably meet an accessibility standard like WCAG AA. A good device selector is especially hard. Codecs and file formats differ between browsers, so the MP4 and WebM files MediaRecorder creates need further processing. You need a warning for low or muted microphones, and a bitrate that scales with resolution so browser defaults don't cap it.
You also have to work around browser bugs (huge frames after standby) and react to browser changes: Chrome changed how the exact keyword behaves and changed its permission dialogs several times, and new codecs keep rolling out. Plan for users connecting new devices, Bluetooth headsets disconnecting, and switching from Wi-Fi to 5G.
The client has to be hosted close to your users, with a build process that can roll back if something breaks. Publishing your own npm library is one option.
Between browser and server
Transfer mechanism
A POST bulk uploads everything at the end. Streaming over WebSockets is more elegant but brings its own complexity: a local buffer, a server-side buffer and a log of what was sent correctly. If the user disconnects, you need to reconnect them to the same server and resume the upload. You also need hash checks to make sure you received the same data that was sent.
On your servers
Post-processing
Fragmented MP4 and WebM files from browsers don't always play correctly, and both are missing duration information. You need to transcode everything to the container and codecs you want. That is CPU-intensive with your own ffmpeg, or expensive with a third-party service. You also need logic to decide whether re-transcoding H.264 to H.264 is worth it.
Uploaded videos need the MOOV atom moved to the start, with the duration in place, for fast start. A keyframe at the beginning stops the video opening on a black frame. Watermarks, mobile rotation, cropping and cutting to length each need extra logic.
Out to storage
Push to storage
Push the recording and its other deliverables to long-term storage like Amazon S3 or Cloudflare R2. SDKs like the AWS S3 SDK need to be kept up to date. The transfer has to be secure, the credentials stored and managed securely, and the permissions scoped correctly.
Out to storage
Retry mechanism
If your storage provider is down, or you mistakenly revoke your IAM user's S3 permissions, you need a staggered retry mechanism that keeps trying to push.
Operations
Monitoring
All of it needs monitoring from a third-party service that checks more than ping: application-level checks that verify the application is available. You need an alert channel, a way to avoid alert fatigue, and people to respond when an alert fires.
Operations
Maintenance
All of it needs maintaining. Keep the OS, database, Nginx, Node, npm and every other library up to date. You need internal documentation, build scripts and backups, plus firewalls, DNS entries and fail2ban.
With AddPipe Already built
- A recording client tested on real devices, including Safari and Firefox
- Streaming as the user records, with reconnection and server-side recovery
- Every recording processed into a non-fragmented MP4, with a snapshot and a filmstrip
- Pushed to S3, R2, FTP, SFTP, Dropbox, Google Cloud Storage or Box
- Retries for about 72 hours, with a log of every attempt
- EU and US regions with two availability zones each
- 55 product updates shipped in 2025
Details.
Isn't MediaRecorder enough to record video in the browser?
It records, but browsers produce different codecs and file formats, and the fragmented MP4 and WebM files are missing duration information and do not always play correctly. You still need a transfer mechanism, post-processing, storage, retries, monitoring and maintenance around it.
Why not just upload the file with a POST at the end?
A POST bulk uploads everything at the end, so long recordings mean long waits, and a dropped connection means starting over. Streaming over WebSockets avoids that but needs buffers on both sides, a log of what was sent, reconnection and resume logic, and hash checks.
What does AddPipe do after the recording is made?
Every recording is processed into a non-fragmented MP4 with a snapshot and a filmstrip, then pushed to your storage. If the push fails, AddPipe retries for about 72 hours and logs every attempt.
Sign up for a 14 day trial.
Add audio, video and screen recording to your website and explore the AddPipe Platform for two weeks.