Forem: Alex Neamtu

GDPR-Compliant Screen Recording for Teams: What You Actually Need

Alex Neamtu — Tue, 31 Mar 2026 12:19:48 +0000

Your team records screen videos every day — product demos, bug reports, training walkthroughs, client updates. Each one potentially contains personal data: email addresses visible in a dashboard, names in a CRM, analytics with user IPs, or even a Slack notification popping up mid-recording.

Under GDPR, that makes your screen recording tool a data processor. And most teams don't think about this until legal asks the question.

What GDPR actually requires from your video tools

GDPR doesn't ban screen recording. It requires you to control where personal data goes, who processes it, and how long it's kept. For a screen recording tool, that means:

1. Data residency

Where are your videos stored? If your tool uploads recordings to US servers, that data transfer needs a legal basis under GDPR. Since the Schrems II ruling invalidated the Privacy Shield framework, relying on Standard Contractual Clauses alone has become legally shaky — especially for video content that may contain sensitive personal data.

The simplest approach: keep videos on EU infrastructure. No transfer, no legal gymnastics.

2. Sub-processors

Your screen recording tool likely uses other services: cloud storage (AWS, GCP), CDN for delivery, AI for transcription, analytics for tracking. Each one is a sub-processor under GDPR. You need to know who they are and have appropriate agreements in place.

Many popular tools have long sub-processor lists that include US-based companies. Each one is a potential compliance risk.

3. Data Processing Agreement (DPA)

You need a DPA with your screen recording provider. This should cover what data is processed, the purpose, retention periods, and deletion procedures. Most enterprise tools offer these. Many free tiers don't.

4. Retention and deletion

GDPR requires data minimization — don't keep personal data longer than necessary. Your screen recording tool should let you set retention periods and automatically delete old videos. Bonus points if it lets you delete individual videos on request (right to erasure).

5. Access controls

Who can see the recordings? If a video contains customer data, it shouldn't be accessible to everyone in the company. Role-based access, password protection on shared links, and link expiry are practical controls that support GDPR compliance.

What most screen recording tools get wrong

US-hosted by default

Loom, Zight, and most mainstream tools host everything on AWS US regions. Your video data crosses the Atlantic before your viewer even clicks play. Some offer EU hosting on enterprise plans, but that's typically $20+/user/month with annual commitments.

Invisible sub-processors

That "AI transcription" feature? It might be sending your audio to OpenAI's API, which processes data on US infrastructure. That CDN making your videos load fast? Cloudflare or AWS CloudFront, both US companies. These details are buried in privacy policies that nobody reads.

No retention controls

Most free and mid-tier plans keep your videos forever — or until you manually delete them. There's no way to set automatic expiry. When an employee leaves and their account has 200 recordings containing customer data, you have a compliance problem.

Tracking on watch pages

When someone views your shared video, many tools load third-party analytics (Google Analytics, Mixpanel, Intercom) on the watch page. Your viewer didn't consent to being tracked by these services. Under GDPR, that's your problem.

A practical checklist

Before choosing a screen recording tool, ask these questions:

Data location:

Where are videos stored? (country and provider)
Where is audio processed for transcription?
Are any CDNs or proxies in the delivery path?

Legal:

Is a DPA available? (even on free tier?)
What sub-processors are listed?
Can you get EU-only hosting without an enterprise contract?

Technical controls:

Can you set video retention periods?
Can you password-protect shared links?
Can you set link expiry dates?
Can you delete videos on demand?
What tracking loads on watch pages?

Access:

Role-based access for team members?
Can you restrict who sees which recordings?
SSO integration for centralized access management?

Self-hosting: the compliance shortcut

If you can run your own infrastructure, self-hosting eliminates most GDPR complexity. There are no sub-processors because you are the processor. Data residency is wherever you deploy. Retention is whatever you configure.

The trade-off is operational: you're responsible for backups, updates, and uptime. But for teams that already run Docker containers in production, adding a screen recording tool is straightforward.

Tools like SendRec (which I build) run as a single Docker Compose stack — the app, PostgreSQL, and S3-compatible storage. Deploy it on a Hetzner server in Germany or Finland and your compliance story becomes very simple: all data stays on infrastructure you control, in the EU, with no third parties.

The managed middle ground

Not every team wants to self-host. If you prefer a managed service, look for these specifics:

EU-only infrastructure with no US fallback — not just "data is stored in EU" but "data never touches US servers at any point"
No third-party AI processing — transcription should happen on the provider's own infrastructure, not via external APIs
Cookie-free analytics on watch pages — tools like Umami or Plausible track views without setting cookies or loading third-party scripts
Transparent sub-processor list that you can actually verify

What about consent for recording?

GDPR compliance for screen recording isn't just about where data is stored. If your recording captures other people's data — a customer's name in a CRM, a colleague's message in Slack — you need a legal basis for processing that data.

For internal team recordings, legitimate interest usually applies. For recordings shared externally (client demos, support videos), consider:

Telling viewers the video may contain personal data
Using password protection or email gates to control access
Setting expiry dates so recordings don't persist indefinitely
Avoiding recording screens that show sensitive customer data when possible

Summary

GDPR-compliant screen recording isn't complicated, but it requires intentional tool choices. The key decisions:

Keep data in the EU — avoid tools that default to US hosting
Know your sub-processors — fewer is better
Set retention policies — don't keep videos forever
Control access — passwords, expiry, roles
Minimize tracking — no third-party scripts on watch pages

The simplest path is self-hosting an open source tool on EU infrastructure. The next best option is a managed service with transparent EU-only hosting and minimal sub-processors.

If you're evaluating tools, we wrote a detailed comparison of open source Loom alternatives that covers data residency, pricing, and features across the main options.

Open Source Loom Alternatives in 2026: A Practical Comparison

Alex Neamtu — Sun, 22 Mar 2026 08:32:25 +0000

Loom changed how teams communicate asynchronously. But as Atlassian pushes prices higher and more organizations ask where their video data actually lives, the search for alternatives has grown.

This post compares the open source options available today. I built one of them (SendRec), so I'll be upfront about that bias — but I'll try to be honest about where each tool shines and where it doesn't.

Why open source matters for screen recording

Screen recordings often contain sensitive information: product demos with unreleased features, internal discussions, customer data visible on screen, credentials accidentally shown. Where that data lives — and who controls it — matters more than most teams realize.

Open source screen recording tools give you three things proprietary tools can't:

Audit the code. You can verify there's no telemetry, no data exfiltration, no hidden upload to third-party services.
Self-host. Your videos stay on infrastructure you control. No third-party cloud provider in the data path.
No vendor lock-in. If the project dies or changes direction, you have the source code. Export your data and move on.

The contenders

Loom (proprietary baseline)

Loom isn't open source, but it's the tool everyone compares against, so it's worth including as a reference point.

What it does well: Polish. Loom's desktop app and Chrome extension are smooth. The editing tools (trim, stitch, filler word removal) work reliably. AI-generated summaries and chapters are available on the Business tier. The brand recognition means recipients know what a Loom link is.

The trade-offs:

Pricing: $15–20/user/month. AI features locked to the $20 Business tier. Enterprise pricing is opaque.
Free tier: 25 videos total (not per month), 5-minute max, 720p only.
Data: US-hosted on AWS. No option for EU data residency. No self-hosting.
Lock-in: Closed source. If Atlassian changes pricing or shuts it down, your video library is at risk.

Loom is the right choice if your team is US-based, budget isn't a concern, and data residency doesn't matter.

Cap

Cap is a newer open source screen recorder with a growing community (17,000+ GitHub stars). It takes a desktop-app-first approach.

What it does well: Beautiful desktop app for macOS and Windows. Local-first recording with optional cloud upload. The Studio editing mode offers frame-level control. Lifetime license option ($58) is attractive for individual users.

The trade-offs:

Desktop app required. No browser-based recording. This is a dealbreaker for some teams — you can't send someone a link and say "record a response."
No Linux support. Desktop app is macOS and Windows only.
Commercial use requires paid license. The AGPL license is open source, but Cap's commercial license prohibits free commercial use. If your company uses it, you need the paid plan.
Limited team features. No workspaces, no role-based access, no SSO, no SCIM. It's designed for individual creators, not teams.
US-based. Cloud storage is US-hosted. Self-hosting is possible but the documentation is more focused on the cloud offering.
No comments or reactions on videos. Collaboration happens outside the tool.

Cap is the right choice if you want a polished desktop recording app for personal use and don't need team features or browser-based recording.

Zight (formerly CloudApp)

Zight rebranded from CloudApp in 2023. It's a screenshot and screen recording tool aimed at support and sales teams.

What it does well: Quick screenshots and GIF creation alongside video recording. Good integrations with support tools. Annotation tools for marking up screenshots.

The trade-offs:

Not open source. Closed source, US-hosted on AWS.
Free tier expires old content. Only your last 50 uploads are accessible — older ones disappear. This is a nasty surprise if you're not expecting it.
Pricing: $9–11/user/month. Less expensive than Loom but still adds up for teams.
Limited video features. No comments, no reactions, no email gate, no embeddable player, no custom thumbnails. It's primarily a screenshot tool that also does video.
No self-hosting. No option to run on your own infrastructure.

Zight is the right choice if screenshots are your primary use case and video is secondary.

SendRec

SendRec is what I've been building — an open source async video platform focused on EU data residency and team use cases. Full disclosure: I'm the developer.

