Lagrange: Operating Italy's First Publicly-Accessible Quantum Computer for Research and Education

This paper presents the design, implementation, and nine-month operational success of a modular middleware stack that enables the first publicly accessible quantum computer in Italy, Lagrange, to support research, education, and commercial use through vendor-agnostic project management, billing, and fair-usage policies.

The Gist

Imagine you just bought a very expensive, incredibly rare, and powerful super-car. It's the first one of its kind in your country. You want to let your friends, your university students, and even paying customers drive it. But there's a problem: the car came with a key that only turns the engine on. It doesn't have a dashboard to track who drove, how long they drove, or how much gas they used. It doesn't have a ticket booth to charge people, and it doesn't have a traffic cop to stop one person from hogging the car for the whole day while others wait.

That is exactly the situation the Lagrange project faced in Italy. They acquired a cutting-edge Quantum Computer (a machine that solves problems using the weird laws of physics to be millions of times faster than normal computers for specific tasks). But the machine arrived "naked"—it had no software to manage who gets to use it, how much it costs, or how to keep things fair.

This paper is the story of how the team built the "Traffic Cop and Dashboard" (the middleware) to turn that raw machine into a shared, public resource.

Here is the breakdown of what they did, using simple analogies:

1. The Problem: The "Wild West" Quantum Machine

When the machine (an IQM Spark) arrived, it was like a public library with no librarian.

• The Issue: Anyone with a key could walk in, stay as long as they wanted, and use as many books as they wanted. There was no way to charge a research grant for the time used, no way to stop a student from printing 1,000 pages while others couldn't print a single one, and no way to schedule a specific time for a class.
• The Goal: They needed a system where:
  • Researchers could be billed for their specific projects.
  • Students could use it during exams without crashing the system.
  • The Public could pay to use it.
  • Everyone could use it without needing to learn complex new rules.

2. The Solution: The "Magic Proxy" (Middleware)

Instead of trying to rewrite the car's engine (which would be dangerous and break the warranty), the team built a transparent glass wall between the users and the machine.

• The Invisible Gatekeeper: They created a software layer called the QC Gateway. Think of it as a super-smart concierge standing at the door.
  • When a user tries to send a job (a calculation) to the quantum computer, the concierge checks their ID.
  • The concierge checks their "budget" (do they have enough money in their project account?).
  • The concierge checks if the machine is already busy with a "reserved" VIP.
  • If everything is green, the concierge whispers to the machine, "Let this through," and then immediately forgets it happened.
• Why this is cool: The users (students and scientists) didn't have to change anything about how they write their code. They used the same tools they always used, just like driving a car with a new GPS system that you don't even notice is there.

3. The "Plugin" System: Lego Bricks for Different Machines

The team realized that one day, they might get a different brand of quantum computer (like a different model of car). They didn't want to build a whole new traffic system for every new machine.

So, they built their software like Lego.

• The Core: The main traffic rules (check ID, check budget, log the time) are the same for everyone.
• The Plugins: They created special "adapter bricks." If they get an IQM machine, they snap on the "IQM Brick." If they get an IBM machine later, they just swap in the "IBM Brick." The rest of the system doesn't even know the difference. This makes their system reusable for anyone else in the world.

4. The "Fairness" Rule: The Pizza Slicer

One of the biggest challenges was Fairness. If one student decided to run a massive calculation that would take 5 hours, they would block everyone else for the whole day.

The team implemented a "Pizza Slicer" rule:

• They set a limit on how many "slices" (shots/calculations) a single person can have "on the table" at once.
• If you have 5 slices waiting to be cooked, you can't order a 6th one until one is done.
• This ensures that even if one person is very busy, there is always room for others to get a slice of the pizza.

5. The "Time Machine" for Data

Quantum computers are fragile. Sometimes they need to be recalibrated (like tuning a guitar). If you ran a calculation at 9:00 AM and the machine was tuned slightly differently at 10:00 AM, your results might be wrong.

The team built a Time Machine Archive:

• Every time a student or scientist runs a job, the system takes a "snapshot" of the machine's health and settings at that exact second.
• They save the result and the snapshot together.
• Years later, if someone asks, "Why did this result look weird?", they can look at the snapshot and say, "Ah, the machine was slightly out of tune that day."

6. The Result: A Classroom Revolution

The paper highlights a truly unique achievement: Students are using this real, expensive quantum computer during their final exams.

• Before: Students learned quantum computing by simulating it on a regular laptop (like playing a flight simulator).
• Now: They are flying the real plane. During exams, they write code, hit "run," and the real quantum computer executes it.
• The Stats: In just a few months, the system handled 240,000 jobs (calculations) and ran for over a week straight. It was available 98% of the time, which is amazing for such a delicate machine.

The Big Picture

This paper isn't just about a computer; it's about infrastructure. It proves that you can take a fragile, expensive piece of science hardware and turn it into a reliable, shared utility—like electricity or Wi-Fi—that universities, researchers, and students can all use fairly and easily.

They built the "operating system" for the future of on-site quantum computing, showing the world how to manage these machines without locking them away in a secret lab.

Technical Summary

1. Problem Statement

The deployment of on-premises superconducting quantum computers (e.g., IQM, IBM, Rigetti) at research institutions faces a critical gap: while vendors provide the hardware and basic authentication, they often lack the necessary resource management, billing, and multi-tenant orchestration layers required for shared institutional use.

