Open QubitHub

The open quantum computing commons

Discover, run and share quantum workloads, in the open.

A community platform for researchers, developers and businesses: a catalog of reusable circuits, models and datasets, a browser Playground, a provider-agnostic job API, benchmarks and reproducible reports.

Computations run on a classical simulator, in your browser or on the QubitHub server. No quantum hardware or payments are involved; catalog entries and statistics are labelled sample data.

Status
qubithub.io · live
Simulator
Real state vector, up to 20 qubits
Quantum hardware
Not connected yet
Access
By approval, with a role
Hosting
OVHcloud Public Cloud, in the EU

Why a commons

Quantum work is fragmented, rarely reused and hard to reproduce.

QubitHub is one vendor-neutral place to discover, build, run, compare and share quantum workloads.

Fragmented

Every vendor has its own SDK, account, queue and result format. QubitHub puts one job interface in front of them.

Rarely reused

Circuits, models and benchmarks are scattered across papers and repositories. The catalog gives them versions, licences and a place to be found.

Hard to reproduce

A result is of little use without the circuit, backend version, parameters, shots and seed that produced it. Every QubitHub job records all of them.

Product areas

Five product areas, one platform.

Each area sits behind a replaceable service interface: simulators today, real providers through a gateway when they are connected.

Quantum Inference

Submit jobs through one interface to the in-browser simulator, a shared pool, a noisy device profile, a fault-injection sandbox or a remote gateway. Validation, queues, cancellation, timeouts, logs and results.

Quantum Infrastructure

Providers and backends with capability metadata: gates, qubits, coupling map, calibration timestamp and availability, plus service health and queues.

Quantum Platform

A searchable catalog of models, circuits, algorithms, datasets, benchmarks and projects with tags, versions, licences, files, examples and results with provenance.

Quantum Playground

Visual and OpenQASM circuit editing with parameters, shots, seeds and backends. Counts, state vector, Bloch components, logs and metadata; save, share and export.

Dashboard and reports

Recent jobs and projects, usage against quota and alerts. Job, project and benchmark reports with a reproducibility appendix, CSV and JSON export and a print view.

Workspaces and roles

Accounts approved by a super admin, roles from Viewer to Owner, an admin console with access requests, users and an audit log, and light, dark and high-contrast themes.

Try it

Run a circuit in one click.

This runner uses the same approach as the QubitHub Playground: a dense state-vector simulation with seeded shot sampling, so the same seed always returns the same counts.

  • Bell and GHZ states split their shots between the all-zero and all-one outcomes
  • Two-qubit Grover search finds the marked state 11 in a single iteration
  • The full Playground adds a visual editor, OpenQASM import and export, parameters, noisy device profiles and job metadata

Open the full Playground (sign-in required)

Run a circuit
Simulated

A real state-vector simulation, computed in your browser. The same engine runs the QubitHub Playground.

Quantum Inference

One interface, many backends.

The Playground, the industry demos and the benchmarks all submit the same job draft. Validation runs on every edit, so an unavailable backend, an unsupported gate or an exceeded quota shows before anything is submitted.

real computation in this build mock service, labelled not connected BROWSER · public code only, no credentials Playground visual + OpenQASM Industry demos 6 workflows Benchmarks suites × backends JobDraft InferenceService single entry point for every job 1 validate backend · quota · role · gates 2 record JobRecord + reproducibility data 3 dispatch to the backend's provider 4 poll status · queue position · logs 5 enforce timeout cancels where the provider can 6 store result counts + provenance label QuantumProvider interface submit · poll · cancel · health LocalSimulatorProvider State-vector simulator, ≤ 20 qubits Web Worker · seeded sampling MockCloudProvider Shared pool · Aurora-7 · Kestrel-27 fault sandbox · all labelled mock HttpGatewayProvider HTTPS to /v1/jobs · poll · cancel no provider keys in the browser dispatch secret boundary SERVER · holds provider credentials Quantum hardware not connected in this build Upstream adapter stub: add a provider SDK Server simulator same engine API gateway /v1/backends · /v1/jobs rate limit · bearer token keys stay in its environment HTTPS runs routes SDK call JOB LIFECYCLE · identical for every backend queued running completed cancelled failed timed_out accepted execution starts result stored cancel error exceeds timeout Terminal states are final. The same circuit, backend version, parameters, shots and seed reproduce the same counts.
Fig. 1 How a job runs Every job enters through one service, which validates, records and dispatches it to a provider. Provider credentials exist only on the server side of the secret boundary, and every backend follows the same lifecycle. SVGPNG

