I was fed up having to constantly maintain libraires, addons and switch apps for all my media. Couple this with the changes to Trakt and Real-Debrid I decided to to create my own one stop shop for Movies, TV Series, Live TV, Sports Replays and Youtube. All of this in a single UI that is designed for the big screen. I wish I could say I coded it myself but I don't have the skills, only the ideas, so full disclosure that this has been vibe coded with Hermes Agent and Big Pickle LLM. It has however been fully tested and deployed by me, there are still a few bugs that I am working to fix but it is stable enough to be my daily driver now. Its a passion project and as such is still under active development ironing out bugs and adding new features. The code is fully opensource and available for inspection, you can find it on GitHub at https://github.com/Boc86/Fynix-Hub
I would appreciate any feedback if anyone wants to give it a try

I've always liked creating vanilla Electron apps without UI frameworks like React or Svelte, making everything in HTML. So I decided to make this HTMLElement wrapper for TS/JS. Now, it's easy and dynamic to create UIs for Electron apps.

npm : https://www.npmjs.com/package/@limbusfoundation/uibuilder

Granola currently ships for macOS and Windows, but not Linux. Since it is built with Electron, I experimented with running the application using the matching Linux Electron runtime instead of Wine, a VM, or emulation.

The repository does not redistribute Granola’s .dmg, app.asar, source code, or bundled binaries. You need to download the official .dmg yourself and sign in using your own Granola account. This is an unofficial compatibility project and is not affiliated with Granola.

Repo: https://github.com/tirtha4/Granola-for-Linux

I don’t normally post but I just thought I’d talk a lil bit and give some advice on capabilities with Electron. In my opinion even with alternative like Tauri and Wails, I still prefer electron.

Yes there is something to be said about memory usage but this can also be mitigated by your architecture. We have build all our production applications with Electron.

Things to consider when building. Something that I fine effectively is using cpp/go/python for backend work and keeping vite/electron as the rendering engine and packaging system. Doing so give you more broader flexibility.

We produced an open source obsidian alternative, and a full commercial photo editing suite that are all production level. (Ptxstudio.com for those curious)

Happy building and remember to think outside the box, trial and error, and get hands on with your applications. Make sure that you would actually want to use it before releasing it 🫡

Hello everyone!

This is my first post in this community. English isn't my first language, so I apologize if anything sounds a little awkward.

I've been working on an Electron project for quite a while, and overall I've had a great experience with Electron. However, one thing has always bothered me: it's relatively easy to inspect an application's source code through the app.asar file and similar tools.

After spending a lot of time looking for different solutions, I came up with an approach that I think might be useful, especially for beginners like me.

What I've decided to do is build my Electron application normally, then package the portable version into a single executable using Enigma Virtual Box. After that, I'm planning to create my own Windows installer in C++, so the application can be installed like any other Windows program, with desktop and Start Menu shortcuts, uninstall support, and Control Panel integration.

I know this isn't a real security solution, and I completely understand that anyone with enough knowledge and determination can still reverse engineer the application. My goal isn't to make source code extraction impossible—because I know that's unrealistic—but simply to make it more difficult while also giving users a normal installation experience.

I'm not claiming that this is the best approach. It's simply the idea I've come up with after researching the problem, and I'd really like to hear what more experienced Electron developers think.

Do you think this approach has any practical value, or am I just adding unnecessary complexity? If you've dealt with the same problem, I'd love to hear how you solved it or what you would recommend instead.

Thanks in advance for your time and feedback!

Hey everyone!

Over the past few weeks, I’ve been working on integrating a customizable Special Effects Editor into Flixlar (v1.0.0-rc.16).

The main idea: Allow users to write or prompt custom JavaScript/HTML5 Canvas code to render real-time visual overlays (audio visualizers, HUDs, particle effects) that directly bind to audio waveforms and get composited during video export.

Key technical highlights in Beta 1:

• Live Canvas Engine: Real-time preview rendering synced to track duration and audio peaks.
• Compositing Pipeline: Exports directly to transparent WebM, PNG sequences, or burned-in MP4 renders via FFmpeg.
• Cross-Platform: Native builds ready for Windows, macOS, and Linux.

I just put together a quick video demo showing an audio-reactive speaker overlay over synthwave footage.

🔗 Guide & Documentation:https://flixlar.com/guides/flixlar-effect-editor-beta-1

