Snapify is a self-hosted, TypeScript screen recorder and asynchronous video sharing application, distributed under the AGPL-3.0 licence, for teams and individuals who want their recordings stored on infrastructure they control.

What it is

Snapify is a web application, written in TypeScript and published under the AGPL-3.0 licence, that records your screen and shares the result with anyone through a public link. Its README describes it plainly as "the self-hostable Loom alternative", and the project's own materials frame the goal as recording and sharing asynchronously, so a recording can stand in for a meeting rather than requiring everyone to attend one at the same time. The application lives in the modern JavaScript web stack: authentication runs through NextAuth with GitHub as the OAuth provider, the data layer is defined by a Prisma schema, and recordings are stored in an S3-compatible object bucket.

The concrete problem it solves is ownership of the recording pipeline. Rather than sending screen captures to a third-party hosted service, a Snapify deployment writes its records into a MySQL database that the operator provisions and stores media files in an object bucket that the operator creates. The development documentation walks through Backblaze B2 specifically, and instructs the operator to keep the bucket private so files are not made publicly available, which keeps distribution under the share link rather than under the storage layer. That is the specific thing it replaces: a hosted recording service whose links, storage and retention the user does not control.

Key capabilities

• Records the browser tab, the desktop, and any individual application, with unlimited recordings.
• Shares recordings with anyone through a public link.
• Deletes or un-lists recordings after a specific timeframe.
• Accepts uploads of existing videos for sharing alongside captured recordings.
• Authenticates users through GitHub OAuth, configured with GITHUB_ID, GITHUB_SECRET, and the callback route /api/auth/callback/github.
• Persists application data through Prisma into MySQL, initialised with npx prisma db push.
• Stores media in S3-compatible object storage configured via AWS_ENDPOINT, AWS_BUCKET_NAME, AWS_REGION, AWS_KEY_ID, and AWS_SECRET_ACCESS_KEY, and documents Backblaze B2 as the worked example.

Who uses it and how

• Teams that need asynchronous screen recording for collaboration but cannot or will not route recordings through a hosted SaaS vendor.
• Self-hosters who want full read and write control over a private object bucket, using Backblaze B2 as documented, so no file is publicly reachable outside a share link.
• Operators deploying to Vercel with a managed MySQL instance, supplying DATABASE_URL, NEXTAUTH_URL, NEXTAUTH_SECRET, and the GitHub and AWS credential set as environment variables.
• Developers working locally, who run npm run dev after npm i and a .env setup, and can verify the flow with the end-to-end suite at npm run test:e2e.
• Anyone who needs to circulate existing video files, since upload and share of pre-recorded video is a supported path.

Getting started

Clone https://github.com/MarconLP/snapify.git, run npm i, duplicate .env.example to .env and fill in the database, GitHub OAuth and S3 credentials, generate NEXTAUTH_SECRET with openssl rand -base64 32, push the schema with npx prisma db push, then start with npm run dev. For deployment, the README offers a Vercel button that clones the repository and prompts for the full environment variable set.

How it compares

The README names Loom directly, positioning Snapify as "the self-hostable Loom alternative". Where Loom is a hosted product, Snapify is run by the adopter on their own MySQL database and their own S3-compatible bucket, which places data ownership and retention with the operator. It is distributed under AGPL-3.0, so anyone redistributing the code or a modified version must comply with that licence as set out in LICENSE.md.

When to use it — and when not to

A self-hoster must operate a MySQL database, an S3-compatible object bucket, a GitHub OAuth application, and a host for the Next.js app, which is a real amount of infrastructure to keep running. It is a poor fit for anyone who wants a managed, zero-operations recording tool, or who cannot run a database and object store alongside the application. The project also shows signs of paused activity: the most recent push recorded here is 25 November 2024, with 23 open issues, and the AGPL-3.0 licence imposes distribution obligations on anyone who ships a modified version.

     1. Open [Railway](https://railway.app/) and click "Start a New Project", and select Provision "MySQL".
     2. Select the MySQL App and copy the `DATABASE_URL` into the `.env`.

     </details>

     1. Open [Github Developer Settings](https://github.com/settings/apps).
     2. Next, go to [OAuth Apps](https://github.com/settings/developers) from the side panel. Then click the "New OAuth App" button. Make sure to set `Authorization callback URL` to `/api/auth/callback/github` replacing Snapify URL with the URI at which your application runs.
     3. Copy the `Client ID` as `GITHUB_ID` into the `.env`.
     4. Next, click "Generate a new client secret" and copy the `Client secret` as `GITHUB_SECRET` into the `.env`.

     </details>

     1. Open [B2 Cloud Storage Buckets](https://secure.backblaze.com/b2_buckets.htm).
     2. Create a new Bucket, make sure to set the bucket to private to make sure files are not being made publicly available.
     3. Copy the `Endpoint` as `AWS_ENDPOINT` and the Bucket name as `AWS_BUCKET_NAME` into the `.env`. Additionally you need to add the `AWS_REGION`, which is part of the endpoint and should look like this: `us-east-005`.
     4. Next, go to [Application Keys](https://secure.backblaze.com/app_keys.htm) from the side panel. Then create a new Application Key, with full read and write access to the bucket.
     5. Copy the `keyID` as `AWS_KEY_ID` and the `applicationKey` as `AWS_SECRET_ACCESS_KEY` into the `.env`.

     </details>
  </details>

# In a terminal just run:
npm run test:e2e