What it does well:

Browser-based recording. Screen, camera, or both. No desktop app required, works on any OS.
Full team features. Workspaces with roles (owner, admin, member, viewer), SSO (OIDC + SAML), SCIM provisioning, per-workspace branding and billing.
Rich video features. Timestamped comments, reactions, password-protected links, email gate, embeddable player, analytics with per-viewer engagement data, custom CTAs.
AI transcription. 99 languages via whisper.cpp, AI summaries, chapters, filler word removal, trim by transcript. Bring your own model — no data sent to external AI services.
Self-hosting. Single Docker Compose command. Go binary + PostgreSQL + S3-compatible storage. Runs on a $10/month VPS.
EU data residency. Managed instance runs on Hetzner in Germany. No US cloud providers in the data path.

The trade-offs:

No desktop app. Browser-only recording. Works well for most use cases, but you can't record native app windows that block screen capture.
Smaller community. ~40 GitHub stars vs Cap's 17,000+. The project is younger and less proven.
Solo developer. I'm building this as one person. Response times for issues are reasonable but not instant.
Free tier has limits. 25 videos/month, 5-minute max duration on the managed instance. Self-hosted has no limits.

SendRec is the right choice if your team needs EU data residency, self-hosting, or team features like SSO and workspaces alongside async video.

Feature comparison

Feature	Loom	Cap	Zight	SendRec
Open source	No	Yes (AGPL)	No	Yes (AGPL)
Self-hostable	No	Yes	No	Yes
Browser recording	Yes	No	Yes	Yes
Desktop app	Yes	Yes	Yes	No
Linux support	Yes	No	No	Yes
Team workspaces	Yes	No	Limited	Yes
SSO / SAML	Enterprise	No	Enterprise	Yes (Pro)
SCIM provisioning	Enterprise	No	No	Yes
Comments	Yes	No	No	Yes
AI transcription	$20/user	Paid	No	Yes (free, local)
Per-viewer analytics	Yes	No	No	Yes
Password protection	Yes	No	Yes	Yes
Email gate	Yes	No	No	Yes
Custom branding	Enterprise	No	No	Yes (Pro)
EU data residency	No	No	No	Yes
Free commercial use	N/A	No	N/A	Yes

Pricing comparison

Tier	Loom	Cap	Zight	SendRec
Free	25 videos total, 5 min, 720p	Local only, no commercial use	Last 50 uploads, 5 min	25 videos/month, 5 min
Paid	$15–20/user/month	$12/month or $58 lifetime	$9–11/user/month	€8–12/month
Self-hosted	N/A	Free (non-commercial)	N/A	Free, unlimited

Which one should you pick?

Choose Loom if: Budget isn't a concern, you want maximum polish, your team is US-based, and data residency doesn't matter.

Choose Cap if: You want a beautiful desktop recording app for personal use and don't need team features or browser recording.

Choose Zight if: Screenshots are your primary workflow and video is a secondary feature.

Choose SendRec if: You need EU data residency, want to self-host, or need team features (SSO, workspaces, SCIM) with an open source tool you can audit.

Try them

Loom — sign up for free tier
Cap — download the desktop app
Zight — sign up for free tier
SendRec — sign up or self-host from GitHub

If you're evaluating async video tools for your team and have questions about any of these, feel free to reach out at hello@sendrec.eu. Happy to help even if you don't end up choosing SendRec.

How We Built Data Retention for SendRec

Alex Neamtu — Thu, 05 Mar 2026 09:54:50 +0000

Video recordings accumulate. A team of ten recording three videos a day produces over 800 recordings a year. Some of those are important. Most are not. Without automatic cleanup, storage grows indefinitely and you end up violating your own data retention policies.

SendRec now has built-in data retention. Configure a retention period at the user or workspace level, pin the videos you want to keep forever, and everything else gets automatically deleted after a 7-day warning email.

Here's how we built it.

Why data retention matters

Three reasons drove this feature:

GDPR data minimization. Article 5(1)(e) requires that personal data is kept only as long as necessary. Video recordings often contain faces, voices, and screen content with personal data. A configurable retention period lets organizations enforce this automatically.

Storage costs. For self-hosted deployments, S3 storage is a real line item. Auto-deleting old recordings keeps costs predictable.

Enterprise compliance. ISO 27001 and SOC 2 audits ask for documented data retention policies with enforcement mechanisms. A dropdown in settings and an automated worker is a concrete answer.

The data model

Three columns across two existing tables handle the configuration:

-- Migration 000051
ALTER TABLE organizations ADD COLUMN retention_days INT NOT NULL DEFAULT 0;
ALTER TABLE users ADD COLUMN retention_days INT NOT NULL DEFAULT 0;
ALTER TABLE videos ADD COLUMN pinned BOOLEAN NOT NULL DEFAULT false;
ALTER TABLE videos ADD COLUMN retention_warned_at TIMESTAMPTZ;

retention_days = 0 means disabled. Valid values are 0, 30, 60, 90, 180, and 365. The pinned flag lets users exempt individual videos from auto-deletion. retention_warned_at tracks whether the 7-day warning email has been sent.

The interesting design decision is the resolution order. Workspace videos use the organization's retention_days. Personal videos use the user's retention_days. This means a workspace admin sets the policy once and it applies to every video in the workspace, while personal accounts control their own.

The two-pass worker

The retention worker runs on a daily ticker and does two things: warn, then delete. Separating these into two passes with a 7-day gap means users always get a chance to pin important videos before they disappear.

func StartRetentionWorker(ctx context.Context, db database.DBTX, sender RetentionSender, baseURL string) {
    if sender == nil {
        return
    }
    go func() {
        slog.Info("retention-worker: started")

        processRetentionWarnings(ctx, db, sender, baseURL)
        processRetentionDeletions(ctx, db)

        ticker := time.NewTicker(24 * time.Hour)
        defer ticker.Stop()
        for {
            select {
            case <-ctx.Done():
                slog.Info("retention-worker: shutting down")
                return
            case <-ticker.C:
                processRetentionWarnings(ctx, db, sender, baseURL)
                processRetentionDeletions(ctx, db)
            }
        }
    }()
}

Both passes run on startup and then every 24 hours. The nil sender check means if email isn't configured, the worker silently skips.

Pass 1: Warn

The warning query is the most interesting part. It needs to resolve the correct retention period from either the organization or the user, depending on which one the video belongs to:

rows, err := db.Query(ctx,
    `SELECT v.id, v.title, v.share_token, u.email,
            COALESCE(o.retention_days, u.retention_days) AS retention_days
     FROM videos v
     JOIN users u ON u.id = v.user_id
     LEFT JOIN organizations o ON o.id = v.organization_id
     WHERE v.status = 'ready'
       AND v.pinned = false
       AND v.retention_warned_at IS NULL
       AND COALESCE(o.retention_days, u.retention_days) > 0
       AND v.created_at < now() - make_interval(days => COALESCE(o.retention_days, u.retention_days) - 7)
     LIMIT 100`)

COALESCE(o.retention_days, u.retention_days) does the resolution: if the video belongs to a workspace (organization_id is not null), the LEFT JOIN returns the org's setting. For personal videos, o.retention_days is null and we fall through to the user's setting.

The - 7 in the age check is the grace period. A 90-day retention policy triggers the warning at day 83, giving users 7 days to pin anything they want to keep.

Results are grouped by email address so each user gets a single email listing all their expiring videos, not one email per video:

grouped := make(map[string][]videoEntry)

for rows.Next() {
    var id, title, shareToken, userEmail string
    var days int
    rows.Scan(&id, &title, &shareToken, &userEmail, &days)
    grouped[userEmail] = append(grouped[userEmail], videoEntry{
        id: id, title: title, shareToken: shareToken, days: days,
    })
}

After sending the email, we mark each video with retention_warned_at = now() so the same video doesn't trigger another warning on the next tick.

Pass 2: Delete

The deletion pass is simpler. It looks for videos that were warned at least 7 days ago and are still not pinned:

rows, err := db.Query(ctx,
    `SELECT id FROM videos
     WHERE retention_warned_at IS NOT NULL
       AND retention_warned_at < now() - interval '7 days'
       AND status = 'ready'
       AND pinned = false
     LIMIT 100`)

If a user pinned a video after receiving the warning, the pinned = false filter excludes it. The deletion itself is a soft delete -- we set status = 'deleted' and remove the video from any playlists. The existing cleanup worker handles purging the actual S3 files later.

db.Exec(ctx, "DELETE FROM playlist_videos WHERE video_id = ANY($1)", videoIDs)
db.Exec(ctx, "UPDATE videos SET status = 'deleted' WHERE id = ANY($1)", videoIDs)

Both passes process 100 videos at a time. With a daily tick this handles up to 100 warnings and 100 deletions per day, which is more than sufficient for typical usage. Larger deployments will process the backlog over multiple days without spiking database load.

The pin toggle

Pinning is a one-click toggle on the VideoDetail page. The handler flips the boolean and returns the new state:

func (h *Handler) TogglePin(w http.ResponseWriter, r *http.Request) {
    videoID := chi.URLParam(r, "id")
    where, args := orgVideoFilter(r.Context(), videoID, nil, "AND status != 'deleted'")

    var pinned bool
    err := h.db.QueryRow(r.Context(),
        "UPDATE videos SET pinned = NOT pinned, updated_at = now() WHERE "+where+" RETURNING pinned", args...,
    ).Scan(&pinned)
    if err != nil {
        httputil.WriteError(w, http.StatusNotFound, "video not found")
        return
    }

    httputil.WriteJSON(w, http.StatusOK, map[string]bool{"pinned": pinned})
}