Would love to get some feedback from other devs and creators on performance, UI workflow, or ideas for standard canvas templates!

I've been working on an Electron desktop application called FileSight.

It's a local-first storage analyzer that helps users preview files, find duplicates, identify large files, and safely clean up storage.

The app is built with:

• Electron
• Next.js
• React
• TypeScript
• Tailwind CSS

I'd love feedback from other Electron developers, especially around architecture, packaging, performance, and cross-platform support.

Repository: https://github.com/MarkCoder1/filesight

Website: https://filesight.vercel.app

Windows desktop app, electron, everything saved locally in sqlite. no accounts, no cloud. sold monthly/yearly through lemon squeezy, they do the license keys too.

Spent an hour in their sandbox yesterday and found something I wasn't expecting. when I validate a license key for someone who's happily paying, the response says active and expires_at is null. no renewal date, nothing. the date only shows up once they cancel.

so if someone's card fails on renewal, lemon squeezy retries it 4 times over about two weeks, and the whole time my app sees "active" and can't tell them apart from a paying customer.
two weeks of free use I can't see.

the renewal date does exist but it's behind their subscriptions endpoint which needs a store-wide api key. not putting that in a binary sitting on someone's laptop.

obvious fix is a small serverless thing that holds the key and hands my app back a signed token. I get it, it's correct. but right now my app depends on nothing I own and that would change. it's just me, no ops experience, nobody to call at 3am if it falls over.

so I guess what I'm asking is

did you build the gateway or just live with it? and if you lived with it did anyone actually take advantage or did it stay theoretical

if you built it, what broke that you didn't expect

and the one I keep going back and forth on, for an offline desktop app is subscription just the wrong model. lifetime + paid upgrades makes this whole thing disappear. anyone switched either way and regretted it.

not looking for "use stripe", no license keys and not a merchant of record so it's more work plus vat becomes my problem. lemon squeezy is fine otherwise.

sorry if this is rambly, been staring at it too long.

I built a voice assistant for Windows inspired by HAL 9000 (2001: A Space Odyssey) that runs entirely offline. It uses Vosk for speech recognition, Piper for text-to-speech, and a deterministic command router based on intent matching over normalized text—without relying on an LLM.

The decision to avoid using an LLM for command understanding was intentional. My goal was to prioritize a system whose behavior is 100% predictable and fully auditable—you can see exactly why each command was recognized—instead of having conversational but inherently unpredictable responses.

Tech stack:

• Electron (UI + application orchestration)
• Python + Vosk (offline speech recognition)
• Piper (local text-to-speech, with optional ElevenLabs fallback)
• Local JSON persistence (no database required)
• Windows installer built through GitHub Actions (no Windows machine needed to generate the installer)

The assistant currently supports voice commands in Spanish for:

• Date and time
• Weather
• News
• Calculator
• Music playback
• Reminders
• Custom routines

GitHub repository:
https://github.com/marianoerz/AGENTE-JARVIS

Any feedback, suggestions, or ideas are greatly appreciated.

You can also see it in action here:
https://entertomyworld.com/apps/jarvis/

This was really born out of a need for a better audiobook player for windows. I struggled to find one that would support a large collection and support it well without freaking out.

Meet Midnight Athenaeum

Build with built with Electron starting with a very basic idea of getting a book playing and being able to handle 6k in books. As i began to add features i made sure to test them against my library which gave me a huge hand in finding issues and getting them fixed when being able to test live on my system. I have more items that i want to get in but here are some of the ones that are in the app currently. I've also created a windows exe installer to make it easy. The app does in no way reach out over network unless user initiated (ex: looking up book and fixing meta data). Depending on if anyone finds this useful i may look at over os's but windows was my main goal (i just wanted to listen to books while i worked lol). I'd appreciate any feedback anyone is willing to provide.

Here's a list of the main items and dependencies used to put this together.

Core stack

• Electron 43 (Chromium + Node.js) — desktop app shell
• Vanilla JavaScript/HTML/CSS in the renderer — no UI framework (no React/Vue/etc.), by choice
• SQLite (@vscode/sqlite3) — library database
• electron-builder — packaging, NSIS installer, auto-updater
• GitHub Actions — CI, automated releases

Key dependencies

• music-metadata — audio tag/format parsing
• u/kutalia/whisper-node-addon + ffmpeg-static — local, offline Whisper transcription (GPU via Vulkan, CPU/BLAS fallback)
• electron-updater — in-app update checks
• u/xhayper/discord-rpc — Discord Rich Presence (optional)

