A USB-attached remote development backend for air-gapped environments.
Status: architectural specification. No prototype code yet. This repo documents a design and the open questions around it. Treat every hardware and performance figure below as a target to validate, not a measured result.
Client-server IDEs (JetBrains Gateway / Remote Development, for example) let a thin client drive a backend that does the heavy lifting. They assume the client can reach that backend over a network.
Regulated and air-gapped environments (defense, finance, healthcare, secure R&D labs) often cannot grant that:
- No external connectivity, so no cloud APIs and no cloud AI assistants.
- Source and build artifacts must not land on unmanaged host filesystems.
- Developers move between locked-down machines with inconsistent toolchains.
Keep the client-server model, but change the transport. Instead of a remote server reached over a network, the backend lives inside a bus-powered USB-C appliance. The host sees a virtual network adapter and talks to the backend over a private point-to-point link. Source code, toolchains, indexes, and a small local AI model stay on the device.
This is not a new IDE architecture. It is a new physical deployment target for an existing one.
| Mode | Host requirement | Status |
|---|---|---|
| A. JetBrains Client (Gateway / Toolbox launch) | JetBrains Client installed on the host, pre-approved by IT | Closest to existing JetBrains remote development; the device would act as the Linux backend |
| B. Browser frontend | A browser only | Experimental. Not an existing JetBrains product; would need a separate web IDE layer and has weaker feature parity |
Mode A is the credible path for JetBrains-style IDE features, but it means a client install on the host. Mode B delivers true zero-install but is a different, lighter experience. The project should be explicit about this tradeoff rather than claim both at once.
+-----------------------------------------------------------------+
| COMPUTE PLUG (USB-C DEVICE) |
| |
| +---------------+ +----------------------+ +------------+ |
| | USB gadget | | ARM SoC, embedded | | Encrypted | |
| | (CDC-NCM / |<->| Linux |<->| NVMe / UFS | |
| | ECM) | | Headless IDE backend | | storage | |
| +---------------+ | + LSP servers | +------------+ |
| | +----------+-----------+ |
+---------|-----------------------|-------------------------------+
| |
(virtual Ethernet, (NPU or CPU inference)
private link address) |
v v
+-------------+ +----------------------------+
| HOST | | Small local code model |
| thin client | | (completion, lint help, |
+-------------+ | small rewrites only) |
+----------------------------+
- Linux USB gadget mode (
libcomposite) presenting a virtual Ethernet adapter. CDC-NCM and ECM are preferred over legacy RNDIS for driverless operation on current Windows, macOS, Linux, and iPadOS. - The link uses a private address (for example
192.168.7.1), not loopback.
- The device should be easy for IT to enroll and allow-list (stable device identity, signed firmware, documented USB class behavior).
- It is not designed to evade endpoint security or USB controls. In a regulated environment, working with the policy is the only viable path.
- JVM languages: a headless JetBrains IDE backend, as used by Remote Development.
- Other languages: standard Language Server Protocol servers.
- Toolchains (JDKs, SDKs, compilers) are baked into the image so the environment is identical wherever the device is plugged in.
- Open question: Gateway documents Linux servers as supported backends; whether the current IDE backends run well on the aarch64 Linux this hardware would use must be verified.
- First candidate: Mellum-all, JetBrains' open-source code-completion model, run through a local runtime. Alternatives to benchmark: small code-tuned models such as Qwen-Coder.
- Scope: inline completion, lint explanations, single-file rewrites. Not multi-file agentic workflows; small on-device models cannot match cloud agents there.
- Optional cloud bridge (off by default, explicit and auditable toggle): when network policy allows, escalate a failing file plus stack trace to a cloud model through bounded tool calls. The air-gapped case never depends on it.
The device is a working copy, not the system of record. Authoritative repositories stay on the organization's side of the boundary, and the device exchanges changes with them through a controlled, verifiable process. This is a design proposal; none of it is implemented yet.
Source code
- Real Git repositories live on the device, so history, branching, and merges behave as developers expect.
- Changes cross the boundary as signed Git bundles: single files that can travel through whatever transfer channel site policy approves. No network path to the authoritative repo is required.
- Inbound: verify the bundle signature against trust anchors pinned on the device, run Git's bundle verification, fetch into a quarantine namespace, check commit signatures against an allowed-signers list, then a person approves the merge. Nothing merges automatically.
- Outbound: incremental bundles from the last acknowledged sync point, signed with a device key. Force-updates of synced refs are disallowed; divergence is resolved with normal merges.
- Integrity over time: signed commits and tags, plus a hash-chained sync ledger on the device recording every import and export.
Dependencies
- A read-only local mirror of needed packages (Maven, npm, PyPI), populated only from signed snapshots built on the connected side from project lockfiles, then imported through the same verified path.
- Lockfiles with integrity hashes where the ecosystem supports them, so a mismatch fails the build. Versioned snapshots allow rollback, and the snapshot date is visible so developers can see how stale it is.
Low-connectivity and travel use (secondary) A laptop with a local clone can already work offline. The device adds a consistent toolchain and keeps source off the host. For this case it works as store-and-forward: changes queue on the device, and when connectivity returns and policy allows, the user explicitly triggers a sync. There is no background sync by default. The air-gapped case remains the primary target.
Not solved yet: which transfer channels real sites approve, key custody and rotation, how large monorepos, submodules, and Git LFS objects behave in bundles, and how review fits existing change control. Remote wipe is impossible in an air gap, so device loss costs unsynced work. Regular exports and a stated maximum unsynced window matter.
- Can a full IDE backend (indexing, code analysis, builds) run acceptably inside the power, memory, and thermal budget of a bus-powered device? This is the first thing to measure.
- What sustained power can a typical locked-down laptop port actually deliver, and how does throttling behave under indexing load?
- Which local model gives usable completion latency on the chosen NPU/CPU, and at what quality?
- How much IDE plugin functionality survives in a headless backend?
| Risk | Mitigation direction |
|---|---|
| Backend memory footprint on small hardware | Measure early; fall back to LSP-only mode for lighter languages |
| Flash wear from indexing and builds | Require NVMe/UFS with wear-leveling; avoid SD/eMMC |
| Thermal throttling in a small enclosure | Prototype thermal testing before any enclosure design |
| USB policy blocks in managed fleets | Standard device classes, signed firmware, IT enrollment workflow |
| Local model quality ceiling | Tiered design: local for fast/simple, optional cloud for deep tasks |
| Overlap with existing JetBrains remote-dev tooling | Position as a deployment target for it, not a competitor |
| Source drift or tampering across the sync boundary | Signed bundles and commits, quarantine import, hash-chained sync ledger |
| Stale or tampered dependencies | Signed snapshots, lockfile integrity hashes, visible snapshot date, rollback |
- Weeks 1-4: USB gadget mode on a Raspberry Pi Zero 2 W or Radxa Zero serving a minimal web page to Windows, macOS, and Linux hosts with no drivers. Then attempt a headless backend and Mode A client connection.
- Weeks 5-8: Measure memory, indexing time, link latency, power draw. Publish the numbers, including the unflattering ones.
- Weeks 9-12: Add local model completion, then the optional cloud bridge. Record a demo that works with the network unplugged.
- Weeks 13-16: Signed bundle round trip (export, verify, import) against a reference repository, plus a read-only dependency mirror populated from a signed snapshot.
- JetBrains Gateway / Remote Development: the model this project extends to a USB-attached backend.
- Mellum: JetBrains' completion model, used here as the preferred local model candidate.
- Fleet: discontinued by JetBrains in December 2025, so this project does not depend on it. Components and ideas from it live on in other JetBrains tooling, including the newer agentic tool Air (in preview).
Copyright 2026 Ashwin H. Code is licensed under the Apache License 2.0. Hardware designs, when added: CERN-OHL-W v2. Model weights keep their own upstream licenses.
Early stage. The most useful contributions right now are measurements: backend footprint on small ARM boards, USB gadget behavior on locked-down hosts, and local model latency numbers.
JetBrains, IntelliJ, Gateway, and Mellum are trademarks of JetBrains s.r.o. This is an independent project and is not affiliated with or endorsed by JetBrains.