UPDATE ... SET pinned = NOT pinned ... RETURNING pinned is atomic -- no race condition between reading the current value and writing the new one. The frontend shows a pin icon that toggles between filled and outlined, plus a "Pinned" badge when active. Pinned videos also show a pin indicator on library cards.

The warning email

Warning emails go through Listmonk via our existing transactional email pipeline. The email lists each expiring video with its title and watch link, plus the deletion date:

func (c *Client) SendRetentionWarning(ctx context.Context, toEmail string, videos []RetentionVideoSummary, expiryDate string) error {
    if c.config.RetentionWarningTemplateID == 0 {
        slog.Warn("retention warning template ID not set, skipping", "recipient", toEmail)
        return nil
    }

    c.ensureSubscriber(ctx, toEmail, "")

    body := txRequest{
        SubscriberEmail: toEmail,
        TemplateID:      c.config.RetentionWarningTemplateID,
        Data: map[string]any{
            "videos":     videos,
            "expiryDate": expiryDate,
        },
        ContentType: "html",
    }

    return c.sendTx(ctx, body)
}

Two details worth noting. First, retention warnings bypass the email allowlist. These are critical notifications -- users need to know their videos are about to be deleted, even in development environments with restricted email sending. Second, if the template ID is zero (not configured), the function returns nil without error. This lets self-hosted instances run without Listmonk configured; videos will still be deleted on schedule, just without the warning.

What we learned

Two passes are simpler than one. We initially considered a single query that calculates the deletion date and groups videos by urgency. The two-pass approach is much cleaner: pass 1 sends warnings, pass 2 deletes warned videos. Each query is simple and testable.

COALESCE handles the org/user resolution in SQL. We considered resolving the retention policy in Go code by querying the org and user separately. Doing it in the query with COALESCE and a LEFT JOIN means one database round trip instead of two, and the filter logic stays in the same place as the data.

Soft delete cascades naturally. Setting status = 'deleted' means the video immediately disappears from the API (all list queries filter on status). The existing S3 cleanup worker picks up deleted videos later. No new cleanup code needed.

Try it

Data retention is live at app.sendrec.eu. Go to Settings, set a retention period, and pin any videos you want to keep forever.

Self-hosting? Pull the latest image and the migration runs automatically. Set DEFAULT_RETENTION_DAYS to configure the default for new accounts, and LISTMONK_RETENTION_WARNING_TEMPLATE_ID if you want warning emails.

Source code: github.com/sendrec/sendrec

How We Added Jira and GitHub Integrations to SendRec

Alex Neamtu — Tue, 03 Mar 2026 11:30:02 +0000

You record a bug. You watch it back. You open Jira, create a ticket, paste the video link, copy the transcript, and fill in the title. That's four context switches for something that should take one click.

SendRec now has built-in Jira and GitHub integrations. From any video, click "Create Issue" and a ticket appears in your project tracker with the video link and a transcript excerpt already attached.

Here's how we built it.

The IssueCreator interface

We wanted to support multiple providers without the handler knowing which one it's talking to. A simple interface does the job:

type IssueCreator interface {
    CreateIssue(ctx context.Context, req CreateIssueRequest) (*CreateIssueResponse, error)
    ValidateConfig(ctx context.Context) error
}

type CreateIssueRequest struct {
    Title       string
    Description string
    VideoURL    string
}

CreateIssue files the ticket. ValidateConfig checks credentials before you save — so you find out immediately if your token is wrong, not when you try to file your first bug.

Adding a new provider means implementing two methods. The handler, the settings UI, and the config storage don't change.

GitHub: Bearer token and markdown

GitHub Issues have a straightforward API. POST to /repos/{owner}/{repo}/issues with a Bearer token:

func (c *GitHubClient) CreateIssue(ctx context.Context, req CreateIssueRequest) (*CreateIssueResponse, error) {
    body := map[string]any{
        "title": req.Title,
        "body":  formatGitHubBody(req),
    }
    bodyJSON, _ := json.Marshal(body)

    url := fmt.Sprintf("%s/repos/%s/%s/issues", c.baseURL, c.owner, c.repo)
    httpReq, _ := http.NewRequestWithContext(ctx, "POST", url, bytes.NewReader(bodyJSON))
    httpReq.Header.Set("Authorization", "Bearer "+c.token)
    httpReq.Header.Set("Content-Type", "application/json")

    resp, err := http.DefaultClient.Do(httpReq)
    // ...
}

The issue body is markdown with the video link prominent and the transcript in a collapsible <details> block so it doesn't overwhelm the ticket:

func formatGitHubBody(req CreateIssueRequest) string {
    body := fmt.Sprintf("**Video:** %s\n\n", req.VideoURL)
    if req.Description != "" {
        body += "<details>\n<summary>Transcript</summary>\n\n"
        body += req.Description
        body += "\n\n</details>"
    }
    return body
}

ValidateConfig hits two endpoints: GET /user to verify the token works, then GET /repos/{owner}/{repo} to confirm the repo exists and the token has access.

Jira: Basic auth and Atlassian Document Format

Jira Cloud uses Basic auth (email + API token, base64-encoded) and requires the Atlassian Document Format (ADF) instead of plain text or markdown. ADF is a JSON tree that describes rich content:

func buildADFDescription(req CreateIssueRequest) map[string]any {
    content := []any{adfParagraph(adfInlineCard(req.VideoURL))}
    if req.Description != "" {
        content = append(content,
            adfParagraph(adfText("Transcript:")),
            adfCodeBlock(req.Description),
        )
    }
    return map[string]any{"version": 1, "type": "doc", "content": content}
}

The video URL renders as an inline card in Jira — Atlassian automatically fetches the page metadata and shows a rich preview. The transcript goes in a code block to preserve formatting.

ValidateConfig calls GET /rest/api/3/myself — the simplest authenticated endpoint Jira offers. If it returns 200, your credentials work.

Encrypting API tokens at rest

Integration configs live in a user_integrations table as JSONB. Storing API tokens in plaintext would be reckless, even in a self-hosted database. We encrypt token fields with AES-256-GCM before writing them:

func Encrypt(key []byte, plaintext string) (string, error) {
    block, _ := aes.NewCipher(key)
    gcm, _ := cipher.NewGCM(block)

    nonce := make([]byte, gcm.NonceSize())
    io.ReadFull(rand.Reader, nonce)

    sealed := gcm.Seal(nonce, nonce, []byte(plaintext), nil)
    return base64.StdEncoding.EncodeToString(sealed), nil
}

The encryption key is derived from the existing JWT_SECRET environment variable via SHA-256 — no new secrets to configure. Each encryption uses a random nonce, so the same token produces different ciphertexts each time.

When listing integrations, we decrypt the token, then mask it (show first 4 characters, replace the rest with asterisks). The full token never leaves the server after initial save.

One subtlety: when a user edits their config (say, changing the repo name) without re-entering the token, the frontend sends the masked value back. The backend detects this, loads the existing encrypted token from the database, and preserves it. No accidental token loss.

The settings UI

Each provider gets a collapsible card in Settings. Connected providers show a green "Connected" badge. Expand the card to see the config fields, pre-filled from saved data (with tokens masked).

Three buttons per provider:

Save — validates all required fields, encrypts tokens, upserts the config
Test Connection — calls ValidateConfig against the live API
Disconnect — deletes the config entirely

Creating issues from videos

On the VideoDetail page, a "Create Issue" button appears if you have at least one integration configured. If you have both GitHub and Jira connected, it becomes a dropdown so you can pick which tracker to file in.

Clicking it sends the video's title, share URL, and a transcript excerpt (first 500 characters) to the provider. The response includes the issue URL, which opens in a new tab.

What we learned

Keep the provider interface minimal. Two methods — CreateIssue and ValidateConfig — are enough. We were tempted to add ListProjects, GetIssueTypes, and other discovery methods, but that would couple the UI to each provider's data model. A flat config with required fields (token, owner, repo for GitHub; base URL, email, API token, project key for Jira) is simpler and works.

Encrypt at the boundary. Token encryption happens in the handler, not in the provider clients. The GitHub and Jira clients receive plaintext tokens and don't know encryption exists. This keeps the providers testable with simple string arguments.

Test against real API shapes. Both providers have test suites using httptest.Server that return realistic response payloads. This caught a bug early — Jira's create-issue response uses key (like PROJ-123), not id, for the issue identifier.

Try it

The integrations are live at app.sendrec.eu. Go to Settings, expand GitHub or Jira, enter your credentials, and hit Test Connection. Then open any video and click Create Issue.

Self-hosting? Pull the latest image and the migration runs automatically. No new environment variables needed — encryption uses your existing JWT_SECRET.

Source code: github.com/sendrec/sendrec

SendRec Now Supports Team Workspaces

Alex Neamtu — Sun, 01 Mar 2026 10:55:53 +0000

SendRec has always been a single-user tool. You record, you share, you see who watched. That works for solo use, but teams need shared libraries, permissions, and a way to manage who can do what.

v1.70.0 added team workspaces, and subsequent releases have expanded them with a viewer role, video transfer between scopes, and workspace-level SSO. Here's how it all works.