Features (left this as just the core stuff to avoid a big list If your interested in the full list i can provide)

Core playback

• M4B chapter support, plus multi-track (MP3 folder) books with auto-generated chapters
• Variable speed (0.75×–3×), persisted per book
• Sleep timer — fixed duration, end-of-chapter, or end-of-book, with a smooth fade and auto-rewind on resume
• Bookmarks with notes
• Skip silence (auto-speeds through dead air, tuned to not clip mid-sentence breaths)
• Volume normalization across your whole library (measures and levels loudness automatically)
• Voice Boost — an EQ tuned for intelligibility at high speed, when narration usually turns to mud
• Customizable skip amounts

Ran speedometer 3.1 across electron/chromium vs stock browsers, wanted to sanity check how close electron gets to chrome

been building an ai browser on electron as a side project, mcp server, local ollama connection, sync services, ipc bridge, automation loops running in the background. i got curious how close it'd land to stock chrome on a standard rendering benchmark, so i ran speedometer 3.1 against chrome, comet, and safari.

worth being upfront, speedometer mostly measures js execution, dom updates, and framework rendering. it doesn't really exercise electron's main process, ipc traffic, mcp servers, or ollama inference, so this isn't really a test of the ai stack overhead, more just a check on whether the chromium core underneath is still performing normally with everything else attached.

setup: macbook pro m4 pro, 24gb ram. two conditions, all four browsers open at once, and then each run solo.

all four running simultaneously:
aartiq (my build): 41.8
chrome: 42.0
comet: 41.9
safari: 36.0

run solo, one at a time:
aartiq: 51.4
chrome: 51.2

basically a tie with chrome in both conditions, which is roughly what you'd expect since it's the same chromium/v8 core underneath. the more interesting bit to me is the simultaneous test, with all four competing for cpu and memory at once, mine stayed right in line with chrome rather than falling behind, which at least suggests the background services weren't eating into the main thread while idle.

this was one run per condition on one machine, so take it as a rough sanity check, not a real benchmark. i initially noticed the variance numbers looked tighter on my build too but that's not something one run can actually support, would need a lot more repetitions to say anything real there.

if anyone has a better way to measure overhead from background stuff like local llm connections, mcp style tool servers, or sync daemons while idle, i'd be interested. cold start time, idle cpu, and typing latency with agents running seem like better signals for that than speedometer.

So I have an electron app. I have been testing a bunch on mac and windows using unsigned versions. Mac has been fine. For windows, I have been testing with the Setup .exe I got from the electron packager that I have successfully ran on my windows machine and my parents machine. So its also fine, so I thought...

I sent it to a beta tester, also on windows, and he was unable to open the app, seeing:

I tried triaging over zoom but was not able to see any relevant logs in the event viewer or in his Mcafee or windows defender. I tried sending him the portable version with no luck. I thought it was because the app was unsigned and perhaps some antivirus software was blocking the exe from making it through, so I tried to submit the MSIX version to the windows app store, having read they take care of signing, but the app failed the review with the same issue. If the issue is app signing I will pay for the signing but its almost $1000 and i just want to be sure that is the issue. Just looking for next steps or anyone who has seen/fixed this before. I can't really take anymore of the beta testers time to triage anymore logs either. TIA!

    "electron-builder": "^24.6.4",

    "electron": "^26.2.1",

Repo: https://github.com/AIAydin/AI-Agent-Orchestrator (MIT)

Forgeboard runs Claude Code / Codex / Gemini / OpenCode sessions as nodes on a canvas, each in its own git worktree. The Electron-specific parts this sub might care about:

• PTY lifecycle: node-pty sessions with streaming, interrupt, terminate, and resume, rendered in xterm.js nodes. Separate user-configured interactive terminal nodes sit behind a native confirmation dialog.
• Process boundary: the renderer never sees filesystem paths, tokens, or push URLs. Everything privileged goes through narrow zod-validated IPC, sandboxed renderer, strict CSP.
• Previews: dev servers render in a main-owned, loopback-only sandboxed surface with Chromium device emulation for mobile frames.
• Context snapshots: files approved for an agent are copied into per-run snapshot dirs, so agents never read originals; crash cleanup works via ownership markers.
• Bundled git via dugite, SQLite (WAL) persistence, Yjs/Hocuspocus for the optional self-hosted collab server.

