feature: Native R Language Support as a First-Class Script Block

[Ohkyusung]

Feature Request: Native R Language Support as a First-Class Script Block

Summary

We are deploying Windmill as the core MLOps orchestration platform for a Virtual Metrology (VM) system at a major semiconductor/display manufacturer. R is the dominant language used by their process engineers and data scientists. The lack of native R support in Windmill is currently the single biggest blocker to enterprise adoption.

We are requesting native R language support — not just Bash-wrapped Rscript execution, but a first-class R script block with IDE-level features comparable to what Windmill already offers for Python and TypeScript.

Context & Business Case

Who We Are

We are an IT solutions provider building smart factory systems (FDC, APC, SPC, Virtual Metrology) for semiconductor, display, and battery manufacturers. We are currently architecting a Virtual Metrology system targeting MLOps Level 3 maturity (automated model deployment with CI/CD pipelines, model registry, continuous monitoring, and automated retraining triggers).

Why Windmill

We evaluated Airflow, Prefect, and Windmill. Windmill stood out for its:

• Built-in Web IDE with LSP support per language
• Auto-generated UI for script parameters
• Flow editor for DAG-based orchestration with sub-20ms overhead
• Self-hostable, air-gapped deployment capability (critical for semiconductor fabs)
• Enterprise RBAC, SSO, and audit logging

We chose Windmill as our MLOps backbone. However, R support is a critical gap.

Why R Matters in This Domain

In semiconductor and display manufacturing, R is deeply embedded in the engineering workflow:

• Statistical Process Control (SPC): Process engineers use R for control chart analysis, Cp/Cpk calculations, and distribution fitting
• Virtual Metrology models: Many existing VM models are written in R using packages like caret, randomForest, xgboost, and custom in-house libraries
• R2R (Run-to-Run) control: Feedback/feedforward control algorithms often originate as R scripts in RStudio
• Regulatory & validation: Rewriting validated R models in Python solely due to platform limitations introduces re-validation overhead and risk

Our customer's engineering team has hundreds of existing R scripts powering their current VM and process control pipelines. Asking them to rewrite everything in Python is not viable — it would add months of migration effort and introduce regression risk in a domain where model accuracy directly impacts yield and product quality.

Enterprise Subscription Potential

This engagement involves a Fortune Global 500 display manufacturer. Native R support in Windmill could be the deciding factor for them to commit to an Enterprise plan. The deployment would span multiple fab lines, with 50+ engineers using Windmill daily for model training, validation, and deployment workflows. This is not a one-off request — we see the same R dependency across multiple customers in the semiconductor and battery industries.

What We're Requesting

Tier 1: Core R Script Block (Essential)