What you get

Shared video libraries. Create a workspace, invite your team, and everyone's recordings and uploads live in one place. Videos belong to either your personal account or a workspace — never both. Switch between them with the workspace switcher in the nav bar.

Role-based permissions. Four roles: owner, admin, member, and viewer.

Action	Owner	Admin	Member	Viewer
View all workspace videos	Yes	Yes	Yes	Yes
Download videos	Yes	Yes	Yes	Yes
View analytics	Yes	Yes	Yes	Yes
Comment on videos	Yes	Yes	Yes	Yes
Create/record videos	Yes	Yes	Yes	No
Upload videos	Yes	Yes	Yes	No
Edit/delete own videos	Yes	Yes	Yes	No
Edit/delete others' videos	Yes	Yes	No	No
Manage folders and tags	Yes	Yes	Yes	No
Manage branding	Yes	Yes	No	No
Invite/remove members	Yes	Yes	No	No
Change member roles	Yes	No	No	No
Transfer videos	Yes	Yes	Yes	No
Delete workspace	Yes	No	No	No
Manage billing	Yes	No	No	No
Configure SSO	Yes	Yes	No	No

Viewers are free — they don't count toward your member limit. Add stakeholders, clients, or executives who need to watch and comment without taking up a paid seat.

Video transfer. Move videos between your personal account and any workspace you belong to. Transfer preserves comments and view counts. Folder assignments and tags are cleared on transfer since they're scope-specific. Videos must be in "ready" status to transfer — processing videos are blocked.

Email invites. Invite teammates by email. They get a link, create an account (or log in if they already have one), and land in the workspace. Pending invites are visible in workspace settings and can be revoked before acceptance.

Workspace branding and billing. Each workspace can have its own logo, colors, and footer — separate from personal branding. Billing works per-workspace: upgrade the workspace to Pro or Business directly.

Workspace SSO. Business plan workspaces can configure OIDC-based SSO. Connect your identity provider, and members can log in with their corporate credentials. Optionally enforce SSO so non-SSO logins are blocked for workspace members.

Free tier limits

