# Cap: a self-hostable screen recorder that treats your recordings as files you own

> Cap is an open source Loom alternative built as a Tauri desktop app with a Rust capture core and a Next.js web platform. It gives you two recording modes, S3-compatible storage, and a Docker Compose path to running the whole sharing stack yourself.

**CapSoftware/Cap** — Open source Loom alternative. Beautiful, shareable screen recordings.

- Repository: https://github.com/CapSoftware/Cap
- Website: https://cap.so
- Stars: 22,946 · Forks: 1,989
- Language: Rust
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/capsoftware-cap

## The problem Cap targets: recordings you cannot move and links you do not control

Screen recording tools usually bundle three things: a capture client, a hosting service, and a sharing page. You get the first for free and rent the other two. That arrangement is fine until a recording contains something you would rather not upload, or until a team wants its demo library to outlive a subscription. Cap's answer is to split the three apart. The desktop app records and edits locally, the web app serves share pages and the dashboard, and storage can be Cap Cloud, your own S3-compatible bucket, local disk, or a full self-hosted deployment. The README frames the audience directly: teams that want to own their data. In practice that means engineering teams filing bug reports, product teams recording demos and onboarding, and anyone doing async standups or design reviews. The pitch is not that recording is hard. It is that the second half of the workflow, where the file becomes a link other people watch, is where lock-in happens.

## Instant Mode and Studio Mode are two different data flows, not two buttons

The README describes the modes in terms of when the upload happens, and that distinction drives everything else. Instant Mode uploads while you record and returns a share link the moment you stop, which is the right shape for a bug report you want to paste into an issue tracker thirty seconds later. Studio Mode records locally, opens the editor, and lets you add backgrounds, zooms, trimming, captions and export settings before anything leaves the machine. Those are opposite trade-offs: Instant Mode optimises for time to link and accepts that the recording is already in flight, while Studio Mode optimises for the finished artifact and accepts the extra editing step. The repository map shows where the work sits. The desktop app is Tauri v2 with a SolidStart UI and a Rust backend; the web app is Next.js and hosts marketing, docs, dashboard, sharing, API routes and auth; media processing runs in a separate media-server service. Capture, camera, audio, encoding, rendering, muxing and export live in the crates directory. The web API is built on Effect and @effect/platform HTTP APIs. One detail worth noticing in the workspace manifest: Cap vendors its own forks of cpal, ffmpeg-next, nokhwa and cidre, pinned by revision. The comment on the cpal entry explains that the fork carries an unreleased fix so audio streams are actually stopped and released on drop on macOS, and so WASAPI capture packets flagged AUDCLNT_BUFFERFLAGS_SILENT are zeroed. That is a maintenance cost Cap has chosen to carry rather than wait upstream.

## Self-hosting Cap Web with Docker Compose

The README gives a three-command path for the web platform. Clone the repository, change into it, and bring the stack up. Cap then answers on port 3000.

```bash

git clone https://github.com/CapSoftware/Cap.git
cd Cap
docker compose up -d

```

The compose file defines a cap-web container built from ghcr.io/capsoftware/cap-web:latest, gated on a healthy MySQL and a healthy MinIO, with the media server on port 3456 internally. Storage is wired through CAP_AWS_ACCESS_KEY, CAP_AWS_SECRET_KEY, CAP_AWS_BUCKET, CAP_AWS_REGION and S3_PATH_STYLE, plus separate S3_PUBLIC_ENDPOINT and S3_INTERNAL_ENDPOINT values, which is how the browser and the containers reach the same bucket by different addresses. If you have not configured email, the login link is not sent. It is printed to the logs instead.

```bash

docker compose logs cap-web

```

Before exposing this to the internet, the README says to set the public URLs and replace the default secrets. The compose file ships defaults for DATABASE_ENCRYPTION_KEY, NEXTAUTH_SECRET, MEDIA_SERVER_WEBHOOK_SECRET and the MinIO credentials, and those defaults are visible in the repository, so leaving them in place on a public host is the same as publishing them.

```bash

CAP_URL=https://cap.yourdomain.com
S3_PUBLIC_URL=https://s3.yourdomain.com

```

The README also points at Railway for one-click managed hosting and at Coolify, which uses docker-compose.coolify.yml. A self-hosted instance only becomes useful to the desktop app once you point it there: the README says to set the Cap Server URL under Settings in the desktop client.

## Building Cap from source: Bun, Rust and a Docker dependency

Cap is a Turborepo monorepo, and the README lists its requirements plainly: Node.js 20 or newer, Bun 1.4.0, Rust 1.88 or newer, and Docker for MySQL, MinIO and local services. Setup is three commands.

```bash

bun install
bun run env-setup
bun run cap-setup

```

From there the package scripts cover the common paths: bun run dev starts the full local stack and brings Docker up around it, bun run dev:web runs the web app without the desktop app, bun run dev:desktop runs the desktop app, and bun run tauri:build produces the desktop release. Linting and formatting go through Biome with bun run lint and bun run format, type checking through bun run typecheck, and Rust tests are run per crate with cargo test -p <crate>. Database work goes through Drizzle: bun run db:generate, bun run db:push and bun run db:studio. The monorepo spans Rust, TypeScript, Tauri, SolidStart, Next.js, Drizzle, MySQL and Tailwind CSS, so a contributor working on the capture path and one working on the share page touch almost nothing in common. That is the point of the layout, and it is also why the toolchain list is long.