Every result says where it came from.

Each result shows one of four provenance labels and the time of its last run. Reports count the labels and state plainly that no value comes from quantum hardware.

  • Sample dataFictional seed content. Its counts were generated by the bundled simulator from fixed seeds.
  • SimulatedComputed by a classical simulator, in the browser or on the server.
  • Self-reportedClaimed by a resource author and not checked.
  • Independently verifiedReproduced under an independent protocol. No result on the platform carries this label yet.

Industry demos

Six problems, one honest workflow.

Runnable, clearly labelled workflows with illustrative data and stated limitations. Each one ends with the quantum result next to an exact classical answer.

1 Illustrative data fictional or synthetic, downloadable as CSV Sample 2 Formulation the question as a cost, Hamiltonian or oracle 3 Quantum circuit parameterised gates; opens in the Playground 4 Run as a job browser · shared pool · Aurora-7 noisy profile Simulated 5 Classical baseline exact or brute force, on the same formulation Simulated 6 Labelled result metric + seed, versions, fingerprint per job Reproducible same formulation, solved exactly measured counts
Fig. 2 One workflow for every industry demo All six industry demos follow the same six stages. The formulation is also solved exactly on a classical computer, so every simulated quantum result is shown next to its baseline. SVGPNG
FinTech

Constrained portfolio selection with QAOA

Pick 2 of 4 fictional assets, balancing expected return against risk.

Baseline
Brute force over all 16 portfolios

QAOA (p = 1)4 qubits

Medical research

Exploratory cohort similarity with a quantum kernel

Compare a ZZ feature-map kernel with a classical RBF kernel on 12 synthetic samples.

Baseline
RBF kernel on the same two features

Fidelity quantum kernel2 qubits

Bioengineering

Searching a variant library with Grover's algorithm

Find enzyme variants that meet two design thresholds among 16 combinations.

Baseline
Random search and the exact success curve

Grover search4 qubits

Life sciences

Gene co-expression modules via Max-Cut

Split a 6-gene dissimilarity network into two modules with QAOA.

Baseline
Brute force over all 64 splits

QAOA Max-Cut6 qubits

Materials science

Quench dynamics of a transverse-field Ising chain

Trotterised time evolution of 4 spins compared with exact diagonalisation.

Baseline
Exact diagonalisation of the 16 x 16 Hamiltonian

Trotter dynamics4 qubits

Chemistry

H₂ ground-state energy with VQE

A one-parameter variational eigensolver on the textbook two-qubit hydrogen Hamiltonian.

Baseline
Exact (FCI) and Hartree-Fock energies

VQE2 qubits

Boundary

All datasets are fictional or synthetic and all results are classical simulations. Every problem is small enough to solve classically. The demos show the workflow and its limits; they make no medical, financial, scientific or performance claims.

Access and sign-in

Approved accounts, and a login path without RSA or elliptic curves.

New accounts stay pending until the super admin approves them and assigns a role. Every sign-in needs a password and a six-digit one-time code from an authenticator app.

TLS 1.3 at the edge · hybrid key establishment X25519MLKEM768 (ML-KEM-768, FIPS 203) · falls back to X25519 for older clients WHAT HAPPENS WHAT PROTECTS EACH STEP 1 Request access name · organisation · requested role · reason Argon2id, memory-hard + server pepper 2 Pending no access yet; the super admin is emailed account state: pending nothing is granted 3 Approval the super admin approves and assigns a role role enforced server-side entry in the audit log 4 First sign-in password, then enrol an authenticator app AES-256-GCM at rest 10 recovery codes 5 Every sign-in password + 6-digit one-time code HMAC code (RFC 6238) single use · rate limited 6 Session 12 h absolute · 2 h idle revocable on the server 256-bit random token stored as SHA-256 hash
Fig. 3 Access by approval, sign-in without RSA or elliptic curves An account goes from request to approval to a two-step sign-in. No step of the login path depends on RSA or elliptic-curve cryptography; the edge negotiates a hybrid post-quantum key exchange. SVGPNG