1 workspace per user (as owner)
3 members per workspace (viewers don't count)
Pro and Business remove both limits

For self-hosters

Update your Docker image to latest and restart. The database migration runs automatically on startup — no manual steps. Workspaces are available immediately with no additional configuration.

docker compose pull sendrec
docker compose up -d sendrec

How we built it

The implementation touches every layer of the stack.

Database. Three core tables: organizations, organization_members, and organization_invites. Videos, folders, tags, analytics, and branding all gained an organization_id foreign key. SSO configuration lives in organization_sso_configs with AES-256-GCM encrypted client secrets.

Backend. A new internal/organization/ package handles CRUD, member management, invites, and middleware. The Middleware verifies membership and injects the user's role into the request context. RequireWriter blocks viewer-role users from all write endpoints — videos, folders, tags, and playlists. Every video handler uses a shared orgVideoFilter helper that builds the correct WHERE clause based on role.

Frontend. The workspace switcher persists your selection in localStorage. The API client reads it and sends an X-Organization-Id header on every request. Workspace settings has sections for general info, members, invites, billing, SSO, and a danger zone. The viewer role conditionally hides all write actions — record, upload, edit, delete, pin, trim, organize — while keeping read actions visible.

Tests. 724 frontend unit tests, 874+ backend tests across 18 packages, and 18 Playwright E2E tests covering workspace CRUD, viewer restrictions, and video transfer.

API

All workspace endpoints are documented in the API reference under the Organizations tag. Key endpoints:

POST /api/organizations — create a workspace
POST /api/organizations/{orgId}/invites — invite a member
POST /api/invites/accept — accept an invitation
PATCH /api/organizations/{orgId}/members/{userId} — change a member's role
POST /api/videos/{id}/transfer — move a video between scopes

Set the X-Organization-Id header on any request to scope it to a workspace.

SendRec is open source and self-hostable. Try it at app.sendrec.eu or run it on your own infrastructure with Docker Compose.

How We Built a Welcome Email That Actually Gets Sent

Alex Neamtu — Thu, 26 Feb 2026 07:16:22 +0000

Most SaaS products send a welcome email the moment you sign up. The problem: if the user hasn't confirmed their email yet, you're sending a "start using the product" message to someone who can't log in. They have to find the confirmation email first, click the link, then come back. The welcome email gets buried.

We wanted the welcome email to arrive at exactly the right moment — after the user confirms their email address and can actually use the product.

The confirmation flow

SendRec requires email verification before login. Here's what happens when someone registers:

User fills out the registration form
Backend creates the account with email_verified = false
Confirmation email is sent with a 24-hour token
User clicks the link
Backend sets email_verified = true
User can now log in

Step 5 is where the welcome email belongs. The user just proved they own the email address, and their next action is to log in and start recording. The welcome email should be waiting in their inbox with a direct link.

The implementation

We use Listmonk for transactional email — it's open source, self-hosted, and speaks a simple HTTP API. Our Go backend already had an email client with methods for password resets, comment notifications, view notifications, and confirmation emails. Adding a welcome email followed the same pattern.

The email client

The email package wraps Listmonk's transactional API. Each email type is a method that takes the recipient details and template-specific data:

func (c *Client) SendWelcome(ctx context.Context, toEmail, toName, dashboardURL string) error {
    if c.config.BaseURL == "" {
        slog.Warn("email not configured, welcome email skipped", "recipient", toEmail)
        return nil
    }

    if c.config.WelcomeTemplateID == 0 {
        slog.Warn("welcome template ID not set, skipping welcome email", "recipient", toEmail)
        return nil
    }

    c.ensureSubscriber(ctx, toEmail, toName)

    body := txRequest{
        SubscriberEmail: toEmail,
        TemplateID:      c.config.WelcomeTemplateID,
        Data: map[string]any{
            "name":         toName,
            "dashboardURL": dashboardURL,
        },
        ContentType: "html",
    }

    return c.sendTx(ctx, body)
}

Two guard clauses handle graceful degradation. If Listmonk isn't configured (BaseURL is empty), the method logs a warning and returns nil — self-hosters who don't run Listmonk won't see errors. If the template ID isn't set, same thing. The application never crashes because email is down.

Bypassing the allowlist

We have an email allowlist feature for staging environments. When set, only emails matching specific domains or addresses get sent. This prevents test runs from emailing real users.

But confirmation and welcome emails must always be sent — they're part of the core authentication flow. A user on staging who can't confirm their email can't test anything. So both methods bypass the allowlist check:

// Welcome emails bypass the allowlist — they are part of the core
// onboarding flow and must always be sent after email confirmation.
c.ensureSubscriber(ctx, toEmail, toName)

Compare this with the view notification method, which checks the allowlist first:

if !c.isAllowed(toEmail) {
    return nil
}

Triggering after confirmation

The ConfirmEmail handler already updates email_verified in the database. We added the welcome email call right after:

if _, err := h.db.Exec(r.Context(),
    "UPDATE users SET email_verified = true, updated_at = now() WHERE id = $1",
    userID,
); err != nil {
    httputil.WriteError(w, http.StatusInternalServerError, "failed to verify email")
    return
}

if h.emailSender != nil {
    var userEmail, userName string
    if err := h.db.QueryRow(r.Context(),
        "SELECT email, name FROM users WHERE id = $1", userID,
    ).Scan(&userEmail, &userName); err != nil {
        slog.Error("confirm-email: failed to load user for welcome email", "error", err)
    } else {
        if err := h.emailSender.SendWelcome(r.Context(), userEmail, userName, h.baseURL); err != nil {
            slog.Error("confirm-email: failed to send welcome email", "error", err)
        }
    }
}

A few design decisions here:

The welcome email is best-effort. If the database query fails or Listmonk is down, we log the error but still return a success response. The user confirmed their email — that worked. The welcome email is a nice-to-have, not a gate.

We query for the user's email and name. The ConfirmEmail handler only has the userID from the confirmation token lookup. We need the email and name to personalize the welcome message, so we make one additional query.

The emailSender nil check handles the case where the email system isn't configured at all. This is common in development and testing.

The interface

The EmailSender interface in the auth package defines what the auth handler needs from the email system:

type EmailSender interface {
    SendPasswordReset(ctx context.Context, toEmail, toName, resetLink string) error
    SendConfirmation(ctx context.Context, toEmail, toName, confirmLink string) error
    SendWelcome(ctx context.Context, toEmail, toName, dashboardURL string) error
}

This keeps the auth package decoupled from the email implementation. In tests, we use a mock that records what was called:

type mockEmailSender struct {
    lastEmail        string
    lastName         string
    lastDashboardURL string
    welcomeCalled    bool
    sendErr          error
}

func (m *mockEmailSender) SendWelcome(_ context.Context, toEmail, toName, dashboardURL string) error {
    m.welcomeCalled = true
    m.lastEmail = toEmail
    m.lastName = toName
    m.lastDashboardURL = dashboardURL
    return m.sendErr
}

The Listmonk template

Listmonk templates are managed in its admin UI, not in code. The template uses Go's text/template syntax with Listmonk's .Tx.Data namespace:

<p>Hi {{ .Tx.Data.name }},</p>

<p>Welcome to SendRec. Your account is live and ready to use.</p>

<p>Everything you record stays on EU infrastructure — no US cloud
in the data path, no third-party processors to vet.</p>

<p>Getting started is fast: click "New Recording" from your dashboard,
choose screen, camera, or both, and hit record. When you stop,
your video gets a shareable link instantly.</p>

<p>Your free tier includes 25 videos per month with AI transcription,
timestamped comments, and viewer analytics on every video.
No credit card needed.</p>

<p><a href="{{ .Tx.Data.dashboardURL }}">Record Your First Video</a></p>

The template ID is passed to the application via an environment variable: LISTMONK_WELCOME_TEMPLATE_ID. This means self-hosters can create their own template with different copy, point the env var at it, and everything works.

A routing mistake

The first version linked the CTA button to ${baseURL}/dashboard. When we tested it, the link went to a 404. Our SPA doesn't have a /dashboard route — the root path / loads the Record page, and authenticated users land there after login.

The fix was simple: link to the base URL instead. But it's a good reminder to actually click the links in your emails before shipping them.

Testing

Three tests for the email client method:

func TestSendWelcome_Success(t *testing.T)            // verifies template ID, email, data
func TestSendWelcome_SkipsWhenTemplateIDZero(t *testing.T) // no HTTP call when unconfigured
func TestSendWelcome_BypassesAllowlist(t *testing.T)   // sent even when allowlist blocks

And the existing TestConfirmEmail_Success was updated to verify the welcome email is sent after confirmation:

if !emailSender.welcomeCalled {
    t.Error("expected welcome email to be sent after confirmation")
}
if emailSender.lastEmail != "alice@example.com" {
    t.Errorf("expected welcome email to alice@example.com, got %q", emailSender.lastEmail)
}

The result

The user experience is now: register, receive confirmation email, click the link, receive welcome email with a direct "Record Your First Video" button. Two emails, in the right order, each arriving when they're useful.

The welcome email is the first step in a planned onboarding sequence. Next up: a "share your first video" nudge on day 2 and a Pro upgrade prompt on day 7. All powered by Listmonk's transactional API, all triggered from application events rather than time-based campaigns.

Try it

SendRec is open source (AGPL-3.0) and self-hostable. Register at app.sendrec.eu to see the welcome email in action, or browse the source code.

How We Added Silence Removal to SendRec

Alex Neamtu — Wed, 25 Feb 2026 12:38:12 +0000

Anyone who has watched a screen recording knows the feeling: the presenter pauses to think, navigates a menu slowly, or just trails off between thoughts. Those dead seconds add up fast. In v1.65.4, SendRec can detect and remove them automatically.

We already had filler word removal — detecting "um", "uh", and similar disfluencies from transcript data, presenting them as a checklist, and cutting them out. Silence removal follows the same pattern, but operates purely on audio energy rather than transcription.

Detection: ffmpeg's silencedetect filter

ffmpeg ships a silencedetect audio filter that scans an audio stream and emits timestamps whenever audio drops below a configurable noise floor for at least a minimum duration.

The command:

ffmpeg -i input.mp4 -vn -af silencedetect=noise=-30dB:d=1.0 -f null -

The -vn flag tells ffmpeg to skip video decoding entirely. Silence detection only needs the audio stream, and skipping video makes the scan significantly faster on large files.

ffmpeg writes silence events to stderr:

[silencedetect @ 0x...] silence_start: 3.504
[silencedetect @ 0x...] silence_end: 5.200 | silence_duration: 1.696

We parse this with a pair of regexes:

startRe := regexp.MustCompile(`silence_start:\s*([\d.]+)`)
endRe   := regexp.MustCompile(`silence_end:\s*([\d.]+)`)

Walk the stderr lines, match each pattern, pair starts with ends. If audio is silent at the very end of a recording, ffmpeg emits a silence_start with no corresponding silence_end — we discard those unpaired starts.

The result is a list of {start, end} pairs returned via a new endpoint:

POST /api/videos/{id}/detect-silence

The request body accepts two optional parameters: noiseDB (default -30) and minDuration (default 1.0 seconds).

The presigned URL optimization

The initial implementation downloaded the full video from S3 to a temp file on disk, then ran ffmpeg against the local path. This worked, but the wait before detection started scaled linearly with file size. A large recording meant waiting for the entire download before ffmpeg processed a single audio frame.

The fix: generate a presigned S3 URL and pass it directly to ffmpeg.

presignedURL, err := h.storage.GenerateDownloadURL(ctx, fileKey, 15*time.Minute)

cmd := exec.Command("ffmpeg",
    "-i", presignedURL,
    "-vn",
    "-af", fmt.Sprintf("silencedetect=noise=%ddB:d=%.2f", noiseDB, minDuration),
    "-f", "null", "-",
)

ffmpeg handles HTTPS inputs natively. It starts streaming and processing audio immediately — no temp file, no download wait. Combined with -vn skipping the video track, detection on a long recording completes in seconds rather than minutes.

Duration clamping

ffmpeg reports timestamps as floats. Our database stores video duration as an integer (seconds). This mismatch caused a subtle bug: a video stored as 120 seconds could have ffmpeg report silence ending at 120.041 seconds, which the segment removal worker would reject with "segment end exceeds video duration."

The fix is a clamping step before returning results:

Drop any segment whose start is at or beyond the stored duration
Cap any segment end at the stored duration
Drop any segment shorter than 0.1 seconds after clamping

This keeps detection results consistent with what the removal worker expects, regardless of float-to-integer rounding.

Frontend

The UI mirrors the existing filler word removal modal. Click "Remove Silence" on a video, and a modal shows each detected pause as a checkbox entry with timestamp range and duration, all selected by default. Confirm, and the segments are handed off to the same removeSegmentsFromVideo worker that handles filler word removal. No new cut logic was needed.

What we learned

The presigned URL approach is worth considering any time you run a command-line tool against a cloud-stored file. Passing a URL directly to ffmpeg eliminates the download-to-disk step, and ffmpeg's streaming behavior means processing starts almost immediately. Combined with -vn for audio-only analysis, the latency improvement on large files is substantial.

The float/integer duration mismatch only showed up with real recordings. ffmpeg is precise; databases round. A clamping step at the boundary prevents confusing errors downstream.

SendRec is open source. The full implementation is on GitHub.

How We Made Our E2E Tests 12x Faster

Alex Neamtu — Tue, 24 Feb 2026 20:54:42 +0000

Our Playwright end-to-end test suite has 15 tests across 5 spec files. They run sequentially because some tests have ordering dependencies — upload creates a video that later tests verify. The suite was taking around 90 seconds per run. Most of that time was spent doing the same thing: logging in through the UI.

We got it down to 7 seconds. Here's how.

The bottleneck

Eight of the fifteen tests need authentication. Each one called loginViaUI() before doing anything:

export async function loginViaUI(page: Page): Promise<void> {
  await page.goto("/login");
  await page.getByLabel("Email").fill(TEST_USER.email);
  await page.getByLabel("Password").fill(TEST_USER.password);
  await page.getByRole("button", { name: "Sign in" }).click();
  await page.waitForURL("/");
}

Navigate to the login page. Wait for it to load. Fill the email. Fill the password. Click the button. Wait for the redirect. That's 2-3 seconds per test, times eight — roughly 20 seconds of typing into login forms.

The remaining time came from Docker health checks with conservative timings and a CI wait loop that polled every 3 seconds.

What we tried first: `storageState`

Playwright has a built-in solution for this: storageState. The idea is to log in once in a global setup, save the browser's cookies and localStorage to a JSON file, and load that file for every test. Tests start authenticated without touching the login page.

We implemented it exactly as the docs describe:

// global-setup.ts
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto(`${baseURL}/login`);
await page.getByLabel("Email").fill(TEST_USER.email);
await page.getByLabel("Password").fill(TEST_USER.password);
await page.getByRole("button", { name: "Sign in" }).click();
await page.waitForURL(`${baseURL}/`);
await page.context().storageState({
  path: join(__dirname, ".auth", "user.json"),
});
await browser.close();

// playwright.config.ts
projects: [{
  name: "chromium",
  use: {
    storageState: "./e2e/.auth/user.json",
  },
}],

It didn't work. Tests landed on the login page as if no authentication existed.

Why `storageState` failed

Our auth system stores the access token in a module-level variable — not in localStorage or sessionStorage:

let accessToken: string | null = null;

The refresh token is an HTTP-only cookie. On page load, a ProtectedRoute component checks for the access token in memory. If it's not there, it calls tryRefreshToken(), which POSTs to /api/auth/refresh with the cookie. If that succeeds, the access token is set in memory and the user is authenticated.

The storageState file captured the refresh token cookie correctly. The problem was refresh token rotation. When a test navigates to a protected page, the browser sends the refresh token cookie. The server validates it, issues a new access token, and rotates the refresh token — the old one is invalidated and a new one is returned.

Each Playwright test gets a fresh browser context initialized from the same storageState file. The first test uses the refresh token, which gets rotated. The second test loads the same (now-invalid) token from the file. The server rejects it. The test lands on the login page.

This is a fundamental incompatibility between storageState and refresh token rotation. The storageState approach assumes tokens remain valid across contexts. Token rotation assumes each token is used exactly once.

What actually worked: API login

Instead of avoiding the login entirely, we made it fast. The page.request API in Playwright lets you make HTTP calls that share cookies with the browser context. A single POST to the login endpoint sets the refresh token cookie — no page navigation, no DOM interaction:

export async function loginViaAPI(page: Page): Promise<void> {
  for (let attempt = 0; attempt < 3; attempt++) {
    const response = await page.request.post("/api/auth/login", {
      data: { email: TEST_USER.email, password: TEST_USER.password },
    });
    if (response.ok()) return;
    if (response.status() === 429) {
      await page.waitForTimeout(2000);
      continue;
    }
    throw new Error(`Login API failed: ${response.status()}`);
  }
  throw new Error("Login API failed: exceeded retries (429)");
}

The retry loop handles rate limiting. Our auth endpoints are rate-limited to 0.5 requests per second with a burst of 5. With 8+ login calls happening across a fast test suite, the last few can hit the limit. A 2-second wait and retry handles it cleanly.

Each test's beforeEach calls loginViaAPI instead of loginViaUI:

test.describe("Upload", () => {
  test.beforeEach(async ({ page }) => {
    await loginViaAPI(page);
  });
  // tests...
});

The auth spec still uses loginViaUI because it's testing the actual login UI flow — form rendering, error messages, redirects. That's intentional; those tests need to exercise the real login page.

Connection pooling

The test helpers used per-call database connections:

export async function query(sql: string, params?: unknown[]): Promise<void> {
  const client = new pg.Client({ connectionString: DATABASE_URL });
  await client.connect();
  try {
    await client.query(sql, params);
  } finally {
    await client.end();
  }
}

Every query opened a new TCP connection, performed the TLS handshake (if applicable), authenticated, executed the query, and closed the connection. For global setup and teardown — which each run a TRUNCATE — that's two full connection lifecycles.

Replacing pg.Client with pg.Pool keeps connections alive across calls:

const pool = new pg.Pool({ connectionString: DATABASE_URL, max: 3 });

export async function query(sql: string, params?: unknown[]): Promise<void> {
  await pool.query(sql, params);
}

export async function closePool(): Promise<void> {
  await pool.end();
}

The pool is closed in globalTeardown after the final table truncation. This saves around 100-200ms per database call — small individually, but it eliminates unnecessary overhead.

Faster health checks

The Docker Compose e2e stack had a conservative health check configuration:

healthcheck:
  test: ["CMD", "wget", "--spider", "-q", "http://localhost:8080/api/health"]
  interval: 5s
  timeout: 5s
  start_period: 15s

The Go binary starts in under a second. A 15-second start period is 14 seconds of waiting. We reduced it to 5 seconds and the check interval from 5 to 2 seconds:

healthcheck:
  interval: 2s
  start_period: 5s

The CI workflow had a similar problem. After Docker Compose reports healthy, a shell loop polled the health endpoint as a safety net:

for i in $(seq 1 60); do
  if curl -sf http://localhost:8080/api/health > /dev/null 2>&1; then
    echo "App is healthy!"
    exit 0
  fi
  sleep 3  # was 3, now 1
done

The loop also dumped garage-init logs and tested S3 connectivity on every successful health check — debugging artifacts from the initial setup that we removed.

Results

Change	Time saved
API login (8 tests)	~20s
Health check timing	~15s
CI wait loop	~20s
Connection pooling	~1s

The suite now runs in about 7 seconds locally, down from 90+. In CI, the total e2e job time drops by roughly a minute including stack startup.

The key insight: the obvious Playwright solution (storageState) didn't work because of how our auth system manages tokens. The actual fix was simpler — skip the browser, call the API directly, handle rate limits. Sometimes the right optimization isn't eliminating the work, it's doing it more efficiently.

Try it

SendRec is open source (AGPL-3.0) and self-hostable. Check the e2e test suite, pull the image from Docker Hub, or browse the source code.

What's Next for SendRec

Alex Neamtu — Tue, 24 Feb 2026 20:22:35 +0000

We shipped 19 releases in February — playlists, engagement heatmaps, system audio, custom player controls, and more. Here's what we built, what we learned, and where SendRec is heading.

SendRec started as a simple idea: an open-source, EU-hosted alternative to Loom. Record your screen, share a link, see who watched. Four weeks into February 2026, we've shipped 19 releases (v1.48.0 through v1.64.0) and the product looks very different from where it started.

Here's a recap of what shipped, and where we're going next.

What shipped in February

The month started with billing (Creem integration for Pro subscriptions) and ended with faster end-to-end tests and a refined deployment pipeline. In between:

Video playlists. Share an ordered set of videos as a single link. Password protection, email gates, auto-advance, watched badges. Playlists get their own embed page with a sidebar.

Custom player controls. We replaced the native <video controls> with a custom UI — seek bar with chapter segments and comment markers, speed controls, picture-in-picture, volume slider, fullscreen. Auto-hide after 3 seconds, touch support for mobile.

Viewer engagement heatmap. The analytics page now shows a 50-segment bar that visualizes where viewers pay attention and where they drop off. Each segment covers 2% of the video timeline. Bright means high engagement, faint means drop-off.

System audio recording. Chrome's systemAudio and suppressLocalAudioPlayback constraints let us capture tab and system audio during screen recording, with an Audio On/Off toggle in the recorder UI.

MP4 recording. Chrome 130+ and Safari record MP4 natively. No more server-side transcoding for most recordings. Firefox falls back to WebM with a VP8/VP9 chain.

iOS compatibility. Custom player controls break on iOS, so we detect it and fall back to native controls. ffmpeg flags were tuned for iOS playback compatibility (-profile:v high -level:v 5.1 -r 60). Videos that aren't iOS-compatible get re-encoded automatically.

Playlist embeds. /embed/playlist/{shareToken} renders a sidebar with video list and auto-advancing player — designed for embedding in documentation, wikis, or internal tools.

Docker Hub publishing. Every tagged release now pushes to Docker Hub (alexneamtu/sendrec) and GHCR automatically. Plus an Unraid community app template for one-click installation.

Structured logging. Migrated ~130 log calls from log.Printf to Go's log/slog with structured key-value fields. Custom HTTP middleware that skips health check noise.

Playwright e2e tests. 15 end-to-end tests covering auth, upload, library, settings, and watch pages. Run against a full Docker Compose stack with ephemeral volumes. Then we made them 12x faster — from 90 seconds to 7 seconds — by replacing UI-based login with API calls, adding connection pooling, and tuning health check timings.

OpenAPI documentation. All 95 API endpoints documented with Scalar UI at /api/docs.

And a handful of smaller things: configurable AI timeout for self-hosters running Ollama on slower hardware, webhook idempotency for billing events, comparison pages on the landing site, data-driven free tier limits.

What we learned

Browser APIs are surprisingly accommodating. The getDisplayMedia API silently ignores unknown constraints instead of throwing errors. This meant we could add Chrome-specific system audio constraints and ship them to all browsers without feature detection. Firefox and Safari just skip what they don't understand. More APIs should work this way.

50 segments is enough. When planning the engagement heatmap, we considered 100 or even per-second tracking. 50 segments (2% each) gives useful resolution — you can clearly see intro drop-off, mid-video engagement dips, and whether viewers reach your call-to-action. More segments would mean more data with no real improvement in actionable insight.

Server-side compositing was the right call. Canvas-based webcam overlay compositing breaks when the tab goes to the background (browser throttling kills requestAnimationFrame). Recording two separate streams and compositing with ffmpeg on the server is more work upfront but works reliably regardless of what the user does with their browser.

iOS is its own platform. Every video feature needs an iOS code path. Custom player controls, specific ffmpeg encoding flags, WebM-to-MP4 normalization, Safari-specific warnings. The investment is worth it — mobile viewing is a significant share of watch page traffic.

The obvious Playwright solution didn't work. Playwright's storageState is the standard way to share authentication across tests. It didn't work for us because our app stores access tokens in memory (not localStorage) and uses refresh token rotation. Each test context loaded the same saved token, the first test rotated it, and every subsequent test got an invalid token. The fix was simpler: skip the browser, POST to the login API directly.

Where we're heading

With the core product solid — recording, sharing, analytics, transcription, AI summaries, billing — the focus shifts.

Distribution. The product does what it needs to do. Now more people need to find it. LinkedIn (founder-led content about EU data sovereignty and building in public), Product Hunt (saving for a coordinated launch), and getting listed on european-alternatives.eu and awesome-selfhosted.

Team features. SendRec is currently single-user. The next major product milestone is team workspaces — shared video libraries, roles and permissions, team-level branding. This is what turns SendRec from a personal tool into something a company deploys.

Self-hosting improvements. Every release should make self-hosting easier. The Unraid template was a start. Better documentation, one-command deploys, and reducing the number of environment variables needed to get started.

The numbers

As of today: 465 unit tests, 15 e2e tests, 95 documented API endpoints, 45 blog posts, 64 releases. The codebase is Go + React + TypeScript + PostgreSQL + S3, licensed AGPL-3.0, and runs on a single Hetzner CX33 server in Helsinki.

Try it

SendRec is open source and self-hostable. Try it at app.sendrec.eu, pull the image from Docker Hub, or check the source code on GitHub.

How We Added System Audio to Screen Recording

Alex Neamtu — Tue, 24 Feb 2026 20:20:47 +0000

We already had screen recording with webcam overlay, drawing tools, and pause/resume. But when someone recorded a product walkthrough with background music or a tutorial with UI sounds, the recording was silent. The browser captured the screen but not the audio coming from it.

The fix was surprisingly small — two constraints on one API call. But understanding why those constraints exist and how they interact with different browsers took more work than writing the code.

The problem

The getDisplayMedia() API lets web apps capture a user's screen. You can request audio alongside video:

const stream = await navigator.mediaDevices.getDisplayMedia({
  video: true,
  audio: true,
});

This works — sort of. The audio: true flag tells the browser you'd like audio, but the browser decides what that means. In Chrome, the share picker shows an "Also share tab audio" checkbox. If the user shares a tab, they get tab audio. If they share an entire screen or window, they might get nothing.

The real issue is that Chrome doesn't offer system-level audio capture by default. Without an explicit signal, it limits you to tab audio at best.

The constraints

Chrome 105+ supports two constraints that change the behavior:

const stream = await navigator.mediaDevices.getDisplayMedia({
  video: true,
  audio: true,
  systemAudio: "include",
  suppressLocalAudioPlayback: true,
});

systemAudio: "include" tells Chrome to offer system audio capture in the share picker, not just tab audio. When a user shares their entire screen, Chrome can now capture audio from any application — not just browser tabs.

suppressLocalAudioPlayback: true solves the echo problem. Without it, if you're recording a tab that's playing audio, the user hears the audio locally and it gets recorded. During playback, you'd hear the audio twice — once from the recording and once from the echo picked up by the microphone. Suppressing local playback mutes the captured source's audio output so it only exists in the recording.

Implementation

The full change was three parts: a state variable, modified constraints, and a toggle button.

The state defaults to true because most people recording their screen want audio:

const [systemAudioEnabled, setSystemAudioEnabled] = useState(true);

The getDisplayMedia call builds its options based on that state:

const displayMediaOptions: DisplayMediaStreamOptions
  & Record<string, unknown> = {
  video: true,
  audio: systemAudioEnabled,
};
if (systemAudioEnabled) {
  displayMediaOptions.systemAudio = "include";
  displayMediaOptions.suppressLocalAudioPlayback = true;
}
const screenStream = await navigator.mediaDevices
  .getDisplayMedia(displayMediaOptions);

The & Record<string, unknown> type intersection is a pragmatic choice. TypeScript's built-in DisplayMediaStreamOptions doesn't include systemAudio or suppressLocalAudioPlayback — they're Chrome-specific extensions that haven't landed in the standard DOM types yet. Instead of creating a custom type declaration file for two properties, we use a type intersection that allows setting arbitrary keys.

When audio is toggled off, we pass audio: false and skip the extra constraints entirely. The browser won't request any audio, and the recording is video-only.

Browser compatibility

Here's what happens on each browser:

Browser	`systemAudio`	`suppressLocalAudioPlayback`	Result
Chrome 105+	Supported	Supported	System + tab audio captured, local playback suppressed
Edge 105+	Supported	Supported	Same as Chrome (Chromium-based)
Firefox	Ignored	Ignored	Tab audio may work on some configs, no system audio
Safari	Ignored	Ignored	No audio capture from `getDisplayMedia`

The key insight: browsers silently ignore unknown constraints in getDisplayMedia(). They don't throw errors or reject the promise. Firefox and Safari simply skip systemAudio and suppressLocalAudioPlayback and proceed as if they weren't there. This means we can safely pass these constraints on all browsers without feature detection.

No try/catch, no if (typeof systemAudio !== 'undefined'), no user-agent sniffing. The API was designed this way — unknown constraints are a no-op.

No backend changes

Our server-side video pipeline already handled audio correctly. The ffmpeg command for compositing screen + webcam recordings uses:

ffmpeg -i screen.mp4 -i webcam.webm \
  -map "0:a?" \
  ...

The ? suffix on 0:a? means "include the audio track from input 0 if it exists, otherwise skip it." When audio is present, it gets included. When it's not, ffmpeg doesn't fail — it just produces a video-only output. This pattern was already in place from the webcam compositing work, so system audio flows through the pipeline with zero changes.

The transcoding step similarly handles audio transparently. MP4 outputs get AAC audio. WebM outputs copy the original codec. If there's no audio track, both paths produce video-only files.

The toggle

We added an "Audio On/Off" button to the recorder's idle UI, sitting between the Camera toggle and the Start Recording button:

[Camera Off] [Audio On] [Start Recording]

It follows the exact same styling pattern as the Camera toggle — accent background when on, transparent with border when off. The toggle only appears in the idle state and disappears during recording, countdown, and paused states, which is the natural behavior since the idle UI section is already conditionally rendered.

When audio is on, the button reads "Audio On" with the accent background. When off, "Audio Off" with a transparent background and border. The aria-label switches between "Disable system audio" and "Enable system audio" for accessibility.

What about microphone audio?

System audio from getDisplayMedia and microphone audio from getUserMedia are separate streams. We deliberately don't mix them. If someone wants narration over their screen recording, they use the webcam overlay — it records separately with its own audio track and gets composited server-side.

Mixing two audio streams in the browser would require a Web Audio API AudioContext with a MediaStreamAudioDestinationNode to combine sources. That's significant complexity for a marginal benefit, especially when server-side compositing already handles multiple tracks cleanly.

macOS caveat

On macOS, Chrome can capture tab audio but not system-wide audio from other applications without additional OS-level permissions. The systemAudio: "include" constraint is a hint to the browser — it tells the share picker to offer audio options. If the OS doesn't support system audio capture, the browser simply doesn't offer it. The recording still succeeds; it just won't have audio from non-browser sources.

On Windows and Linux, system audio capture generally works without additional setup.

Try it

SendRec is open source (AGPL-3.0) and self-hostable. Record a screen with system audio at app.sendrec.eu. Pull the image from Docker Hub, check the Self-Hosting Guide, or browse the source code.

How We Built a Viewer Engagement Heatmap

Alex Neamtu — Tue, 24 Feb 2026 19:59:06 +0000

We already had view counts and a completion funnel showing how many viewers reached 25%, 50%, 75%, and 100%. That tells you whether people finish your video, but not where they lose interest. A five-minute product walkthrough might have great completion rates while everyone skips the two-minute intro.

The engagement heatmap fixes that. It splits the video timeline into 50 segments and shows how many viewers watched each one. Bright segments mean high engagement. Faint segments mean drop-off.

The data model

Each video gets up to 50 rows in a new segment_engagement table:

CREATE TABLE segment_engagement (
    video_id UUID NOT NULL REFERENCES videos(id),
    segment_index SMALLINT NOT NULL CHECK (segment_index >= 0 AND segment_index < 50),
    watch_count INTEGER NOT NULL DEFAULT 0,
    PRIMARY KEY (video_id, segment_index)
);

The composite primary key means no separate ID column and no index to maintain — the primary key is the lookup path. Each segment covers roughly 2% of the video duration.

We considered adding a day column for time-series breakdowns but decided against it. The heatmap answers "which parts of my video work?" — that question doesn't change much day to day. Keeping it aggregate means at most 50 rows per video, and queries stay simple.

Client-side tracking

The tracking runs as a self-contained IIFE on both watch and embed pages. The core logic hooks into the player's timeupdate event:

player.addEventListener('timeupdate', function() {
    if (!player.duration || player.duration <= 0) return;
    var seg = Math.min(
        Math.floor((player.currentTime / player.duration) * SEGMENTS),
        SEGMENTS - 1
    );
    if (reported[seg]) return;
    if (lastSeg >= 0 && Math.abs(seg - lastSeg) > 1) {
        lastSeg = seg;
        return;
    }
    reported[seg] = true;
    pending.push(seg);
    lastSeg = seg;
});

Three things happen here:

Client-side dedup. The reported object tracks which segments this viewer has already counted. Each segment fires at most once per page load. If someone rewinds and watches segment 12 again, it doesn't inflate the count.

Seek detection. If the current segment jumps by more than 1 from the last segment, the viewer seeked. We skip that segment — it wasn't watched through natural playback, so counting it would distort the heatmap. The next naturally-played segment will be counted normally.

Batch collection. Segments accumulate in the pending array instead of firing a request per segment. A flush function sends the batch every 5 seconds:

function flush() {
    if (pending.length === 0) return;
    var data = JSON.stringify({ segments: pending });
    pending = [];
    if (navigator.sendBeacon) {
        navigator.sendBeacon(
            '/api/watch/' + shareToken + '/segments',
            new Blob([data], { type: 'application/json' })
        );
    } else {
        fetch('/api/watch/' + shareToken + '/segments', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: data
        }).catch(function() {});
    }
}

