R package INLA on Posit Connect Cloud — GLIBC / MKL binary compatibility

Posit Professional & Hosted Products Connect Cloud
1

I'm deploying a Shiny app (built with golem) on Posit Connect Cloud that depends on the INLA R package (https://www.r-inla.org/), which is not on CRAN and distributes precompiled Linux binaries rather than compiling from source.

Context:

  • Connect Cloud content runs on Ubuntu 22.04.
  • INLA's own binary-selection mechanism (inla.binary.install() / inla.call) is meant to auto-detect the OS and download the matching precompiled binary at install/runtime.
  • In our testing, the default binary resolved for our INLA version did not match Ubuntu 22.04's GLIBC version, causing a "GLIBC_x.xx not found" error when running inla().
  • As a workaround, at app startup we now explicitly download the Ubuntu-22.04.5-specific build from Index of /Linux-builds/ and point INLA to it via inla.setOption(inla.call = ...).
  • Separately, the MKL-optimized binary variant (inla.mkl.run) causes a segmentation fault in Connect Cloud's environment, so we force the standard (non-MKL) binary and set INLA_DISABLE_MKL=TRUE.

Questions:

  1. Is this GLIBC/binary-selection issue with INLA on Connect Cloud something you've seen before, and is there a supported/recommended way to pin a specific system-compatible binary at deploy time (e.g., via manifest.json, Additional_repositories, or another mechanism) rather than downloading and patching the binary at runtime in app_server()?
  2. Is the MKL segmentation fault a known limitation of Connect Cloud's virtualized/containerized environment? Is there a way to influence which binary variant gets installed during the build step, before the app starts serving sessions?
  3. Currently our workaround runs inside app_server(), which executes on every new session rather than once per deployment. Is there a recommended hook (during build, or once per R process rather than per session) for this kind of one-time system-level setup on Connect Cloud?

Any guidance — including whether this is simply not a supported use case on Connect Cloud — would help us decide whether to continue down this path or look at an alternative deployment target.