open-sourcecommunityproject

Open Project: A Minimal CLI for Submitting Quantum Jobs from Local Browsers and Edge Nodes

UUnknown

2026-02-17

10 min read

Open-source scaffold for a lightweight, secure CLI and local agent to submit quantum jobs from browsers, desktops and Raspberry Pi edge nodes — join the project.

Ship quantum jobs from your browser or Pi: a practical open-source CLI scaffold and call for contributors

Hook: You need a dependable, secure way to submit quantum workloads from where development actually happens — local browsers, desktop agents, and low‑power edge nodes such as Raspberry Pi — without sacrificing provenance, developer ergonomics, or security. This proposal outlines an open-source CLI and companion local agent that fills that gap and invites the community to build it together.

Executive summary (most important first)

We propose an open project — provisionally named q-submit — that provides a tiny cross‑platform CLI plus a lightweight local agent/daemon to accept signed job submissions from:

The CLI/agent package will:

Package quantum jobs (OpenQASM3, QIR, or SDK payload) with metadata and signatures — see related resources on running quantum simulators locally for testing payloads
Enforce end‑to‑end provenance and short‑lived credentials
Support offline queueing and store‑and‑forward from edge nodes
Be lightweight (single binary recommended) and easy to audit

Why now? In 2026 local AI tooling and more capable edge devices (Pi 5 + AI HATs), local browser ecosystems that prioritise privacy, and the maturation of quantum SDK standards (OpenQASM3, QIR) make this the right window to deliver a community tool that bridges local dev and remote quantum hardware.

Why the community needs q-submit in 2026

Technology professionals building hybrid quantum/classical workflows face friction:

Quantum hardware access is fragmented — cloud providers, private research QPUs, simulators — and each has different auth and job APIs.
Developers want to iterate locally (browser notebooks, VS Code, Pi edge) but current job submission flows often require manual copying of files, credential juggling, or proprietary SDKs.
Security and auditability are increasingly required for enterprise adoption; ad‑hoc submission channels lack provenance and tamper evidence.

q-submit addresses these by providing a standard local endpoint and CLI for secure packaging and submission. It lets developers stay in their preferred environment (local browser notebook, desktop, or Pi edge node) while enforcing modern security and workflow ergonomics.

Trends and context (2024–2026) that make this feasible

Recent trends that shape the design:

Edge hardware: Raspberry Pi 5 coupled with AI HATs and improved ARM performance in 2025–2026 makes it practical to run preprocessing and small LLM inference at the edge. Use cases include local classical pre/post processing for quantum hybrid algorithms.
Local browser resurgence: Privacy‑first browsers and local AI features (2025–2026) show developers are comfortable with powerful local-first experiences that avoid cloud‑only flows.
Standardisation in quantum IR: OpenQASM3 and QIR are broadly used, enabling a canonical payload format for job packaging. See notes on running local quantum simulators for prototyping.
Provider variety: More commercial and research QPU offerings with diverse APIs emphasise the need for an agnostic submission layer.

Design principles

Local-first UX: Developers should be able to submit jobs from browser notebooks and local terminals without manual token copying.
Minimal trusted surface: Keep the agent small, auditable, and dependency-minimal (single binary in Rust/Go recommended).
End-to-end provenance: Jobs must be signed; the backend should be able to verify origin, code checksum, and submitter identity.
Offline resilience: Edge nodes should queue jobs, sign them locally, and forward when connected — patterns here overlap with edge orchestration and security playbooks for remote launch pads (edge orchestration).
Extensible connectors: Provide a plugin system for provider adapters (IBM, IonQ, Rigetti, Azure Quantum, Braket, private QPUs).
Privacy and least privilege: Use short‑lived credentials and provide clear data residency controls. Consider compliance-first approaches described in serverless/edge strategy documents (serverless edge for compliance).

High-level architecture

Components:

q-submit CLI — user facing: installable tool that packages jobs, signs them (WebAuthn/YubiKey optional), and communicates with the local agent.
Local agent / daemon — runs on localhost (or edge) and mediates between local submitters and remote gateways or directly to providers. Handles offline queueing, credential refresh, and provider connectors.
Browser connector — a small JS library for notebooks and single-page apps to handshake with the local agent via a secure local channel (WebSocket over localhost or WebTransport, with short‑lived ephemeral tokens and user approval). See companion app patterns and lightweight JS connector templates used by exhibitors and gadget startups (CES companion apps).
Provider adapters — plugins or microservices that translate the canonical job package to provider APIs and handle result retrieval. Adapter implementations may integrate with large object stores or artifact repositories (see object storage reviews for AI workloads: object storage providers).
Remote gateway (optional) — for sites that want to centralise routing, policy, and billing.