The flush runs on an interval, but also fires on pause, ended, visibilitychange, and beforeunload. The sendBeacon API is important here — regular fetch requests get canceled when the page unloads, but sendBeacon is designed for exactly this use case. It queues the request for delivery even after the page closes.

Server-side upsert

The endpoint validates the segments, looks up the video, then fires a goroutine to upsert the counts:

go func() {
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()
    for _, seg := range req.Segments {
        if seg < 0 || seg >= 50 {
            continue
        }
        h.db.Exec(ctx,
            `INSERT INTO segment_engagement (video_id, segment_index, watch_count)
             VALUES ($1, $2, 1)
             ON CONFLICT (video_id, segment_index)
             DO UPDATE SET watch_count = segment_engagement.watch_count + 1`,
            videoID, seg,
        )
    }
}()

The handler returns 204 No Content immediately. The upsert runs in the background so tracking never slows down video playback. The ON CONFLICT DO UPDATE pattern means the first view creates the row, and every subsequent view increments the counter — no read-before-write, no race conditions.

Normalization in the analytics API

Raw watch counts aren't useful for visualization. Segment 0 might have 200 views while segment 49 has 15. The analytics endpoint normalizes counts to a 0.0–1.0 intensity scale:

var maxCount int64
for _, sd := range segments {
    if sd.WatchCount > maxCount {
        maxCount = sd.WatchCount
    }
}
for i := range segments {
    if maxCount > 0 {
        segments[i].Intensity = float64(segments[i].WatchCount) / float64(maxCount)
    }
}

