Launching SiLA 2 Studio: OpenAPI to SiLA 2 driver in two minutes

SiLA 2 Studio is live at sila2.qpillars.com. Drop an OpenAPI 3.0 or 3.1 spec, get back a runnable Python SiLA 2 driver scaffold - server, gRPC servicer, Feature Definition files, Dockerfile, tests. The hosted tool is free. The transformation library underneath, openapi-to-sila2, is open source. No sign-up, no install, no credit card.

Why we built it

Every instrument vendor we have worked with reaches the same wall. The SiLA 2 standard exists, the Python SDK exists, but writing a SiLA 2 driver from scratch is a multi-week senior-engineer project. You learn the XSD schema for Feature Definitions, you hand-write the FDL, you run the SiLA code generator, you wire the gRPC servicer, you fix the type mismatches between your instrument's data model and SiLA's, and only then do you start the integration work that actually matters.

We watched teams burn a month on scaffolding that should have been generated. So we generated it.

What you get

You upload an OpenAPI spec. Studio parses it, maps it to SiLA 2 concepts, and offers a review screen where you tweak names, exclude operations, and mark properties as observable. You click generate. A few seconds later you download a zip with this layout:

<project_slug>/
  features/<Feature>.xml
  <python_package>/
    __init__.py
    __main__.py
    server.py
    feature_implementations/
      <feature>_impl.py   <- you fill these in
    generated/
      client.py
      <feature>/...       <- do not hand-edit; auto-regenerated
  tests/test_driver.py
  Dockerfile
  docker-compose.yml
  pyproject.toml
  README.md

The feature_implementations/ files are deliberate stubs that raise NotImplementedError. That is the only code only you can write - the call to your real instrument SDK, HTTP client, serial port, or whatever the hardware speaks. Everything else - discovery, gRPC plumbing, type marshalling, the server entry point - is already wired.

Run it locally:

uv sync
uv run python -m <package> --insecure -p 50051

A SiLA 2 server is now listening on port 50051. Any SiLA-aware client can discover and call it.

The mapping rules

OpenAPI and SiLA 2 are not isomorphic. The Studio's transformation layer makes opinionated choices that we have validated against real instrument APIs:

• One OpenAPI tag -> one SiLA 2 Feature. Tags are the natural grouping in OpenAPI; Features are the natural grouping in SiLA 2.
• GET without parameters -> Property. The verb pattern matches: a sensor reading, a status value.
• POST / PUT / DELETE -> Command. Anything that mutates state becomes an invokable command.
• GET with parameters -> Command. Parameterised reads are operations, not properties.
• 2xx response schemas -> Command response types. XSD-typed.
• 4xx / 5xx response schemas -> Defined Execution Errors. Surfaced as typed SiLA errors.

The full ruleset is documented in openapi-to-sila2 - the open-source library that does the actual transformation. The Studio is the polished, hosted front-end; the library is what you reach for when you need full control or want to wire generation into CI.

What the hosted tool gives you over the library

You can pip install openapi-to-sila2 today and run it locally. So why does the hosted Studio exist?

• No Python toolchain required. Drop a file, click a button. Useful for evaluators, scientists, and anyone who is not set up to run Python.
• Visual review of the proposed mapping. The library returns FDLs; the Studio shows the feature breakdown with command and property counts before you generate.
• Override layer. Rename, exclude, mark observable - all in the browser, before generation. No code edits, no spec edits, just decisions.
• Reproducible bundles. Same spec -> same SHA-256. Useful when you want to confirm that a regenerated driver is byte-identical to what shipped.
• Two-minute iteration loop. Upload, tweak, regenerate. The library version takes longer because of CLI overhead and local tooling setup.

For one-off scaffolding, the Studio. For pipeline integration, the library. Same engine.

What the scaffold is not

The Studio gets you 80% of the way to a working driver. The remaining 20% is the integration that only your team can write - and the productionisation that turns a scaffold into something you can defend in a GxP audit.

