Oliver Eidel ·
June 21, 2026
Moving Away From Cap (Loom Alternative) + Hetzner S3
We used Loom a lot at OpenRegulatory. However, we have a very strong dislike of Atlassian products. The main reason for that is that they suck.
Unfortunately, Loom got acquired by Atlassian. This presented us with a dilemma: Will we stay true to our values and leave Loom behind, or are we going to bite the bullet and just continue using it?
Just kidding, there was no dilemma. Of course we were going to move away. So we started making plans.
The obvious contender was Cap, which is an open-source Loom alternative. You can self-host it. This sounded awesome - I'd just spin up a Hetzner cloud instance (back when they were still cheap after the recent 2-3x price increase, nervous chuckle), set up an S3 bucket, and we'd be good to go!
So that's what I did.
Unfortunately, Loom got acquired by Atlassian. This presented us with a dilemma: Will we stay true to our values and leave Loom behind, or are we going to bite the bullet and just continue using it?
Just kidding, there was no dilemma. Of course we were going to move away. So we started making plans.
The obvious contender was Cap, which is an open-source Loom alternative. You can self-host it. This sounded awesome - I'd just spin up a Hetzner cloud instance (back when they were still cheap after the recent 2-3x price increase, nervous chuckle), set up an S3 bucket, and we'd be good to go!
So that's what I did.
Self-Hosting Cap
I wrote up how I did it in this separate post. I would love to say that self-hosting Cap was easy, but.. it just wasn't. It's just unnecessarily complex. Among other things:
- There's no production-ready HTTP server, so you have to bring in something like Caddy yourself to handle Letsencrypt SSL certificates etc.
- You need an epic amount of third-party API keys: Your S3 bucket, Resend (for emails), Deepgram (for transcriptions), OpenAI (for.. I don't know, it's unclear).
- You need to generate (and save) passwords for your MySQL database, which is required; this feels unnecessary as it's only reachable from the Cap Docker container anyway.
- You need to set the CORS settings on your S3 bucket - I think the Cap docs actually had wrong CORS settings in them.
But it just gets worse:
- Video transcription is.. simply broken? Even if you provide a Deepgram API key, it doesn't seem to work on self-hosted setups (GitHub issue 1, issue 2).
The whole transcription setup is extremely confusing: You need to provide a Deepgram API key, but you can also provide an OpenAI API key. Theoretically, it is said that the OpenAI key will be used as fallback if you don't provide a Deepgram API key. In practice, nothing works, even if you provide both. - Cloudflare R2 is listed as compatible storage provider, but it actually is not (GitHub issue). Frustratingly, video uploads fail in the very final stages, so you only notice this after recording a few long-ish videos.
Okay, look.. I'm not being ungrateful here or so. Mad props to the Cap people for even attempting this daunting task of building a Loom alternative and making it available as open source software, too!
So my criticism above here can be summarized as "first world problems": It's awesome to have a self-hosted option available, but I just had a lot of trouble with it.
However.. the most epic problem probably was an issue we had with the storage format of the video recordings. Something was really buggy in the way the videos were encoded (server-side? with ffmpeg?) which led to incredibly slow load times where you'd have to navigate to a video page, leave your browser sitting there for ~10 minutes until the entire video was buffered, and then hit play.
It was a maddeningly frustrating experience, and it was detrimental to our work as a team at OpenRegulatory, too - people were simply recording fewer screencasts, and I felt like the CEO dude who mandated that everyone use a "great" open source tool while everyone actually realized that "the emperor had no clothes" and the tool actually sucked. I've actually seen this in some of the companies we've worked with as consultants. Not cool.
Something had to give. But going back to Loom (Atlassian!) was not an option.
So I built our own Loom alternative.
Enter Chairkick
Yeah.. I couldn't come up with a better name, and the .com domain was available. Welcome to Chairkick. It's like.. rolling over to a colleague's desk in a physical office, with your chair, and, um.. giving their chair.. a kick? To show them something on your screen? On their screen?
Anyway, Chairkick is a Loom alternative. And I think it's really cool.
It has a few features which both Loom and Cap are actually missing:
Anyway, Chairkick is a Loom alternative. And I think it's really cool.
It has a few features which both Loom and Cap are actually missing:
- Full resolution: Literally no resolution shrinkage when storing screencasts. It's amazing. It looks like you're staring at the actual screen of a colleague.
- AI highlights: Skip directly to the interesting parts of a video (if you have a colleague / CEO who rambles to much, you know.. not me).
- Loom / Cap import: It's probably the only tool out there right now which can easily import your videos from your Loom or Cap account (even self-hosted Cap instances!). This is really cool and was inspired by the (very awesome, in my opinion) Cloudflare R2 migration tool, which copies over entire buckets from your legacy S3 provider. It's an awesome experience.
A few very interesting developments made Chairkick possible:
- Vibe-coding: I don't know if I'd had the patience to fiddle with all the client-side JS code to get browser recording working. We're at a point where Claude / Codex have become so good that they can get this done for you. It's really cool.
- Cloudflare R2 with free egress: This is an interesting one - you're only paying for uploads and storage (simplified), but you're not paying for egress. So storing videos costs you money, but having lots of people view videos doesn't. That means you might get away with not compressing your videos very much, which means much less CPU time spent. Chairkick is currently running on only one Rails server!
- Browser-only recording, no desktop apps: The browser APIs for recording screens and webcams have become really powerful - it is totally possible for e.g. the user to select a window to record while overlaying their webcam onto the final video client-side (HTML canvas and all). This means that you can skip the complexity of shipping desktop apps to various platforms.. for now. Not 100% sure on this one though as there still are limitations.
So yeah. Chairkick has already proven itself at our company, because people are back to recording quite a few screencasts day to day. We'll be using it for the foreseeable future, and you should give it a try, too!
Related posts