• Native R executor (Rscript runtime) as a first-class language option in the script editor, flow steps, and app inline scripts
• Typed input/output signature — R function parameters parsed and exposed as auto-generated UI inputs (similar to Python's type hints → UI mapping)
• Dependency management — renv.lock or equivalent for reproducible R package installation, with worker-level caching (similar to how Windmill caches pip and npm dependencies)
• Resource/variable access — Windmill client library (or REST helper) for R to fetch resources, variables, and state from the Windmill workspace
• Result handling — structured JSON return values from R scripts that downstream flow steps can consume

Tier 2: IDE Experience (Highly Desired)

• LSP integration — R Language Server (languageserver package) connected via WebSocket, providing autocomplete, signature help, hover docs, and diagnostics in the Web IDE
• Inline execution & debugging — ability to run R code cell-by-cell or line-by-line within the editor (similar to RStudio / Jupyter R kernel experience), with output/plot rendering in the preview pane
• Plot rendering — capture and display R plot output (base R, ggplot2) as images in the job result view

Tier 3: Advanced (Nice to Have)

• Dedicated worker tag for R-heavy workloads (pre-installed R + common packages to avoid cold-start)
• R ↔ Python interop within a single flow — e.g., pass a data frame from a Python step to an R step via Arrow/Parquet serialization through S3
• Rmarkdown rendering as a job output type

Current Workaround & Its Limitations

We are currently wrapping R execution in Bash steps:

Rscript -e "source('/path/to/script.R'); main(arg1='$1', arg2='$2')"

This works for simple cases but has significant limitations:

• No LSP, no autocomplete, no syntax highlighting for R in the editor
• No typed parameter UI — everything is a raw string
• Dependency management is manual (must pre-install packages in the Docker image)
• No structured output — must manually parse stdout
• Debugging is painful — errors surface as raw stderr text with no line mapping
• Cannot leverage Windmill's dependency caching or resource system from R

Reference

In Issue #4102, @rubenfiszel mentioned:

"Other languages we intend to support are R and Rust"

Rust has since been added as a native language. We would like to advocate for R to be next in line, backed by a concrete enterprise deployment that depends on it.

Summary

Aspect	Detail
Industry	Semiconductor / Display Manufacturing
Use Case	Virtual Metrology, SPC, R2R Control
Target MLOps Level	Level 3 (Automated Model Deployment)
Scale	50+ engineers, multiple fab lines
Subscription Impact	Enterprise plan adoption contingent on R support
Migration Alternative	Rewriting R → Python is not viable (validation cost, regression risk)

We're happy to collaborate on design, testing, and feedback. If there's an RFC or beta program for new language support, we'd love to participate.

# Feature Request: Native R Language Support as a First-Class Script Block

Summary

We are deploying Windmill as the core MLOps orchestration platform for a Virtual Metrology (VM) system at a major semiconductor/display manufacturer. R is the dominant language used by their process engineers and data scientists. The lack of native R support in Windmill is currently the single biggest blocker to enterprise adoption.

We are requesting native R language support — not just Bash-wrapped Rscript execution, but a first-class R script block with IDE-level features comparable to what Windmill already offers for Python and TypeScript.

Context & Business Case

Who We Are

We are an IT solutions provider building smart factory systems (FDC, APC, SPC, Virtual Metrology) for semiconductor, display, and battery manufacturers. We are currently architecting a Virtual Metrology system targeting MLOps Level 3 maturity (automated model deployment with CI/CD pipelines, model registry, continuous monitoring, and automated retraining triggers).

Why Windmill

We evaluated Airflow, Prefect, and Windmill. Windmill stood out for its:

• Built-in Web IDE with LSP support per language
• Auto-generated UI for script parameters
• Flow editor for DAG-based orchestration with sub-20ms overhead
• Self-hostable, air-gapped deployment capability (critical for semiconductor fabs)
• Enterprise RBAC, SSO, and audit logging

We chose Windmill as our MLOps backbone. However, R support is a critical gap.

Why R Matters in This Domain

In semiconductor and display manufacturing, R is deeply embedded in the engineering workflow:

• Statistical Process Control (SPC): Process engineers use R for control chart analysis, Cp/Cpk calculations, and distribution fitting
• Virtual Metrology models: Many existing VM models are written in R using packages like caret, randomForest, xgboost, and custom in-house libraries
• R2R (Run-to-Run) control: Feedback/feedforward control algorithms often originate as R scripts in RStudio
• Regulatory & validation: Rewriting validated R models in Python solely due to platform limitations introduces re-validation overhead and risk

Our customer's engineering team has hundreds of existing R scripts powering their current VM and process control pipelines. Asking them to rewrite everything in Python is not viable — it would add months of migration effort and introduce regression risk in a domain where model accuracy directly impacts yield and product quality.

Enterprise Subscription Potential

This engagement involves a Fortune Global 500 display manufacturer. Native R support in Windmill could be the deciding factor for them to commit to an Enterprise plan. The deployment would span multiple fab lines, with 50+ engineers using Windmill daily for model training, validation, and deployment workflows. This is not a one-off request — we see the same R dependency across multiple customers in the semiconductor and battery industries.

What We're Requesting

Tier 1: Core R Script Block (Essential)

• Native R executor (Rscript runtime) as a first-class language option in the script editor, flow steps, and app inline scripts
• Typed input/output signature — R function parameters parsed and exposed as auto-generated UI inputs (similar to Python's type hints → UI mapping)
• Dependency management — renv.lock or equivalent for reproducible R package installation, with worker-level caching (similar to how Windmill caches pip and npm dependencies)
• Resource/variable access — Windmill client library (or REST helper) for R to fetch resources, variables, and state from the Windmill workspace
• Result handling — structured JSON return values from R scripts that downstream flow steps can consume

Tier 2: IDE Experience (Highly Desired)

• LSP integration — R Language Server (languageserver package) connected via WebSocket, providing autocomplete, signature help, hover docs, and diagnostics in the Web IDE
• Inline execution & debugging — ability to run R code cell-by-cell or line-by-line within the editor (similar to RStudio / Jupyter R kernel experience), with output/plot rendering in the preview pane
• Plot rendering — capture and display R plot output (base R, ggplot2) as images in the job result view

Tier 3: Advanced (Nice to Have)

• Dedicated worker tag for R-heavy workloads (pre-installed R + common packages to avoid cold-start)
• R ↔ Python interop within a single flow — e.g., pass a data frame from a Python step to an R step via Arrow/Parquet serialization through S3
• Rmarkdown rendering as a job output type

Current Workaround & Its Limitations

We are currently wrapping R execution in Bash steps:

Rscript -e "source('/path/to/script.R'); main(arg1='$1', arg2='$2')"

This works for simple cases but has significant limitations:

• No LSP, no autocomplete, no syntax highlighting for R in the editor
• No typed parameter UI — everything is a raw string
• Dependency management is manual (must pre-install packages in the Docker image)
• No structured output — must manually parse stdout
• Debugging is painful — errors surface as raw stderr text with no line mapping
• Cannot leverage Windmill's dependency caching or resource system from R

Reference

In [Issue #4102](#4102), @rubenfiszel mentioned:

"Other languages we intend to support are R and Rust"

Rust has since been added as a native language. We would like to advocate for R to be next in line, backed by a concrete enterprise deployment that depends on it.

Summary

Aspect	Detail
Industry	Semiconductor / Display Manufacturing
Use Case	Virtual Metrology, SPC, R2R Control
Target MLOps Level	Level 3 (Automated Model Deployment)
Scale	50+ engineers, multiple fab lines
Subscription Impact	Enterprise plan adoption contingent on R support
Migration Alternative	Rewriting R → Python is not viable (validation cost, regression risk)

We're happy to collaborate on design, testing, and feedback. If there's an RFC or beta program for new language support, we'd love to participate.

[rubenfiszel]

Hi @Ohkyusung ,

Thanks for choosing Windmill.

We can add R support, we can actually do it in a week but we'd like to talk to the customer that would acquire the license were we to satisfy his requirements to get more context. You can send email at sales@windmill.dev

[rubenfiszel]

I took a stab at doing a v0 helped with claude and it's pretty decent: #8263
There a bit more work needed to wrap this up if we decided to pursue this but I'm very confident in our ability to deliver this under a week:

[Ohkyusung]

Hi @rubenfiszel,

Thank you for the incredibly fast response — and the v0 prototype looks great!
awesome!!

To give you a clearer picture of our requirements:

1. R + Python mixed workflows: Our Virtual Metrology pipelines typically involve Python steps for data extraction/preprocessing and R steps for statistical modeling (SPC, VM model training). Being able to chain R and Python steps within a single Flow — with structured data passing between them (e.g., JSON or data frame serialization) — is essential.

2. Multiple R version support: Our customer's engineering teams maintain models across different R versions (e.g., R 3.6.x for legacy validated models, R 4.x for new development). The ability to configure and switch between R versions per script or per worker would be very valuable.

3. Air-gapped on-premise deployment: Our customer operates in a semiconductor fab environment with no external network access. All dependencies (R packages, base images, etc.) must be pre-installed or served from an internal mirror. It would be helpful if the R worker image supports pre-bundled packages and/or a configurable local CRAN mirror (e.g., Posit Package Manager or miniCRAN).

Once R support is released, we'll thoroughly test it against our actual VM pipeline scenarios. If the results are positive — especially around R/Python interop and air-gapped operability — I'm very confident we can make a strong case to our customer for adopting the Enterprise plan.

Really impressed by the speed and quality of the v0. Looking forward to what's next!

[rubenfiszel]

Hi,

we can do the above but we will need to talk to the end-customer and them to start an official trial for enterprise.

[Ohkyusung]

Hi @rubenfiszel,

Thanks for being open to this. Let me share where we are so you have the full picture.

We're currently in the pre-proposal stage for this project — meaning we're still preparing our technical architecture and solution proposal to present to the end-customer. The project hasn't been officially awarded yet.

Here's the reality of our situation:

• The customer's point of contact on their side is a manufacturing/process domain expert, not an IT decision-maker. They are not fluent in English and would not be comfortable in a direct technical or sales conversation with Windmill.
• Since we're still in the proposal phase, it's too early for us to connect the end-customer with a vendor for an enterprise trial. That kind of introduction becomes appropriate once the project is approved and the architecture is finalized.

That said, having R support in Windmill significantly strengthens our proposal. If we can demonstrate R + Python mixed workflows running on Windmill during our internal PoC, it becomes a compelling differentiator — and makes the case for Enterprise adoption much easier once the project kicks off.

So here's what I'd like to propose:

1. If R support could be made available in the Community Edition (even as an experimental/beta feature), we can immediately start building PoC pipelines with it.
2. A successful PoC directly increases the probability of this project being approved with Windmill as the core platform.
3. Once the project is awarded, we would then formally introduce the end-customer and proceed with Enterprise licensing.

I understand this is a bit of a chicken-and-egg situation, but from our experience, being able to show a working demo is the single most effective way to get budget approval from manufacturing customers.

Would this approach work for you? Happy to discuss further

[rubenfiszel]

Hi @Ohkyusung , unfortunately, we have other big priorities at the moment and adding official support for a language is a lot of efforts that we can't afford right now with so many maybe, even in beta/experimental mode. You can make a hacky solution for now and let them know that if a budget is approved and they're ready to start a trial with us with a budget in mind that they share with us, we're happy to invest in that direction. We may be able to add support for R in the next 6 months however even without that nudge so maybe you can delay the pilot.

[Ohkyusung]

Hi @rubenfiszel,

Totally understand — no rush at all.

On our side, the project still needs to go through investment approval, infrastructure procurement, and development before we actually need R in production. That process alone will take 6+ months.

So the priority can be as low as you need it to be. The only thing that would really help is if R support lands sometime within this year (2026) — that would align perfectly with our timeline.

In the meantime, we'll continue working with the Bash workaround and keep building out the rest of our architecture on Windmill.

Thanks again for being upfront about it — really appreciate it.

[rubenfiszel]

sounds good!