Planned feature
This feature is not available yet. Here is what is planned, so you can tell whether it will cover your need — and tell us if it will not.
Status — design settled
Planned availability — server mode only
In short
Launching a real Shiny, Streamlit, Dash or Gradio app from the project’s code, and using it in a Linkr tab — never touching a port number or opening a terminal on the side. The app would run in its own process, so it would not block your coding session.
The need
An interactive app remains the right tool for some things: a review form, a score simulator, a bespoke explorer that neither a dashboard nor a notebook replaces.
Today, launching one from Linkr does not work. A shiny::runApp() run in the IDE blocks the session until the execution timeout interrupts it, after two minutes — and the IDE with it. The only current answer is to leave Linkr, run the app on your own machine, and handle data access yourself.
Worth knowing right now
Do not launch a web app from the IDE: it will occupy your session without ever displaying, until the automatic interruption. That is precisely what this feature exists to fix.
What is planned
Launching from the Run button
A Run as web app entry would appear in the Run button’s menu when the open file looks like an app — an app.R, a ui.R, or a script importing Streamlit, Dash, Gradio, Panel or Marimo.
For cases not recognized, a Custom command option would let you supply your own command line.
The app in a tab
It would open as an IDE tab with the app displayed inside, a status pill — starting, ready, failed — Restart and Stop buttons, access to the logs when something goes wrong, and the option of opening it in a separate window.
Closing the tab would not stop the app: it would stay listed in the jobs panel, where it can be stopped.
Without blocking your work
This is the central requirement. The app would run in its own process, separate from your R and Python sessions. Your console stays available, your variables are intact, and you can keep coding while the app runs.
Server mode only
A browser-mode installation has no process to spawn: the feature cannot exist there. See Deployment modes.
What is already settled
The app will not be shareable by link, at least at first. The reason is security: because the app displays inside Linkr, its code would have access to the sign-in token of whoever views it. Until a strict separation is in place, only the person who launched the app will be able to reach it.
It is an accepted limitation: better a restricted feature than a sharing mechanism that exposes credentials.
An app that ignores the path Linkr gives it will not work. Apps that build absolute URLs in hard-coded form, without regard for the address they are served at, will not be supported.
What is not settled yet
Several design points remain open. They are listed here because your view can still tip them.
Several apps at once?
Should two apps be allowed on one project, or is that always a sign one was left running? A limit of two simultaneous apps per user is under consideration.
Restart on save
Should the app restart when a file is saved, or should the framework handle its own reloading, with Linkr offering only a button?
An app as a dashboard widget
Embedding a Shiny app in a dashboard is out of scope for now: it depends on the security separation mentioned above.
Memory usage
No memory or CPU ceiling is planned for now — a greedy app could weigh on the instance. Coding sessions have the same gap today.
Some values are being considered without being fixed: automatic shutdown after an hour with no use, and one minute for an app to start before it is declared failed.
In the meantime
- IDE — writing the app’s code, and running it other than as a web app.
- Dashboards — which already cover many interactivity needs.
- Code widgets — R or Python producing a display inside a dashboard.