[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fd33augw42rxv":3},{"code":4,"message":5,"data":6,"timestamp":63},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":27,"summary_md":28,"topic":29,"github_topics":32,"license":53,"homepage":54,"updated_at":55,"history":56},"CapSoftware\u002FCap",6,"Open source Loom alternative. Beautiful, shareable screen recordings.","Rust",23711,2148,94,1072,[16,22],{"id":17,"title":18,"points":19,"comments":20,"posted_at":21},41741422,"Show HN: Reintroducing Cap, the open source Loom alternative",57,10,"2024-10-04",{"id":23,"title":24,"points":25,"comments":25,"posted_at":26},40172949,"Cap – open-source alternative to Loom",1,"2024-04-26","Screen recording with shareable links and self-hosting, for teams that want to keep recordings off hosted platforms.","Cap is worth a serious look if your team pays for Loom and dislikes where the videos live. It is an open-source recorder plus sharing platform, so the decision is not just about capture quality but about running and maintaining the sharing side.\n\n## The problem\n\nSomeone records a bug walkthrough or product demo, then needs colleagues to watch it. With a conventional recorder, the file has to be uploaded, permissions sorted out and a link pasted into chat; with a hosted sharing service, the recording lands in a vendor's storage you may not control. Cap collapses this into one flow: record screen, camera and microphone, then either get a link immediately (Instant Mode uploads while recording) or open a local editor for trims, backgrounds, zooms and captions before sharing (Studio Mode). The result is a watchable page with comments, transcripts and analytics rather than an attachment.\n\n## What's different\n\nThe storage story is the real differentiator. Recordings can go to Cap Cloud, to an S3-compatible bucket such as AWS S3, Cloudflare R2, MinIO or Wasabi, or stay local, and the whole web platform can be self-hosted with Docker Compose. Desktop apps exist for macOS and Windows, with Rust crates handling capture and export and a Tauri app wrapping the desktop UI. That makes Cap a plausible replacement for a paid async-video tool rather than just a screen recorder.\n\nThe trade-off is scope. The repository is a Turborepo monorepo spanning a Next.js web app, a SolidStart desktop UI, a media server, a Discord bot, CLI and database packages, so self-hosting means operating web, API, database and media services together. The README also notes that its analytics setup command can remove Tinybird resources outside the checked-in configuration, a reminder that some bundled tooling is not read-only. For a quick personal recording, that machinery is overhead; for a team that already runs infrastructure, it is the reason to consider Cap.\n\n## Who should try it\n\nGood fit: a team currently sharing videos through a hosted service, with an S3 bucket or a small server available, that wants links on its own domain and control over retention. Also reasonable for an individual who mostly records local demos and exports files, since Studio Mode works without the sharing platform.\n\nPoor fit: someone who wants a zero-setup recorder and does not care where uploads live, or a team without anyone to own a self-hosted deployment. The README treats production use as a configuration task, requiring public URLs and replacement of default secrets before exposure, which is ongoing operational responsibility rather than a one-time install. Note also the split licence: camera and `scap-*` crates are MIT, most other code is AGPLv3.\n\n## Requirements and limitations\n\nRunning from source requires Node.js 24+, Bun 1.4.4, Rust 1.88+ and Docker for MySQL and MinIO, so building locally assumes a reasonably current toolchain across three ecosystems. Self-hosting via Docker Compose is the lighter path, but the guide expects email setup, AI provider configuration, SSL, storage and production hardening to be handled separately. Authentication is a recurring theme: login links are printed to service logs when email is not configured, and single-owner setups behind an authenticating proxy rely on a separate trusted-proxy configuration with a shared secret.\n\nOne older report is worth noting rather than treating as current: a commenter on the October 2024 Show HN thread said the desktop app did not complete authentication after browser sign-in. That thread is nearly two years old by the last HotRepo observation, so verify current login behaviour with your intended hosting model instead of assuming either outcome.\n\n## HotRepo's take\n\nHotRepo recorded Cap on the daily trending board twice, on 2026-10-24 (+81 stars) and 2026-10-25 (+94), reaching 23,705 stars in that sample. The two-day window is too short to judge whether interest is sustained or fading. For adoption, the concrete thing to confirm is the [self-hosting guide](https:\u002F\u002Fcap.so\u002Fdocs\u002Fself-hosting), specifically whether your storage, email and domain setup matches what the project documents before you move a team's recording library onto it.",{"slug":30,"name":31},"media","Media & Design",[33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52],"app","cap","coss","loom","mac","nextjs","nextjs15","open-source","oss","react","record","rust","screen-capture","screen-recorder","screenshot","solidjs","tauri","tauri-app","typescript","vite","NOASSERTION","https:\u002F\u002Fcap.so","2026-10-25T02:54:05Z",[57,61],{"date":58,"stars":59,"stars_gained":60},"2026-10-24",23694,81,{"date":62,"stars":11,"stars_gained":13},"2026-10-25",1792906115]