The scaffold does not include:

• Validation evidence (IQ/OQ documentation)
• Audit trails or 21 CFR Part 11 compliance helpers
• Role-based access control beyond SiLA's LockController feature
• Observability beyond basic logging
• Vendor SDK integrations - those are unique to each instrument

That gap is the engagement we build with customers. The Studio is the starting point; the production-grade SiLA 2 driver is the destination. If you are at that destination, book a technical call.

Privacy and data handling

Specs are stored as objects in Google Cloud Storage with a 24-hour lifecycle, scoped to the session that generated them. Nothing is written to a database, nothing is forwarded to third parties, and the spec contents never appear in application logs. Email submissions on the lead-gate form go to sila2@qpillars.com via Resend. The full data flow is documented on the Studio's Privacy page.

What we shipped

SiLA 2 Studio is a Next.js 16 / FastAPI / Python application running on Google Cloud Run. Behind a Global External HTTPS Load Balancer with a managed certificate. GCS-backed object storage with signed URLs for downloads. Resend for transactional email. The Studio's front-end proxies all backend traffic, so end users see only sila2.qpillars.com - the backend URL is never exposed to the browser. CD pipeline on GitHub Actions; every push to main hits production.

If you want the architectural details, browse the SiLA 2 Studio repository - it is public.

Try it

sila2.qpillars.com. Open in a tab, paste an OpenAPI URL or drop a file, click through, download the zip. If your first generation takes longer than two minutes, tell us at sila2@qpillars.com and we will fix it.

Key Takeaways

• What it is: A hosted tool that turns an OpenAPI spec into a runnable Python SiLA 2 driver scaffold.
• Where it lives: sila2.qpillars.com (free, no sign-up).
• What it generates: Full Python package - server.py, __main__.py, feature_implementations/ stubs, generated/ base classes, Dockerfile, tests/, pyproject.toml.
• What you still write: The body of each NotImplementedError stub - the call to your instrument SDK.
• Open source: The transformation library, openapi-to-sila2, is on GitHub.
• Privacy: 24-hour object lifecycle on GCS. No database. Specs never logged.

FAQ

What is SiLA 2 and why does it matter?

SiLA 2 (Standardization in Lab Automation) is the open standard for instrument-to-software communication in life-science labs. It defines a gRPC contract between instruments and the orchestration software that drives them - LIMS, schedulers, AI agents. A SiLA 2 driver makes your instrument addressable from any SiLA-aware client without per-vendor adapters.

Does the generated driver work out of the box?

The scaffold is wired - server, discovery, gRPC servicer, types, clients. The per-command method bodies are NotImplementedError stubs. That is intentional: only you know how to talk to your instrument. The Studio gets you 80% of the way; the remaining 20% is the integration only your team can write.

How does Studio differ from writing FDL files by hand?

Hand-writing an FDL takes a senior engineer two to four weeks per instrument family - learning the XSD schema, the type system, the gRPC mapping rules. Studio collapses that to minutes by deriving the mapping from your existing OpenAPI spec.

Can I run this for a regulated environment?

The Studio generates the scaffold. Productionising a SiLA 2 driver for GxP/FDA workflows needs validation evidence, audit trails, role-based access, and observability that the scaffold does not bundle. That is the engagement we build with customers - the Studio is the starting point, not the finish line.

What happens to my OpenAPI spec after I upload it?

Stored as objects in Google Cloud Storage with a 24-hour lifecycle, scoped to the session. Nothing is written to a database, nothing is forwarded to third parties, spec contents never appear in application logs.

Related reading

• REST APIs and the SiLA 2 bridge - introducing openapi-to-sila2 - deep dive on the transformation library.
• How to connect AI agents to lab instruments with MCP - the other half of the integration story.
• MCP server on top of vendor SDKs - lessons from LiquidBridge - what we learned wrapping vendor SDKs.