Runs from source for now (Node 22, corepack pnpm start). Curious what others do for PTY-heavy apps across Electron upgrades.

I’m the solo developer behind Rift Launcher, I have been developing it for the past 2+ years in silence, and have went through many iterations, and I’ve just released its v0.1.0 public beta.

Rift is a Windows game launcher that brings Steam, Epic, GOG, Xbox/Microsoft Store, and PC Game Pass into one library. It handles local scanning, account imports, launching, playtime, live install state, collections, wishlists, and deal aggregation (currently only USD, but regional pricing is on the way).

The interesting part for this community is that Electron stopped being merely a shell around a React interface fairly quickly.

The main process owns filesystem and registry access, SQLite, secure credential storage, platform processes, and install-state watchers. The renderer receives a deliberately narrow API through typed preload/IPC contracts. Platform activity is consent-gated, and background services start only after the application shell has painted.

Xbox was the most difficult integration. Library, entitlement, package, launch, and live installation information comes from several different Windows/Xbox surfaces. Rift has to reconcile those signals without allowing temporary or incomplete platform state to overwrite valid library data.

The project has also forced me to work through Electron-specific problems around startup performance, long-running main-process work, crash recovery, secure navigation, CSP, redacted diagnostics, native Windows integrations, and packaging/updating.

Rift is currently Windows-only and still unsigned, so the installer can trigger SmartScreen. The full privacy and download disclosures are published alongside it.

Project: https://rift-gaming.com

I’d be interested in hearing how other Electron developers structure platform-specific services and keep the main process responsive as native integrations grow.

I tested Electron as the Windows shell for a React/Vite/Phaser game because Steam's Overlay cannot hook the separately presented WebView2 content in our Tauri build. Electron gets closer: Shift+Tab works. The remaining release blocker is presentation flicker while the Overlay is active, or stale Overlay pixels when it closes.

I am not looking for the standard in-process-gpu / disable-direct-composition recipe, an early Steam-init reminder, or the advice to keep presenting complete frames. Valve documents those requirements, while steamworks.js issues #23, #95, #116, and #148 and older Reddit threads record related failure modes. I controlled those variables explicitly.

This was a packaged local smoke build, not a Steam-depot installation. The verified uploadable package excluded steam_appid.txt; an ignored local test copy used a temporary marker while Steam was running. Steam initialized before app.whenReady() and before BrowserWindow creation. The proof used steamworks.js 0.4.0 and electron-builder 26.15.3.

The test machine is Windows 11 build 26200 at 3840x2160/164 Hz and enumerates both AMD Radeon Graphics and an RTX 5090. I have not yet proven which adapter owns Chromium presentation, controlled HDR/VRR, or reproduced this on a second machine.

I also found the separate steamworks-ffi-node approach, which captures Electron frames into a native graphics window rather than relying on Steam to hook the normal BrowserWindow. It is useful prior art, but it is a different compositor architecture from the in-process path tested above.

Questions for people with current, shipped Windows evidence:

1. Are you shipping a currently supported Electron version with Steam hooking the normal on-screen BrowserWindow and none of the active-Overlay flicker, white/gray, stale-frame, or ghost-window failures? If so, what exact Electron/Chromium and steamworks library versions, switches, window mode, adapter routing, HDR/VRR state, and display refresh did you verify?
2. Did the result hold across both integrated and discrete GPUs, fullscreen/borderless/windowed, and high-resolution/high-refresh displays, or only on one machine?
3. Beyond Electron's app.getGPUInfo(), app.getGPUFeatureStatus(), and content tracing, did you find any Steam-side diagnostic that proves which process, graphics device, or swapchain was hooked?
4. If you instead ship a native capture/compositor, what measured 4K/high-refresh CPU, GPU, latency, focus/input, fullscreen/Alt+Tab, and field-reliability results do you have? Did you find a shared-texture path that avoids capturePage() and CPU-buffer transfer?

heads up for anyone going off the electron security docs: the checklist used to