The highest segment always gets intensity 1.0. Everything else is relative. This means the heatmap always shows useful contrast regardless of whether the video has 5 views or 5,000.

The visualization

The frontend renders 50 equal-width div elements, each using the brand accent color with opacity mapped to intensity:

{Array.from({ length: 50 }, (_, i) => {
    const seg = data.heatmap.find((s) => s.segment === i);
    const intensity = seg ? seg.intensity : 0;
    return (
        <div
            key={i}
            title={`${i * 2}%-${(i + 1) * 2}%: ${seg ? seg.watchCount : 0} views`}
            style={{
                flex: 1,
                background: "var(--color-accent)",
                opacity: Math.max(intensity, 0.08),
            }}
        />
    );
})}

No chart library, no canvas, no SVG. Just 50 divs in a flex container with varying opacity. The minimum opacity of 0.08 keeps empty segments visible so you can see the full timeline shape. Hovering any segment shows the exact percentage range and view count.

What it tells you

The heatmap answers questions that view counts and completion rates can't:

Where do viewers drop off? A steep drop after the intro means your hook isn't working.
What gets rewatched? Segments with counts higher than the start segment mean people sought back to rewatch them.
Does the ending matter? If the last few segments are faint, viewers stop before your call to action.

Combined with the existing completion funnel and per-viewer tracking, you can now see both the what (which parts get watched) and the who (which viewers watched how much).

