Main Process Runtimes

The main process doesn’t have to be JavaScript. Electrobun exposes the same native core to six runtimes — so a team that thinks in Rust, or an app whose main process is really a simulation loop, can skip the JS layer entirely and still get Electrobun’s windows, webviews, RPC, and packaging. Hutch is the build tool for every option, and switching runtimes is a config change, not a different framework.

The practical decision is simpler than six options suggests: start with Cottontail (the default), select Bun when you want the actual Bun runtime, and reach for a native language when you want compiled performance or a smaller-than-JavaScript footprint. Each runtime has a dedicated walkthrough: Cottontail, Bun, Zig, Rust, Go, and Odin — and the Main Process API page shows what the SDK looks like in every language, including a per-feature coverage matrix.

Runtime	`build.mainProcess`	Project build input	Default toolchain
Cottontail	`"cottontail"`	`src/bun/index.ts`	Downloaded runtime
Bun	`"bun"`	`src/bun/index.ts`	Downloaded runtime
Zig	`"zig"`	`build.zig`	Zig 0.16.0
Rust	`"rust"`	`Cargo.toml` / binary `main`	Rust 1.88.0
Go	`"go"`	`go.mod` / package `./src/go`	Go 1.26.4
Odin	`"odin"`	package containing `src/odin/main.odin`	Odin dev-2026-07a

Cottontail

Cottontail is the default. It executes TypeScript and supports the Node.js and Bun-compatible APIs used by Electrobun applications.

import type { ElectrobunConfig } from "electrobun";

export default {
  app: {
    name: "Cottontail App",
    identifier: "dev.example.cottontail-app",
    version: "0.1.0",
  },
  build: {
    mainProcess: "cottontail",
    cottontail: { entrypoint: "src/bun/index.ts" },
  },
} satisfies ElectrobunConfig;

import { BrowserWindow } from "electrobun/main";

new BrowserWindow({
  title: "Hello Electrobun",
  url: "views://mainview/index.html",
});

Bun

Choose Bun only when the application intentionally depends on the actual Bun runtime. Hutch bundles source and packages the app; its built-in resolver owns JavaScript dependencies by default, or the project’s explicitly selected package manager owns them instead.

import type { ElectrobunConfig } from "electrobun";

export default {
  app: {
    name: "Bun App",
    identifier: "dev.example.bun-app",
    version: "0.1.0",
  },
  build: {
    mainProcess: "bun",
    bun: { entrypoint: "src/bun/index.ts" },
  },
} satisfies ElectrobunConfig;

The TypeScript Electrobun SDK remains electrobun/main for both JavaScript runtimes.

Native main processes

Zig, Rust, Go, and Odin applications load ElectrobunCore through their SDK, create native windows and views, and run the platform event loop. They are normal projects in their language rather than source snippets generated by Hutch:

import type { ElectrobunConfig } from "electrobun";

export default {
  app: {
    name: "Native App",
    identifier: "dev.example.native-app",
    version: "0.0.1",
  },
  build: {
    mainProcess: "zig",
    zig: { version: "0.16.0" },
    copy: {
      "src/mainview/index.html": "views/mainview/index.html",
    },
  },
} satisfies ElectrobunConfig;

The Zig project owns build.zig; Hutch invokes it with the projected SDK path. Rust owns Cargo.toml and Cargo.lock, with the Electrobun SDK referenced at .hutch/devkit/rust-sdk. Go owns go.mod and go.sum, with a local replace to .hutch/devkit/go-sdk. Odin compiles the configured source package with the projected electrobun_sdk collection. Hutch does not generate any of those build descriptions or synthesize a GOPATH.

The fastest way to see real native SDK code is to generate a template — each one contains complete SDK initialization, window, webview, RPC, and event-loop examples you can copy from:

hutch electrobun init zig-app --template=zig-wgpu
hutch electrobun init rust-app --template=rust-flock-wgpu
hutch electrobun init go-app --template=go-maze-wgpu
hutch electrobun init odin-app --template=odin-particles-wgpu

Odin also has focused native graphics templates for fluid simulation, soft-body physics, cellular materials, and procedural plants:

hutch electrobun init fluid-lab --template=odin-fluid-wgpu
hutch electrobun init jelly-lab --template=odin-jelly-bunny-wgpu
hutch electrobun init alchemy-lab --template=odin-alchemy-wgpu
hutch electrobun init tree-studio --template=odin-tree-wgpu

Toolchain resolution

Each resolved Electrobun devkit declares default compiler versions. The release may come from an exact electrobun.version pin, the npm-paired default, or the active channel. A project may override one with the matching build.<language>.version field in electrobun.config.ts. Hutch checks for an exact matching system compiler where supported; otherwise it downloads that toolchain into ~/.hutch/toolchains/<language>/<version>/<platform> and reuses it across projects. The compiler is not bundled into the finished application.

hutch electrobun prepare downloads and verifies the matching Electrobun core and SDK release under ~/.hutch/releases/electrobun, copies its SDKs into the project’s generated .hutch/devkit sysroot, and resolves the native toolchain under ~/.hutch/toolchains without advancing a valid floating projection. Go builds on Windows also resolve Zig for cgo. build, run, and dev call the same preparation automatically; use sync to advance an unpinned direct-Hutch project to the current channel head.

Native limitations

Native main processes currently build for the host operating system and architecture. Use native CI runners for a release matrix.
Windows targets are x64. Windows on ARM runs the x64 build through emulation.
Windows Rust and Odin builds require Visual Studio Build Tools and the Windows SDK.
macOS needs Xcode Command Line Tools. Linux needs the platform compiler and linker packages documented in Cross-Platform Development.
Odin is pre-1.0. Electrobun guarantees the SDK against its pinned Odin release, not arbitrary Odin versions.