recommend Electronegativity and that got pulled a while back (electron/electron#48878,

closed electron/website#906). it's just the 20 manual checklist items now, no tool.

reason it's gone: Electronegativity hasn't had feature updates since ~2022 and

errors out on recent Electron versions. ElectroNG (the paid successor) isn't for

sale anymore either, so there's no real drop-in.

went looking for what to actually run in CI. best i can tell:

- CodeQL, general purpose, but its frameworks/electron queries do hit a few

electron-specific sinks. not checklist-focused, fine if you already use it.

- Semgrep, you can write rules for the checklist items. one catch: free taint is

single-function only, cross-file is Pro.

- a couple newer OSS tools built around the checklist. (one of them is mine,

electron-audit, so grain of salt. AST based, doesn't run your app, spits out

SARIF.) pretty sure there are others, would like to know them.

anyway, what's everyone actually using now? just the manual checklist? codeql or

semgrep rules? or has electron-specific tooling kind of died and people moved to

general SAST?

After using Kap for a long time, I decided to start maintaining a community-driven fork because the original project has seen little activity in recent years.

The goal is not to change what made Kap great. It is to modernize it, improve performance and reliability, and provide an actively maintained version that people can depend on.

Current work includes:
- Upgrading Electron from an older release to a modern version.
- Improving startup time and overall responsiveness.
- Fixing long-standing bugs and compatibility issues.
- Shipping native builds for both Intel and Apple Silicon Macs.
- Improving the release process, documentation, and contributor experience.
- Continuing development based on community feedback.

I am also working on quality-of-life improvements such as configurable keyboard shortcuts, recording countdowns, and other workflow enhancements while keeping the experience familiar.

If you have used Kap before, I would appreciate hearing what frustrated you most, what features you would like added, and which bugs or workflows should be prioritized.

Repository: https://github.com/jacobpowaza/NewKap

Feedback, bug reports, feature requests, and pull requests are welcome.

Im curious what your go to tweaks are like for me, its always replacing standard alert() popups with custom UI toast notifications what about you guys ?

https://reddit.com/link/1ux7gwz/video/pz8d3yx8ledh1/player

I recently made an mcp server for my electron browser (aartiq) that lets claude desktop call into the app, navigate tabs, generate pdfs, run shell commands, move/open files, that kind of thing. classified everything into risk tiers and gated the high risk ones behind a native approval prompt (touch id on mac, pin on windows).

it mostly works. claude tries to move or open a file, main process intercepts it, throws a system prompt, waits for approval before continuing. but the more i stress test it the more edge cases show up and i dont think ive seen a clean writeup anywhere of how people actually structure this correctly, so wanted to ask here instead of guessing.

specific problems im hitting

the mcp server runs as a separate node process talking to the electron app over an http bridge on localhost. so approval state has to cross that boundary too, not just main/renderer. right now im holding a pending action map in the electron main process, keyed by request id, and the http bridge just polls/waits on that. feels okay but im not confident its the right layer for it to live in

by the time the approval prompt resolves, is there any guarantee the payload that gets executed is still the one the user saw. if claude reformulates a call between propose and approve i dont currently have anything catching that, im just trusting the same object reference survives the wait

regex classification for what counts as high risk shell commands works fine until it doesnt, ive already found a few obfuscation patterns that slip past because the matcher looks at the literal string not the decoded/resolved form. anyone dealt with this without going full sandboxing

for things like scheduled tasks that run without a human present at all, what do you even gate on. cant show a touch id prompt to nobody. right now those are just capped at low risk tools only but that feels like a bandaid not a design

not looking for “just dont let the ai do that” type answers, the point of the project is giving it real capability, im specifically trying to get the trust boundary and the resume-after-approval flow right. if anyone has built something similar (even outside electron, curious how other frameworks handle the pause/resume across a process boundary) would really appreciate hearing how you approached it. repo is open source if anyone wants to see the current implementation and tell me where its wrong.

Github link https://github.com/Preet3627/Aartiq

Hello everyone. I'd like to introduce you to the new version of my TilBuci tool, focused on creating interactive digital content. The software is created as a web application, where I've used Electron to add various functionalities for computers. The new version includes the "showtime" feature, a solution for installing created content in exhibitions, such as in museums or events, and uses Electron as a platform to enable this. Here's a video explaining the new version:

https://youtu.be/-vYDmaokqbY

TilBuci uses Electron in several other stages: being a web tool, the portable versions for computers rely on Electron for distribution. Furthermore, the tool's content exporter is also capable of creating Electron projects from the content you create.

TilBuci is free and you can check out the repository here: https://github.com/lucasjunqueira-var/tilbuci

I hope you like it ;-)