• The Gap: Without a management stack, a shared quantum computer operates like a single-user lab instrument. Any user with credentials can submit unlimited jobs, making it impossible to:
  • Attribute costs to specific funded projects (billing).
  • Enforce fair usage policies or quotas.
  • Manage reservations or time-slot allocations between different partner institutions.
  • Provide long-term data persistence independent of the vendor's internal storage.
• Limitations of Existing Solutions: Commercial cloud platforms (IBM Quantum, AWS Braket) solve these issues but are closed-source, cloud-only, and cannot be deployed on-premises. Academic deployments often focus on hardware benchmarking rather than the administrative software layer, and existing solutions lack portability across different vendors.

2. Methodology and System Architecture

The authors developed Lagrange, a modular, Python-based middleware stack designed to sit between users and the IQM Spark quantum computer. The system is built on two core design principles: Transparency (users interact with unmodified vendor clients) and Extensibility (separation of vendor logic from site policies).

Key Architectural Components:

• QC Gateway (Middleware):
  • Implemented as a transparent reverse proxy using FastAPI.
  • Intercepts all IQM REST API calls without modifying the request/response schemas.
  • Workflow: Validates OIDC tokens $\rightarrow$ Checks role-based access $\rightarrow$ Queries backend for budget/reservation status $\rightarrow$ Enforces concurrency limits (via Redis) $\rightarrow$ Forwards request to the IQM server.
  • Fail-Open Design: If non-critical services (e.g., Redis, object storage) are down, the proxy continues to forward jobs to ensure researchers are not blocked, with retries handled asynchronously.
• Plugin Architecture:
  • Vendor Plugins: Handle vendor-specific logic (parsing IQM API payloads, polling job status, handling calibration data). This allows the core middleware to be reused with different hardware backends (e.g., Rigetti, IBM) by simply swapping the plugin.
  • Site Plugins: Encapsulate site-specific policies (budget checking, reservation logic, billing reporting). This allows the same core to be deployed at different institutions with different administrative rules.
• Backend API & Database:
  • Manages persistent state (Organizations, Projects, Users, Reservations, Budgets) using PostgreSQL.
  • Handles the logic for authorizing jobs based on project budgets and time-slot reservations.
• Storage Layer:
  • MinIO (S3-compatible): Stores submitted circuits, job results, and calibration reports long-term, decoupling data persistence from the vendor's internal storage.
  • Redis: Enforces per-user concurrency limits (fairness) via atomic counters.
• Authentication & Federation:
  • Uses a self-hosted Keycloak instance as the central Identity Provider (IdP).
  • Federates with partner institutions (Politecnico di Torino, INRiM) via SAML and OIDC, allowing users to log in with institutional credentials without manual account provisioning.

3. Key Contributions

• First Multi-Tenant On-Premise Quantum Stack in Italy: Lagrange is the first system in Italy to enable shared access to a quantum computer for multiple institutions (LINKS, Politecnico, INRiM) with heterogeneous billing models (project-based budgets, time-slot reservations, and best-effort access).
• Transparent Integration: The system allows researchers and students to use standard, unmodified Python libraries (Qiskit, Cirq, Qrisp) and the official iqm-client SDK. No code changes or SSH access to a head node (unlike SLURM-based approaches) are required.
• Novel Educational Integration: The system supports a unique use case where students access the real quantum hardware during formal university examinations and regular lectures, a practice the authors claim is unique in Europe.
• Modular Plugin Design: The separation of vendor-specific logic from site-specific policies creates a reusable blueprint for other institutions deploying on-premises quantum hardware.
• Comprehensive Observability: The stack includes a dual-purpose monitoring system (Grafana/Prometheus) that mirrors machine telemetry (qubit fidelity, cryostat health) and monitors the software stack itself.

4. Results and Operational Experience

Since entering production in September 2025, the system has demonstrated high reliability and scalability:

• Usage Volume: Processed over 240,000 quantum jobs totaling more than one week of QPU execution time.
• Uptime: Maintained >98% uptime, a significant achievement for on-premises hardware subject to cryogenic instability and recalibration.
• User Base: Served over 500 users, including more than 350 students from the Quantum Engineering Master's program.
• Educational Impact: Successfully integrated into advanced courses (Quantum Computing, Qubit Electronics, Hardware Design), allowing students to run experiments and exams directly on the hardware.
• Resilience: The system handled high-concurrency scenarios (e.g., dozens of students submitting jobs simultaneously during exams) without architectural changes.

5. Significance

The Lagrange project demonstrates that small-scale quantum computers can be operated as shared, multi-tenant research infrastructure with service management levels comparable to High-Performance Computing (HPC) facilities.

• Bridging the Gap: It solves the "last mile" problem of on-premises quantum deployment by providing the necessary administrative, billing, and fairness layers that vendors do not supply.
• Educational Paradigm Shift: By enabling direct hardware access for students during exams, it moves quantum education beyond simulation, fostering a deeper understanding of noise, hardware constraints, and real-world system behavior.
• Reusability: The open-source nature of the QC Gateway and the plugin architecture provide a scalable model for the global community of institutions planning similar on-premises deployments, reducing the barrier to entry for shared quantum resources.

In conclusion, the paper validates that a modular, transparent middleware approach is essential for the sustainable operation of shared quantum hardware, enabling both rigorous research and innovative educational applications.