apptron

Apptron is a local-first development platform that boots a real Alpine Linux environment, complete with a custom kernel, entirely client-side in the browser. It uses the v86 x86 JIT emulator together with Wanix, a filesystem-as-capability runtime, to give that guest Linux native access to WebAssembly execution and browser DOM APIs as if they were ordinary mount points. The primary interface is a built-in VSCode-based editor, which doubles as both an IDE for your projects and the general interface for using the environment as a compute platform in its own right, similar in spirit to a Smalltalk image.

Because the guest OS runs entirely in-browser, nothing is billed or provisioned server-side for compute: every page load allocates a session IP on a virtual network, and any TCP service you bind inside the environment automatically gets a public HTTPS endpoint, tunneled the way Ngrok would do it, with non-HTTP services proxied over WebSocket. Project, home, and public directories persist across reloads via browser storage and are cloud-synced, while anything outside them resets like an uncommitted Docker layer. A separate Cloudflare Worker backend (written in TypeScript) handles Hanko-based passwordless authentication, R2-backed project storage, and publishing static sites under aptn.pub domains.

The project is written mostly in Go, which gets first-class treatment: Apptron bundles a precompiled Go 1.25 standard library so builds don’t pay the browser’s slower execution cost on every run, and the Alpine environment ships apk along with make, git, and esbuild preinstalled. Because it is fully extendable, customizable, and self-hostable, teams can also treat Apptron less as a finished IDE and more as a foundation for building their own browser-native development platform.

What You Get

• A full Alpine Linux environment with a custom kernel running client-side via the v86 x86 JIT emulator
• A built-in VSCode-based editor and IDE for your project, home, and public directories
• Automatic virtual networking: a per-session IP plus a public HTTPS endpoint for any TCP service you bind
• Native WebAssembly execution and DOM API access exposed through the filesystem via Wanix
• Preinstalled apk packages (make, git, esbuild) and a bundled, precompiled Go 1.25 toolchain
• A Cloudflare Worker backend handling Hanko-based auth, R2-backed project storage, and public-site publishing

Common Use Cases

• Instant, zero-install development environments and editors
• Sandboxing AI agents and experiments inside a disposable, resettable Linux VM
• Publishing static sites and demos straight from the in-browser environment
• Embedding a self-contained software playground inside another web page
• Running and sharing Linux or Wasm software directly from a shared browser link

Under The Hood

Architecture boot.go is the WASM entrypoint (//go:build js && wasm) that composes a set of filesystem layers (cowfs, fskit, httpfs, memfs, p9kit, syncfs, tarfs) and boots a v86-emulated guest kernel, all wired through Wanix (tractor.dev/wanix), which supplies the fs, vm, and browser-runtime abstractions the rest of the client depends on. Inside the guest, system/cmd/aptn is a separate small Go binary (built for linux/386 via the Dockerfile’s aptn-go/aptn-tinygo stages) that bridges host and guest through fuse, port-forwarding, exec, and shared-memory 9P serving (fuse.go, ports.go, exec.go, shm9p.go). The worker/ directory is an entirely separate Cloudflare Worker (worker/cmd/worker/main.go, TypeScript sources under worker/src) handling auth, R2-backed persistence, and public-site proxying, fully decoupled from the client-side VM. It’s a layered, three-tier design (browser WASM host, emulated guest OS, edge worker backend) built around Wanix’s filesystem-as-capability model as the load-bearing abstraction — changing it would ripple through both boot.go’s composition and the guest-side tooling.

Tech Stack The host runtime is Go 1.25 (module apptron.dev) compiled to js/wasm, depending on tractor.dev/wanix, tractor.dev/toolkit-go, and a forked github.com/hugelgupf/p9 for 9P filesystem serving. The guest-side aptn binary is a separate Go module cross-compiled for linux/386 (via golang:1.25-alpine or tinygo 0.36) into a 32-bit Alpine 3.22 rootfs, run inside the v86 x86 JIT emulator with a custom prebuilt kernel image. The edge backend is a TypeScript Cloudflare Worker using @cloudflare/containers, deployed with wrangler, backed by R2 for storage and Hanko for passwordless session auth. End-to-end tests run via Playwright against Mailinator-provisioned test accounts. A multi-stage Dockerfile assembles and brotli-compresses the rootfs, kernel, v86 wasm binary, and Go source/build-cache tarballs into static bundles the worker serves.

Code Quality No Go unit tests (*_test.go) were found anywhere in the repository; coverage instead comes from Playwright end-to-end specs (tests/auth.test.ts) with dedicated setup/teardown fixtures driving Mailinator and Hanko’s admin API. Go code uses conventional error returns and explicit build tags but has no linter configuration checked in. The TypeScript worker code is narrowly typed (e.g. the ValidationResponse interface in auth.ts) and wraps network calls in try/catch with explicit logging rather than swallowing failures. CI workflows exist for building the kernel and deploying, but not for running a Go test suite, since there isn’t one — quality assurance here is e2e-first, not unit-tested.

What Makes It Unique Most browser-based IDEs either proxy to a real remote server (Codespaces) or run a JavaScript-only sandboxed runtime (StackBlitz-style WebContainers); Apptron instead emulates a genuinely full Linux distribution, kernel and all, entirely client-side, then bridges host and guest through a shared filesystem abstraction that exposes native Wasm execution and DOM APIs as ordinary mount points. Combined with automatic per-session virtual networking that grants any bound TCP port a public HTTPS tunnel at no server-compute cost to the operator, it’s an unusual assembly of existing pieces (v86, Wanix, an edge worker) into something not commonly seen packaged this way.

Self-Hosting

Licensing Model No LICENSE file is published in this repository (GitHub does not detect a license), so formal reuse terms are unclear even though the source is public; there is no license-key or paid-tier gating found anywhere in the codebase.

Self-Hosting Restrictions None found — no code paths (Go or TypeScript) check for a license key, subscription status, or feature flag before enabling functionality.

Enterprise Features None — there is no separate enterprise or paid tier; the project ships as a single self-hostable stack (guest OS, editor, and Cloudflare Worker backend).

License Key Required No.