Communication model

Recommended stack:

Browser ⇄ Local Agent: WebTransport or secure WebSocket to localhost with a one‑time ephemeral token issued by the CLI or via user confirmation in the agent GUI. This avoids exposing any long‑lived tokens to the page.
Agent ⇄ Provider Gateway: mTLS with rotated short‑lived JWTs; provider adapters handle provider-specific auth.
Signing: Jobs are signed using a local keypair; WebAuthn or an HSM can be used for higher assurance. For higher assurance and edge identity patterns, see creator tooling and edge identity discussions (edge identity).

Job packaging (concrete)

Use a canonical JSON manifest and a compressed payload bundle. Example manifest fields:

{
  "schema_version": "2026-01-01",
  "job_id": "uuid-v4",
  "submitter": {
    "id": "user@example.com",
    "key_id": "pubkey-xx"
  },
  "language": "openqasm3",
  "payload_sha256": "...",
  "backend_preferences": ["ionq", "ibm:nyu-lab"],
  "resources": {"shots":1024, "qubits":12},
  "metadata": {"project":"metrology-experiment","commit":"abc123"}
}

The bundle is a gzipped tar of the manifest and payload (OpenQASM3 file, circuit JSON, or serialized SDK object). The CLI signs the bundle and creates a detached signature that the agent and provider can verify. For local end-to-end testing, consider running against local simulator workflows and mobile/edge simulator notes such as running quantum simulators locally.

Example flows and commands

Local CLI submission (desktop)

# install (example)
curl -sSL https://get.q-submit.sh | bash

# package and submit a job (local CLI)
q-submit package --source circuit.qasm --backend ionq --shots 1024 --output job.bundle
q-submit submit --file job.bundle --wait

Browser notebook flow

Notebook imports the browser connector JS: const agent = await QSubmit.connect()
The connector opens a secure localhost channel. The user approves in the local agent UI (one click), which returns an ephemeral capability token.
Notebook calls agent.submit({manifest, payload}) and receives a job UUID.

Edge (Raspberry Pi) offline mode

For edge devices that may be intermittently connected, the agent signs and queues bundles locally in a secure store. A simple systemd unit on Pi ensures agent restarts. Example snippet for a systemd unit:

[Unit]
Description=q-submit local agent
After=network.target

[Service]
User=pi
ExecStart=/usr/local/bin/q-submit-agent --data-dir /var/lib/q-submit
Restart=on-failure

[Install]
WantedBy=multi-user.target

Operational docs and ops-tooling patterns (hosted tunnels, local testing and zero‑downtime releases) are useful when validating service startup and networking on constrained hosts: hosted tunnels & local testing.

Security model (details)

Security is central. Key points:

Local approval: Browser requests must be approved locally (agent UI or OS‑level prompt) to prevent web pages from silently submitting jobs.
Short‑lived capabilities: Tokens for browser→agent communication are ephemeral (seconds/minutes) and bound to origin and process.
Signed bundles: Job bundles include a detached signature; providers verify signatures before execution to ensure integrity and provenance. Consider audit trail best practices when designing signing and retention: audit trail best practices.
Hardware-backed keys: Support optional WebAuthn/YubiKey or TPM on Pi for higher assurance signing.
Least privilege: Agent stores only the minimum credentials necessary and encrypts its data store (AES‑GCM + HKDF).

Design for audit: every job submission is an auditable event — who submitted, when, the code checksum, and where it executed.

Implementation recommendations

Language and packaging:

Core agent/CLI: Rust (preferred) or Go for a single statically linked binary across Linux/x86_64, Linux/aarch64, macOS, and Windows.
Browser connector: small vanilla JS module that uses WebTransport/WebSocket; avoid heavy frameworks for auditability. See companion-app connector templates for examples (CES companion apps).
Provider adapters: separate processes or serverless functions in Python/Node/Rust to use provider SDKs (Qiskit, Pennylane, Braket SDK, Azure Quantum). Adapters often need reliable artifact stores — review top options for AI workloads and large payloads: object storage reviews.

Developer experience: examples and snippets

Python example that uses the CLI as a local submission gateway (pseudo‑code):

import subprocess

# package a qasm file and submit via q-submit CLI
subprocess.run(["q-submit","package","--source","circuit.qasm","--output","/tmp/job.bundle"])
proc = subprocess.run(["q-submit","submit","--file","/tmp/job.bundle","--backend","ionq"], capture_output=True, text=True)
print(proc.stdout)  # contains job id and status

