---
title: "Migrate Off Capacitor Community Electron"
description: "Looking for a maintained @capacitor-community/electron alternative? Learn how to migrate your Capacitor desktop app to the new Capacitor Electron Platform."
date:
  created: 2026-07-17
  updated: 2026-07-17
authors:
  - robingenz
categories:
  - Capacitor
  - Electron
  - Guides
faq: true
links:
  - Capacitor Electron: sdks/capacitor/electron.md
---

# Migrate Off Capacitor Community Electron

If you have been searching for a maintained **capacitor community electron alternative**, this guide is for you. The [Capacitor Community Electron Platform](https://github.com/capacitor-community/electron){:target="_blank"} is no longer actively maintained, which leaves desktop apps pinned to aging Electron versions and a large generated project you have to babysit yourself. Here you will learn how to move your Capacitor desktop app to the maintained [Capacitor Electron Platform](../../sdks/capacitor/electron.md), step by step.

<!-- more -->

<div class="capawesome-z29o10a">
  <a href="https://capawesome.io/" target="_blank">
    <img alt="Build and deploy your Capacitor app with Capawesome Cloud" src="https://capawesome.io/assets/banners/cloud-build-and-deploy-capacitor-apps.png?t=1" />
  </a>
</div>

**Key takeaways:**

- The `@capacitor-community/electron` platform is no longer actively maintained, so staying on it means falling further behind on security and Electron releases.
- The maintained alternative is `@capawesome/capacitor-electron`, licensed under MIT and free to use.
- Instead of owning a large generated Electron project, you own a minimal scaffold while the platform logic ships in a versioned npm package.
- Plugins with a web implementation keep working through automatic fallback, so most apps migrate with little friction.
- Security defaults such as a sandboxed renderer, context isolation, and a strict CSP are enabled out of the box and cannot be weakened.
- The platform requires Capacitor 6 or later and Electron 28 or later.

## Why migrate away from the Capacitor Community Electron platform?

The short version: the `@capacitor-community/electron` platform is no longer actively maintained. New releases have stalled, and that has a few concrete consequences you feel in day-to-day development.

First, you are effectively pinned to older Electron versions. Electron ships frequent security patches, and Chromium vulnerabilities are disclosed regularly. When the platform that wires Electron into your Capacitor app stops keeping up, upgrading becomes your problem to solve by hand, and the gap only grows over time.

Second, the community platform generates a full Electron project inside your repository. That generated `electron/` folder contains the main process, preload scripts, and build wiring, and all of it lives in your source tree. You own every line of it. When something needs to change, whether it is a security fix, a new Electron API, or a build tweak, there is no package update that carries the improvement to you. You edit the generated code yourself and hope you got the details right.

For a desktop runtime that sits between the operating system and your web layer, that is a real risk. Security-sensitive defaults drift, bugs go unpatched, and the maintenance burden quietly shifts onto your team. Looking for a maintained capacitor community electron alternative is the sensible response, not a nice-to-have.

## What's different in the Capacitor Electron Platform?

The [Capacitor Electron Platform](../../sdks/capacitor/electron.md) takes a different approach to almost every one of those pain points. The core idea is that you should own as little runtime code as possible, while the platform maintainers own the parts that need regular updates. The table below compares the two platforms across the aspects that matter most during a migration.

| Aspect | Community Electron | Capacitor Electron Platform |
| --- | --- | --- |
| Maintenance status | No longer actively maintained | Actively maintained, released under MIT |
| Runtime ownership | You own a large generated Electron project | You own a minimal scaffold; platform logic lives in the versioned npm package and updates via `npm update` |
| Security defaults | Configured manually in generated code | Sandboxed renderer, context isolation, strict CSP, and validated IPC enabled by default |
| Live Updates | None | Built-in serving primitive with failed-boot rollback |
| Electron version | Pinned to an older version | Tracks the latest Electron, with a floor of Electron 28 |

The ownership row is the one that changes the most in practice. Because the heavy lifting lives inside `@capawesome/capacitor-electron`, a routine `npm update` pulls in security hardening, bug fixes, and support for newer Electron releases. You are no longer the sole maintainer of your desktop runtime.

The security row matters just as much. The renderer runs sandboxed with context isolation, a strict Content Security Policy is applied, and IPC messages are validated. These defaults are mandatory and cannot be weakened, which removes a whole category of mistakes that were easy to make when you hand-edited a generated main process.

There is also something genuinely new here. The Capacitor Electron Platform is the first Capacitor desktop platform with built-in Live Updates. It ships a provider-agnostic serving API together with a watchdog that rolls back to the last known-good bundle if a new one fails to boot. If you already deliver over-the-air updates on mobile, you can now extend the same idea to the desktop.

## How do you migrate to the Capacitor Electron Platform?

Migrating is mostly a matter of removing the old platform, adding the new one, and moving any custom code into the new extension points. The steps below walk through the full path. To keep things focused, the install details are kept short and linked rather than repeated in full, since the migration path is the interesting part here.

### The fast path: AI-assisted migration

If you would rather not do this by hand, there is a shortcut. The [Capawesome Skills](https://github.com/capawesome-team/skills){:target="_blank"} include a `capacitor-platforms` skill that adds and configures the Capacitor Electron Platform for you directly from your AI assistant. Add it to your tool of choice with a single command.

```bash
npx skills add capawesome-team/skills --skill capacitor-platforms
```

Then prompt your assistant to add the `@capawesome/capacitor-electron` platform to your project, and it will scaffold and wire up the setup for you. It is the quickest way to get onto the maintained platform. The manual steps below are still worth reading so you understand what changes during the migration, and to handle anything the assistant leaves for you to review, such as porting a custom plugin implementation.

### Step 1 — Remove the old platform

Begin by uninstalling the community platform and deleting the project it generated. Removing the package first makes sure nothing tries to reference it afterwards.

```bash
npm uninstall @capacitor-community/electron
```

After that, delete the generated `electron/` project from your repository. It contained runtime code you no longer need, since the new platform provides its own scaffold in the next step. If you made custom changes in that folder, note them down first, because Step 3 shows where they belong now.

### Step 2 — Add the new platform

With the old platform gone, install the maintained alternative and add it as a Capacitor platform. The `cap add` command scaffolds a fresh `electron/` folder.

```bash
npm install @capawesome/capacitor-electron
npx cap add @capawesome/capacitor-electron
```

The new scaffold is intentionally minimal. It contains only what you are meant to own, while the platform logic stays in the npm package. For a full walkthrough of the initial setup, see [the getting-started guide](./how-to-build-a-desktop-app-with-capacitor-and-electron.md) and the [Installation](../../sdks/capacitor/electron.md#installation) section in the SDK documentation.

### Step 3 — Move custom main-process code into config hooks

With the community platform, any custom main-process behavior meant editing the generated main process directly. Trays, application menus, and window tweaks all lived in code you owned and maintained. The new platform replaces that pattern with dedicated hooks so your customizations survive updates.

You configure these hooks under the `hooks` key in `capacitor.electron.config.ts`. There are three of them: `beforeReady` runs before the app is ready and receives the Electron `app`, `windowFactory` creates the browser window, and `onWindowCreated` runs after a window exists. A typical config looks like this.

```typescript
import { defineConfig } from '@capawesome/capacitor-electron/config';

export default defineConfig({
  hooks: {
    beforeReady: (app) => {
      // Set up trays, application menus, or other startup logic.
    },
    onWindowCreated: (window) => {
      // Tweak the window after it has been created.
    },
  },
});
```

If you provide a custom `windowFactory`, keep one rule in mind: it must not weaken the mandatory security options. Context isolation, the sandbox, and the strict CSP stay in place no matter what your factory returns. This is deliberate, and it is what keeps every app on the platform secure by default.

### Step 4 — Handle plugins

Plugins are usually the part developers worry about most, and here the news is good for the majority of cases. Any plugin that has a web implementation works automatically through the platform's fallback mechanism, so you do not need to touch it at all.

The plugins that need attention are the ones that shipped a custom Electron implementation for the community platform. That old approach is not compatible with the new one, so those plugins must be re-implemented against the new plugin contract. The contract is small: a plugin class exposes its public API through static `__capacitorElectronPlugin` metadata with a `name` and a list of `methods`. The optional `defineElectronPlugin(metadata, pluginClass)` helper sets that metadata for you.

```typescript
import { defineElectronPlugin } from '@capawesome/capacitor-electron/plugin';

class EchoImpl {
  async echo(options: { value: string }) {
    return { value: options.value };
  }
}

export const Echo = defineElectronPlugin(
  { name: 'Echo', methods: ['echo'] },
  EchoImpl,
);
```

If you maintain plugins yourself, or you depend on one that needs porting, point the author to the plugin author guide in the [repository](https://github.com/capawesome-team/capacitor-electron){:target="_blank"}. It covers the contract and packaging expectations in detail.

### Step 5 — Update packaging

Packaging moves into the scaffolded `electron/` folder. The `pack` script runs the full pipeline for you: it compiles TypeScript, vendors the runtime dependencies, and then hands off to electron-builder.

```bash
cd electron && npm run pack
```

Your existing signing and notarization settings carry over cleanly. They live in `electron-builder.config.js`, so if you already configured code signing for macOS or Windows, you can bring that configuration across with minimal changes.

### Step 6 — Verify

Finally, run the app to confirm everything is wired up. The Capacitor CLI can launch the Electron target directly.

```bash
npx cap run @capawesome/capacitor-electron
```

Once the app is running, a quick sanity check is to confirm the platform name. Calling `Capacitor.getPlatform()` in your web layer should return `'electron'`, which tells you the platform is detected and your web code can branch on it just like it does for `'ios'` or `'android'`.

## What if a plugin has no Electron implementation?

This comes up often enough to call out on its own. If a plugin has no dedicated Electron implementation, the platform falls back to the plugin's web implementation, and in most cases that is exactly what you want. A large share of Capacitor plugins are perfectly happy running their web code inside the Electron renderer.

When the web fallback is not enough, for example when a plugin needs true native desktop APIs, you have two options. You can implement the plugin against the new contract described in Step 4, or you can open an issue in the [repository](https://github.com/capawesome-team/capacitor-electron){:target="_blank"} so the maintainers and community can help. Either way, you are not stuck.

## FAQ

### Is the Capacitor Electron Platform free?

Yes. `@capawesome/capacitor-electron` is licensed under MIT and is free to use in both open source and commercial projects.

### Do my existing plugins work?

Plugins with a web implementation work automatically through the platform's fallback mechanism. Only plugins that shipped a custom Electron implementation for the community platform need to be re-implemented against the new plugin contract.

### Which Capacitor and Electron versions are required?

The platform requires Capacitor 6 or later and Electron 28 or later. It tracks recent Electron releases, so you stay closer to the latest security patches over time.

### Can I keep my electron-builder config?

Yes. Packaging is handled by electron-builder, and your signing and notarization settings live in `electron-builder.config.js`. Existing configuration carries over with little to no change.

### How is this different from owning the generated project?

With the community platform you owned the entire generated Electron project. With the Capacitor Electron Platform you own only a minimal scaffold, while the runtime logic ships in the npm package and updates through `npm update`.

Ready to move your desktop app onto a maintained platform and unlock Live Updates on the desktop? Give Capawesome Cloud a try and ship your Capacitor app with confidence.

[Try Capawesome Cloud Free](https://capawesome.io){ .md-button .md-button--primary }

## Conclusion

Staying on an unmaintained desktop platform is a slow-moving risk: old Electron versions, unpatched security defaults, and a large generated project that only you can maintain. The Capacitor Electron Platform flips that around. You own a minimal scaffold, the platform logic updates through npm, security-first defaults are on by default, and you get built-in Live Updates on the desktop for the first time. Most apps migrate by swapping the package, moving custom code into config hooks, and re-implementing the handful of plugins that need it.

If you are setting up desktop support for the first time or want a deeper look at the platform, read [Build a desktop app with Capacitor and Electron](./how-to-build-a-desktop-app-with-capacitor-and-electron.md). Questions are welcome on the [Capawesome Discord server](https://discord.gg/VCXxSVjefW){:target="_blank"}, and you can follow along with new releases through the [Capawesome newsletter](https://capawesome.io/newsletter){:target="_blank"}.