Six roles, enforced on the server.

A role is assigned on approval and can be changed by the super admin. A Viewer who tries to submit a job is refused by the server, not only by the interface.

Boundary

The certificate signature at the edge is still classical: public certificate authorities do not yet issue post-quantum certificates. Hybrid key establishment protects against recording traffic now and decrypting it later, not yet against an active attacker with a quantum computer.

Security overview

Roles and what each can do
RoleCan
Super AdminApprove or reject access requests, assign roles, suspend accounts, reset login codes and read the audit log
OwnerEverything in their workspace, including billing
AdminMembers, settings and backends; view billing
ResearcherProjects, jobs, publishing and reports
DeveloperJobs, API tokens, integrations and reports
ViewerRead-only; cannot submit jobs

Deployment

Running on OVHcloud, provisioned and shipped as code.

Terraform provisions the network, cluster, database, registry and storage. GitHub Actions tests, scans, builds and deploys; migrations run before every rollout.

Browser any client OVHCLOUD PUBLIC CLOUD Load balancer public address TLS 1.3 X25519MLKEM768 MANAGED KUBERNETES · private network Caddy edge Let's Encrypt · PQ TLS qubithub-app web + API qubithub-app web + API sticky cookie migrate Job on every deploy db-backup CronJob nightly pg_dump non-root · read-only root · only Caddy reaches the app Managed PostgreSQL 17 HA · point-in-time recovery Object Storage versioned · encrypted CA-verified TLS private endpoint backups Private registry signed image pull GitHub Actions CI · scans · deploy push image kubectl apply: secrets, migrations, rollout terraform apply: network, cluster, database, registry, storage
Fig. 4 Production deployment on OVHcloud QubitHub runs on OVHcloud Public Cloud: a load balancer in front of a Caddy edge and the application on Managed Kubernetes, with Managed PostgreSQL and Object Storage behind a private network. GitHub Actions builds, scans, provisions and deploys. SVGPNG

Edge

Caddy terminates TLS 1.3 with the hybrid X25519MLKEM768 key exchange and falls back to X25519 for clients without post-quantum support.

Workloads

Non-root containers with a read-only root filesystem and all capabilities dropped. Network policies let only the edge reach the application.

Data

Managed PostgreSQL 17 on a private endpoint with daily backups and point-in-time recovery, plus nightly dumps to versioned, encrypted object storage.

Pipeline

Lint, type checks, tests against a real PostgreSQL, container and dependency scans, CodeQL analysis and a software bill of materials with every release.

What is real today

What runs for real, and what is simulated or sample data.

What runs for real and what is simulated or fictional
ComponentTodayNeeded for production use
Circuit simulationReal classical state-vector simulation of up to 20 qubits, with seeded samplingHigh-performance simulators for larger circuits
Quantum hardwareNone. Aurora-7 and Kestrel-27 are fictional device profiles with an approximate noise modelA provider SDK and credentials in the server-side gateway
Accounts and rolesReal accounts: approval, password and one-time code, roles enforced on the serverIn place
Catalog and statisticsFictional seed data, labelled as sample or self-reportedA catalog service and storage
Queues and failuresSimulated by a mock provider, labelled as suchProvider status interfaces
BillingNot configured. Nothing can be purchased or chargedA payment provider with server-side checkout

Where it goes next.

  • Live

    The platform at qubithub.io: catalog, Playground, job API, industry demos, reports and real accounts.

  • Now

    Closed beta: every account is approved by hand and given a role.

  • Planned

    A first hardware provider, connected through the job API gateway.

  • Planned

    Premium Business for teams, once billing is configured.

Planned items are intentions, not commitments, and carry no date.

Plans

Free for the community, Premium for teams.

Free

No charge

Learn, experiment and publish in the open.

  • Unlimited runs on the in-browser simulator
  • 100 managed jobs per month on shared demo backends
  • Public projects, starter workflows and industry demos
  • Job summaries with CSV and JSON export
Boundary

Billing is not configured. Plans and quotas are built and shown for illustration; no payment details are collected and nothing is charged.

Run your first circuit on QubitHub

Request access and say which role you need. Every account is approved by hand before the first sign-in.