Self-host a Loom alternative on Cloudflare

Start with the reviewed commit and deployment runbook

Open CaptureFlow’s project page and inspect the original README, license, Wrangler configuration and workflow. Our snapshot is pinned to commit ade77a3ed3a29f05d8c74a984f245c50b2967d79. Follow the deployment runbook at that commit rather than assuming an unreviewed newer revision has identical requirements.

The README requires Node 24.13 or newer, while the runbook says Node 20+. Use the stricter README requirement and check the package engine constraints. This source discrepancy is one reason a documented setup path is not the same as a tested installation.

Understand the infrastructure before provisioning

The web configuration defines a Worker serving the application and API, a DB D1 binding, a BUCKET R2 binding and an ASSETS binding. It also schedules hourly and daily tasks for multipart-upload cleanup and retention. The repository has additional admin and documentation Worker configurations; they are distinct surfaces, not resources to conflate with the basic web app.

Use your own Cloudflare account and resource identifiers. Replace upstream custom domains and public app URLs. Keep secrets out of source-controlled configuration and out of variables named NEXT_PUBLIC_*, which are intended to be public in the client bundle.

Configure a minimal instance

1. Install the pinned repository’s dependencies with its documented Node and pnpm requirements.
2. Create your own D1 database and R2 bucket, then update the web app’s bindings.
3. Review and apply the repository’s ordered database migrations to those resources.
4. Set the authentication secret and your actual application/authentication URLs.
5. Leave optional billing and email integrations disabled for the initial pilot.
6. Review the media-access design before deploying the web app or installing a recorder pointed at it.

The upstream runbook includes commands and the required variable names. Read each step against your own configuration rather than copying resource IDs or domains from another installation. Enabling R2 may require a card on file even when usage fits free allowances.

Decide whether media is public or private

The documented default reads videos, posters and screenshots from a public R2 CDN origin. That can be appropriate for intentionally public share links. It is insufficient evidence of access protection for confidential recordings.

For a private instance, assess authentication on the media-serving path, how links expire, browser range requests and whether storage endpoints remain reachable without the application session. Validate the actual object response with an unauthenticated recipient before putting private material in the bucket.

Verify the whole recording lifecycle

Test sign-in, recorder configuration, a short recording, a long recording, interrupted uploads, playback startup, seeking, microphone/system audio and the recipient device. Check that completed recordings appear in the dashboard and that cleanup and retention jobs do what you expect. Establish a database and media recovery procedure before expanding use.

Monitor Worker CPU and requests, D1 activity and R2 storage/operations against the current free allowances. Optional providers, domains and maintenance time remain separate costs. The Loom pricing guide, comparison and alternatives shortlist help decide whether owning this workflow is worthwhile.