Try it

SendRec is open source (AGPL-3.0) and self-hostable. Share a video, check the analytics page, and see where your viewers pay attention. Pull the image from Docker Hub, check the Self-Hosting Guide, or try it at app.sendrec.eu.

SendRec Is Now on Docker Hub and Unraid

Alex Neamtu — Tue, 24 Feb 2026 18:33:42 +0000

A user opened an issue asking for an Unraid community app template. They wanted to install SendRec on their Unraid server, but without a template in Community Applications, setup meant manually configuring a Docker container with a dozen environment variables. We fixed that — and while we were at it, we published the Docker image to Docker Hub.

Docker Hub

Until now, SendRec's Docker image was only built on the server during deployment. There was no public image to pull. If you wanted to self-host, you had to clone the repo and build it yourself.

We added a GitHub Actions workflow that builds and pushes the image on every version tag:

- name: Build and push
  uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    build-args: VERSION=${{ github.ref_name }}
    tags: |
      alexneamtu/sendrec:latest
      alexneamtu/sendrec:${{ steps.version.outputs.version }}
      ghcr.io/sendrec/sendrec:latest
      ghcr.io/sendrec/sendrec:${{ steps.version.outputs.version }}
    cache-from: type=gha
    cache-to: type=gha,mode=max

Every release now publishes to both Docker Hub and GitHub Container Registry. The build uses Docker Buildx with GitHub Actions cache, so subsequent builds only rebuild changed layers.

Self-hosting is now one command:

docker pull alexneamtu/sendrec:latest

You still need PostgreSQL and S3-compatible storage — the Self-Hosting Guide covers the full setup with Docker Compose.

The Unraid template

Unraid Community Applications uses XML templates to describe how a container should be configured. Each <Config> element becomes a form field in the Unraid UI — ports, volumes, environment variables — so users can fill in values and click Apply without touching the command line.

The template for SendRec lives at sendrec/unraid-templates. Here's what the configuration looks like:

Required settings

These appear in the basic install view:

<Config Name="Database URL" Target="DATABASE_URL"
        Default="postgres://sendrec:secret@192.168.1.X:5432/sendrec?sslmode=disable"
        Type="Variable" Display="always" Required="true" Mask="false"/>

<Config Name="JWT Secret" Target="JWT_SECRET"
        Type="Variable" Display="always" Required="true" Mask="true"/>

<Config Name="Base URL" Target="BASE_URL"
        Default="http://192.168.1.X:8080"
        Type="Variable" Display="always" Required="true" Mask="false"/>

Sensitive fields like JWT_SECRET and S3_SECRET_KEY use Mask="true" to hide values in the UI. The Required="true" attribute prevents installation if the field is empty.

S3 storage

SendRec stores videos in S3-compatible object storage. The template includes fields for endpoint, bucket, credentials, and region:

<Config Name="S3 Endpoint" Target="S3_ENDPOINT"
        Default="http://192.168.1.X:3900"
        Type="Variable" Display="always" Required="true" Mask="false"/>

<Config Name="S3 Bucket" Target="S3_BUCKET"
        Default="sendrec"
        Type="Variable" Display="always" Required="true" Mask="false"/>

For S3-compatible providers like Garage, MinIO, or Backblaze B2, the checksum settings are pre-configured in the advanced view:

<Config Name="S3 Checksum Calculation" Target="AWS_REQUEST_CHECKSUM_CALCULATION"
        Default="when_required"
        Type="Variable" Display="advanced" Required="false" Mask="false"/>

Usage limits

Self-hosters typically want no limits. The template defaults all limits to 0 (unlimited):

<Config Name="Max Videos per Month" Target="MAX_VIDEOS_PER_MONTH"
        Default="0"
        Type="Variable" Display="always" Required="false" Mask="false"/>

<Config Name="Max Video Duration (seconds)" Target="MAX_VIDEO_DURATION_SECONDS"
        Default="0"
        Type="Variable" Display="always" Required="false" Mask="false"/>

Optional features

Transcription and AI summaries are configurable through the template. The whisper model gets mounted as a read-only volume:

<Config Name="Whisper Model" Target="/models" Default="" Mode="ro"
        Description="Path to directory containing the whisper model file (ggml-small.bin, ~466 MB)."
        Type="Path" Display="always" Required="false" Mask="false"/>

<Config Name="AI Enabled" Target="AI_ENABLED"
        Default="true|false"
        Type="Variable" Display="always" Required="false" Mask="false"/>

The Default="true|false" syntax creates a dropdown selector in the Unraid UI instead of a free-text field.

Display modes

Unraid templates support two display modes: always for settings most users need, and advanced for settings they typically don't. We put the core settings (database, S3, limits) in the basic view and less common options (checksum settings, AI model name, frame ancestors) in the advanced view. This keeps the install dialog manageable while still exposing every configuration option.

Prerequisites warning

The <Requires> element shows a warning in the Unraid install dialog:

<Requires>PostgreSQL 16+ and S3-compatible storage (Garage, MinIO, AWS S3, etc.)</Requires>

This tells users they need to install PostgreSQL and an S3 provider before installing SendRec — both are available as separate containers in the Unraid CA store.

What's next

The template repo is ready. The remaining steps to get into Unraid Community Applications are:

Create a support thread on the Unraid forums
Submit via the Community Applications form
Wait for moderation review (typically 48 hours)

In the meantime, Unraid users can install SendRec manually by adding the template repository URL in the Docker tab, or by pulling the image directly from Docker Hub.

Try it

SendRec is open source (AGPL-3.0) and self-hostable. Pull the image from Docker Hub, check the Self-Hosting Guide, or try it at app.sendrec.eu.

Forem: Alex Neamtu

GDPR-Compliant Screen Recording for Teams: What You Actually Need

What GDPR actually requires from your video tools

1. Data residency

2. Sub-processors

3. Data Processing Agreement (DPA)

4. Retention and deletion

5. Access controls

What most screen recording tools get wrong

US-hosted by default

Invisible sub-processors

No retention controls

Tracking on watch pages

A practical checklist

Self-hosting: the compliance shortcut

The managed middle ground

What about consent for recording?

Summary

Open Source Loom Alternatives in 2026: A Practical Comparison

Why open source matters for screen recording

The contenders

Loom (proprietary baseline)

Cap

Zight (formerly CloudApp)

SendRec

Feature comparison

Pricing comparison

Which one should you pick?

Try them

How We Built Data Retention for SendRec

Why data retention matters

The data model

The two-pass worker

Pass 1: Warn

Pass 2: Delete

The pin toggle

The warning email

What we learned

Try it

How We Added Jira and GitHub Integrations to SendRec

The IssueCreator interface

GitHub: Bearer token and markdown

Jira: Basic auth and Atlassian Document Format

Encrypting API tokens at rest

The settings UI

Creating issues from videos

What we learned

Try it

SendRec Now Supports Team Workspaces

What you get

Free tier limits

For self-hosters

How we built it

API

How We Built a Welcome Email That Actually Gets Sent

The confirmation flow

The implementation

The email client

Bypassing the allowlist

Triggering after confirmation

The interface

The Listmonk template

A routing mistake

Testing

The result

Try it

How We Added Silence Removal to SendRec

Detection: ffmpeg's silencedetect filter

The presigned URL optimization

Duration clamping

Frontend

What we learned

How We Made Our E2E Tests 12x Faster

The bottleneck

What we tried first: storageState

Why storageState failed

What actually worked: API login

Connection pooling

Faster health checks

Results

What we tried first: `storageState`

Why `storageState` failed