Testing, CI and reproducibility

To be trustworthy, the project needs strong automated tests and reproducible builds:

GitHub Actions matrix builds for x86_64, armv7, aarch64.
Unit tests that include signature verification, token expiry, and queueing behaviour.
Integration tests running against simulators (Qiskit Aer or a lightweight local simulator) in CI for submission/roundtrip.
Fuzz tests for manifest parsing, and static analysis for dependency safety.

Governance, license and contribution model

We recommend:

License: Apache 2.0 for permissive use in research and commercial settings.
Contrib model: GitHub org with clear CODE_OF_CONDUCT, CONTRIBUTING.md, and issue labels: good-first-issue, security, infra, docs, adapter.
Maintainers: Small core team with rotating reviewers; accept community PRs for adapters and docs.

Roadmap and first milestones (MVP)

Core CLI + local agent that accepts signed bundles and forwards to a mock provider (simulator).
Browser connector enabling a JupyterLab/Colab extension demo.
Raspberry Pi systemd packaging and a minimal offline queue demo.
Three provider adapters: Qiskit (IBM), IonQ, and Braket (simulator) as reference implementations.
Security audit and reproducible builds.

How you can contribute (concrete call‑to‑action)

We need contributors across these areas:

Systems engineers (Rust/Go) to build the agent/CLI.
JS developers to write the browser connector and notebook integrations.
ARM/RPi maintainers to validate packaging and performance on Pi 4/5 — see edge device patterns and tuning in the edge AI & smart sensors review.
Security reviewers for threat modelling, WebAuthn/TLS, and audit of signing mechanisms.
Provider adapters maintainers: if you use IBM, IonQ, Rigetti, Azure Quantum, Braket, or a private QPU, help write an adapter.
Docs and community managers to run meetups, onboarding sessions, and hackathons.

Starter tasks you can take in the first two weeks:

Open a repo and add LICENSE, README, CODE_OF_CONDUCT, and CONTRIBUTING.md.
Create a minimal Rust CLI that prints version and accepts a –package flag.
Build a browser sample that demonstrates a localhost handshake and approval flow.
Spin up a Raspberry Pi VM and validate cross‑compiled binary runs and registers a systemd service.

Community & events strategy

To accelerate adoption and attract contributors, propose a sequence of community events:

Project launch webinar (demo: local browser → Pi → simulator).
Monthly hack nights focused on adapters (IBM, IonQ, Braket).
Quarterly security sprints for audits and threat modelling.
Physical meetups at quantum conferences — live debugging and workshop for Pi edge deployments.

Advanced strategies & future directions (2026+)

Potential extensions that would add real value as the project matures:

Policy engine: enterprise policy for allowed backends, data residency, and cost controls — policy engines dovetail with compliance-first edge strategies (serverless edge).
Verifiable execution receipts: append immutable provenance records (Merkle trees, timestamping) to results for compliance.
Plugin marketplace: community adapters and utilities (postprocessing filters, noise profiles).
Hybrid job orchestration: coordinate classical pre/post tasks (RPC to local AI inferencer on Pi HAT) and quantum execution as a single workflow — patterns overlap with edge orchestration design.

Actionable takeaways

If you run quantum experiments from a laptop or Pi, a small local agent + signed job bundles dramatically reduces friction and improves auditability.
Implement the MVP using a single binary (Rust) and a small JS connector for browsers to reduce maintenance and ease audits.
Design for offline queuing on edge nodes and ephemeral tokens for browser approval to protect user credentials.
Start small: package and signing, then add provider adapters and security audits. Consider storage and CI choices for artifacts (see cloud NAS and object storage reviews).

Closing: join the open project

We are ready to bootstrap an open community project that solves a widely felt pain: a repeatable, secure, and local‑first way to submit quantum jobs from where developers actually work. If you are a developer, Raspberry Pi enthusiast, security engineer, or quantum SDK maintainer, your expertise will accelerate this effort.

Call to action: Create a GitHub org/repo named q-submit, add the recommended governance files (LICENSE: Apache‑2.0, CONTRIBUTING.md, CODE_OF_CONDUCT), and open the first issue: "MVP: Basic CLI and local agent that accepts signed bundles and forwards to simulator." Host a 1‑hour kickoff call to attract contributors and run the first hack night. If you want to lead a subproject (browser connector, Raspberry Pi packaging, or provider adapter), file an issue describing your plan and tag it "maintainer‑needed".

Together, we can make local‑first, secure quantum job submission a reality — enabling reproducible experimentation, safer workflows, and faster iteration for quantum developers around the world.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.