## Where Cap is the wrong tool

The desktop apps run on macOS and Windows, and the README does not list a Linux desktop build. If your team records on Linux workstations, the client is not there, and the web dashboard does not replace it. The second boundary is operational. Self-hosting here means MySQL, MinIO or another S3-compatible store, a media server, and a web app behind a domain, and the README's own production checklist covers email setup, AI providers, SSL, storage and hardening. That is a real service to run. If nobody on the team wants to own a database and a bucket, Cap Cloud or the hosted download is the intended path, and the self-hosting story stops being an advantage. A third limitation is visible in the dependency manifest rather than the README: the workspace pins forks of cpal, ffmpeg-next, nokhwa and cidre by revision. Those forks exist because upstream did not carry the fixes Cap needed. Anyone building from source inherits that patch surface, and any upstream change has to be reconciled against it.

## Cap against Loom, and against a plain local recorder

Loom is the comparison the README invites, and the difference is where the recording lives. Loom is a hosted product: you record, it uploads, and the library and share pages sit inside Loom's infrastructure. Cap keeps the same shape as an option through Cap Cloud, but it also lets you point storage at AWS S3, Cloudflare R2, Backblaze B2, MinIO, Wasabi or another S3-compatible provider, serve share pages from your own domain, and run the web app, API, database, media server and object storage yourself with Docker Compose. Cap also imports existing Loom videos, which matters if the decision is a migration rather than a greenfield choice. The second alternative is not a product at all: a plain local recorder plus a file share. That costs nothing and never uploads anything, but you lose the parts Cap exists to provide, namely share links, comments, reactions, transcripts, viewer analytics, team workspaces and password-protected pages. Cap's position is between those two, and the honest framing is that you are trading operational work for control over where the bytes end up.

## Maintenance, releases and what the licence file leaves open

The repository is not archived, and the most recent push was on 2026-09-20. Releases are frequent enough to suggest a working cadence: cap-v0.6.0 on 2026-09-15, cap-v0.5.9 on 2026-08-11, and cap-v0.5.7 on 2026-07-20. The upgrade cost depends on which half you run. Desktop users take a new build and stop there. Self-hosters pull a new cap-web image and, when the Drizzle schema changes, run the database commands, which is why bun run db:generate and bun run db:push exist as separate steps rather than being folded into startup. The licence is the part to check yourself. The repository metadata reports NOASSERTION rather than a recognised identifier, and there is both a LICENSE file and a licenses directory at the top level. GitHub's classifier not resolving an SPDX identifier means you cannot assume the terms from the description alone. If you plan to self-host this for a company, or to build on packages/sdk-embed or packages/sdk-recorder, read the LICENSE file and the licenses directory and get your own advice. Nothing in the README states the terms.

## Conclusion

Adopt Cap if you record demos, bug reports or async updates and you want the sharing layer to be yours: the Docker Compose stack plus an S3-compatible bucket is the part no hosted competitor will give you. Do not adopt it if you need a Linux desktop recorder, since the README lists only macOS and Windows desktop apps, or if you want a hosted service with no infrastructure to run. Before committing, clone the repository, run docker compose up -d, and check whether the login link appears in docker compose logs cap-web with your mail settings absent; that one test tells you whether your self-hosted instance is reachable at all.

## FAQ

### Is Cap free?

The README does not describe pricing tiers, and it links to a pricing page at cap.so/pricing for the hosted product. The source code is public and the README documents self-hosting the full platform with Docker Compose, so running your own instance is a documented path. Check the pricing page and the LICENSE file for the terms that apply to you.

### Can I use the Cap screen recorder on my Mac?

Yes. The README states that Cap runs on macOS and Windows, with a web dashboard for viewing, sharing and managing recordings, and it points to cap.so/download for the desktop build. The desktop app is a Tauri v2 application with a SolidStart UI and a Rust backend.

### What is the difference between Instant Mode and Studio Mode in Cap?

Instant Mode uploads while you record and produces a share link as soon as recording stops, which suits fast feedback and bug reports. Studio Mode records locally, opens the editor for backgrounds, zooms, trimming and captions, and lets you export or share a finished video.

### Can Cap store recordings in my own S3 bucket?

The README lists AWS S3, Cloudflare R2, Backblaze B2, MinIO, Wasabi and other S3-compatible providers as storage options, alongside Cap Cloud and keeping recordings local. The compose file wires this through CAP_AWS_ACCESS_KEY, CAP_AWS_SECRET_KEY, CAP_AWS_BUCKET and CAP_AWS_REGION, with separate public and internal S3 endpoints.

### How do I point the Cap desktop app at my own Cap server?

The README says to set the Cap Server URL in the desktop app under Settings. That is the step that connects a self-hosted Cap Web instance to the recording client.

## Sources

- [CapSoftware/Cap on GitHub](https://github.com/CapSoftware/Cap)
- [Issues](https://github.com/CapSoftware/Cap/issues)
- [Project website](https://cap.so)
- [README](https://github.com/CapSoftware/Cap/blob/main/README.md)
- [Releases](https://github.com/CapSoftware/Cap/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/capsoftware-cap