deploy-shinyproxy
Deploy ShinyProxy for hosting multiple containerized Shiny applications. Covers ShinyProxy Docker deployment, application.yml configuration, Shiny app Docker images, authentication, container backends, usage tracking, and scaling. Use when hosting multiple Shiny apps behind a single entry point, needing per-app authentication and access control, deploying Shiny apps as isolated Docker containers, or scaling beyond single-app deployment with usage analytics and audit logging.
Best use case
deploy-shinyproxy is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Deploy ShinyProxy for hosting multiple containerized Shiny applications. Covers ShinyProxy Docker deployment, application.yml configuration, Shiny app Docker images, authentication, container backends, usage tracking, and scaling. Use when hosting multiple Shiny apps behind a single entry point, needing per-app authentication and access control, deploying Shiny apps as isolated Docker containers, or scaling beyond single-app deployment with usage analytics and audit logging.
Teams using deploy-shinyproxy should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/deploy-shinyproxy/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How deploy-shinyproxy Compares
| Feature / Agent | deploy-shinyproxy | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Deploy ShinyProxy for hosting multiple containerized Shiny applications. Covers ShinyProxy Docker deployment, application.yml configuration, Shiny app Docker images, authentication, container backends, usage tracking, and scaling. Use when hosting multiple Shiny apps behind a single entry point, needing per-app authentication and access control, deploying Shiny apps as isolated Docker containers, or scaling beyond single-app deployment with usage analytics and audit logging.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Deploy ShinyProxy
Deploy ShinyProxy to host multiple containerized Shiny applications with authentication and usage tracking.
## When to Use
- Hosting multiple Shiny apps behind a single entry point
- Need per-app authentication and access control
- Deploying Shiny apps as isolated Docker containers
- Scaling beyond single-app deployment (shinyapps.io or standalone Docker)
- Requiring usage analytics and audit logging
## Inputs
- **Required**: One or more Shiny apps to deploy
- **Required**: Server with Docker installed
- **Optional**: Authentication provider (LDAP, OpenID, social)
- **Optional**: Domain name and SSL certificate
- **Optional**: Container orchestrator (Docker or Kubernetes)
## Procedure
### Step 1: Create Shiny App Docker Images
Each Shiny app needs its own Docker image. Example `Dockerfile` for a Shiny app:
```dockerfile
FROM rocker/shiny:4.5.0
RUN apt-get update && apt-get install -y \
libcurl4-openssl-dev \
libssl-dev \
&& rm -rf /var/lib/apt/lists/*
RUN R -e "install.packages(c('shiny', 'bslib', 'DT', 'dplyr'), \
repos='https://cloud.r-project.org/')"
COPY app/ /srv/shiny-server/app/
RUN chown -R shiny:shiny /srv/shiny-server/app
USER shiny
EXPOSE 3838
CMD ["R", "-e", "shiny::runApp('/srv/shiny-server/app', host='0.0.0.0', port=3838)"]
```
Build and test each app:
```bash
docker build -t myorg/dashboard:latest ./apps/dashboard/
docker run --rm -p 3838:3838 myorg/dashboard:latest
```
**Got:** Each Shiny app runs independently in its own container.
### Step 2: Configure ShinyProxy
`application.yml`:
```yaml
proxy:
title: "Shiny Applications"
port: 8080
container-backend: docker
docker:
internal-networking: true
authentication: simple
admin-groups: admins
users:
- name: admin
password: admin_password
groups: admins
- name: analyst
password: analyst_password
groups: users
specs:
- id: dashboard
display-name: "Analytics Dashboard"
description: "Interactive data analysis dashboard"
container-image: myorg/dashboard:latest
container-cmd: ["R", "-e", "shiny::runApp('/srv/shiny-server/app', host='0.0.0.0', port=3838)"]
container-network: shinyproxy-net
port: 3838
access-groups: [admins, users]
- id: report-builder
display-name: "Report Builder"
description: "Generate custom reports"
container-image: myorg/report-builder:latest
container-cmd: ["R", "-e", "shiny::runApp('/srv/shiny-server/app', host='0.0.0.0', port=3838)"]
container-network: shinyproxy-net
port: 3838
access-groups: [admins]
logging:
file:
name: /opt/shinyproxy/log/shinyproxy.log
server:
forward-headers-strategy: native
```
### Step 3: Deploy ShinyProxy with Docker Compose
`docker-compose.yml`:
```yaml
services:
shinyproxy:
image: openanalytics/shinyproxy:3.1.1
container_name: shinyproxy
ports:
- "8080:8080"
volumes:
- ./application.yml:/opt/shinyproxy/application.yml:ro
- /var/run/docker.sock:/var/run/docker.sock
- shinyproxy-logs:/opt/shinyproxy/log
networks:
- shinyproxy-net
restart: unless-stopped
networks:
shinyproxy-net:
name: shinyproxy-net
driver: bridge
volumes:
shinyproxy-logs:
```
```bash
# Create the network first (ShinyProxy spawns containers on this network)
docker network create shinyproxy-net
# Start ShinyProxy
docker compose up -d
# Check logs
docker compose logs -f shinyproxy
```
**Got:** ShinyProxy starts on port 8080, shows login page, and lists configured apps.
**If fail:** Check `docker compose logs shinyproxy`. Verify app images are available locally (`docker images`).
### Step 4: Configure Authentication
#### Simple (built-in)
As shown in Step 2 with `authentication: simple` and inline users.
#### LDAP
```yaml
proxy:
authentication: ldap
ldap:
url: ldap://ldap.example.com:389/dc=example,dc=com
manager-dn: cn=admin,dc=example,dc=com
manager-password: ldap_admin_password
user-search-base: ou=users
user-search-filter: (uid={0})
group-search-base: ou=groups
group-search-filter: (member={0})
```
#### OpenID Connect (Keycloak, Auth0, etc.)
```yaml
proxy:
authentication: openid
openid:
auth-url: https://auth.example.com/realms/myrealm/protocol/openid-connect/auth
token-url: https://auth.example.com/realms/myrealm/protocol/openid-connect/token
jwks-url: https://auth.example.com/realms/myrealm/protocol/openid-connect/certs
client-id: shinyproxy
client-secret: your_client_secret
roles-claim: realm_access.roles
```
### Step 5: Add Reverse Proxy with Nginx
For production, place Nginx in front of ShinyProxy:
```nginx
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 443 ssl;
server_name shiny.example.com;
ssl_certificate /etc/letsencrypt/live/shiny.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/shiny.example.com/privkey.pem;
location / {
proxy_pass http://shinyproxy:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 600s;
proxy_buffering off;
}
}
```
WebSocket support is critical — ShinyProxy and Shiny use WebSockets heavily.
### Step 6: Usage Tracking
ShinyProxy logs usage events to its log file. For structured tracking, configure InfluxDB:
```yaml
proxy:
usage-stats-url: http://influxdb:8086/write?db=shinyproxy
usage-stats-username: shinyproxy
usage-stats-password: stats_password
```
Add InfluxDB to the compose stack:
```yaml
services:
influxdb:
image: influxdb:1.8
environment:
INFLUXDB_DB: shinyproxy
INFLUXDB_ADMIN_USER: admin
INFLUXDB_ADMIN_PASSWORD: admin_password
volumes:
- influxdata:/var/lib/influxdb
networks:
- shinyproxy-net
volumes:
influxdata:
```
### Step 7: App Resource Limits
```yaml
specs:
- id: dashboard
container-image: myorg/dashboard:latest
container-memory-limit: 1g
container-cpu-limit: 1.0
max-instances: 5
container-env:
R_MAX_MEM_SIZE: 768m
```
### Step 8: Verify Deployment
```bash
# Check ShinyProxy health
curl -s http://localhost:8080/actuator/health
# Test login
curl -s -c cookies.txt -d "username=admin&password=admin_password" \
http://localhost:8080/login
# List apps via API
curl -s -b cookies.txt http://localhost:8080/api/proxyspec
```
**Got:** Health endpoint returns `UP`. Login succeeds. Apps launch in isolated containers.
## Validation
- [ ] ShinyProxy starts and shows login page
- [ ] Authentication works for all configured users
- [ ] Each Shiny app launches in its own container
- [ ] WebSocket connections work (Shiny reactivity functions)
- [ ] Access groups restrict app visibility correctly
- [ ] Container cleanup works when users disconnect
- [ ] Logs capture usage events
## Pitfalls
- **Docker socket permissions**: ShinyProxy needs Docker socket access to launch containers. Run as a user in the `docker` group or mount the socket.
- **Network mismatch**: App containers must be on the same Docker network as ShinyProxy (`container-network` in specs must match).
- **WebSocket proxy**: Nginx or other proxies in front of ShinyProxy must forward WebSocket upgrade headers.
- **Image not found**: App images must be pulled or built locally on the Docker host before ShinyProxy tries to use them.
- **Container cleanup**: If ShinyProxy crashes, orphaned app containers may remain. Use `docker ps` to check and clean up.
- **Memory limits**: Shiny apps can consume significant memory. Set `container-memory-limit` to prevent a single app from starving others.
## Related Skills
- `deploy-shiny-app` - single-app deployment to shinyapps.io, Posit Connect, or Docker
- `configure-reverse-proxy` - reverse proxy patterns including WebSocket proxying
- `create-dockerfile` - general Dockerfile creation for app images
- `create-r-dockerfile` - R-specific Dockerfiles with rocker imagesRelated Skills
deploy-to-vercel
Deploy a Next.js application to Vercel. Covers project linking, environment variables, preview deployments, custom domains, and production deployment configuration. Use when deploying a Next.js app for the first time, setting up preview deployments for pull requests, configuring custom domains, or managing environment variables in a production Vercel deployment.
deploy-to-kubernetes
Deploy applications to Kubernetes clusters using kubectl manifests for Deployments, Services, ConfigMaps, Secrets, and Ingress resources. Implement health checks, resource limits, rolling updates, and Helm chart packaging for production deployments. Use when deploying new applications to EKS, GKE, AKS, or self-hosted clusters, migrating from Docker Compose to container orchestration, implementing zero-downtime rolling updates, or setting up multi-environment deployments across dev, staging, and production.
deploy-shiny-app
Deploy Shiny applications to shinyapps.io, Posit Connect, or Docker containers. Covers rsconnect configuration, manifest generation, Dockerfile creation, and deployment verification. Use when publishing a Shiny app for external or internal users, moving from local development to a hosted environment, containerizing a Shiny app for Kubernetes or Docker deployment, or setting up automated deployment pipelines.
deploy-searxng
Deploy a self-hosted SearXNG meta search engine via Docker Compose. Covers settings.yml configuration, engine selection, result proxying, Nginx frontend, persistence, and updates. Use when setting up a private search engine without tracking, aggregating results from multiple providers, running a shared search instance for a team or organisation, or replacing reliance on a single search provider.
deploy-ml-model-serving
Deploy machine learning models to production serving infrastructure using MLflow, BentoML, or Seldon Core with REST/gRPC endpoints, implement autoscaling, monitoring, and A/B testing capabilities for high-performance model inference at scale. Use when deploying trained models for real-time inference, setting up REST or gRPC prediction APIs, implementing autoscaling for variable load, running A/B tests between model versions, or migrating from batch to real-time inference.
deploy-edge-ai-model
Deploy machine learning models to edge devices using Google AI Edge Gallery, TensorFlow Lite, ONNX Runtime, and MediaPipe. Covers model quantization (INT8/INT4), on-device inference with Gemma 4 models, Android/iOS deployment via AI Edge Gallery, hardware delegate selection (GPU/NPU/DSP), and performance benchmarking on constrained devices. Use when deploying models to mobile phones, IoT devices, or embedded systems where cloud inference is impractical due to latency, cost, or connectivity constraints.
skill-name-here
One to three sentences describing what this skill accomplishes, followed by key activation triggers. This field is the primary mechanism agents use to decide whether to activate the skill — it is read during discovery before the full body is loaded. Start with a verb. Include the most important "when to use" conditions inline. Max 1024 characters.
write-vignette
Create R package vignettes using R Markdown or Quarto. Covers vignette setup, YAML configuration, code chunk options, building and testing, and CRAN requirements for vignettes. Use when adding a Getting Started tutorial, documenting complex workflows spanning multiple functions, creating domain-specific guides, or when CRAN submission requires user-facing documentation beyond function help pages.
write-validation-documentation
Write IQ/OQ/PQ validation documentation for computerized systems in regulated environments. Covers protocols, reports, test scripts, deviation handling, and approval workflows. Use when validating R or other software for regulated use, preparing for a regulatory audit, documenting qualification of computing environments, or creating and updating validation protocols and reports for new or re-qualified systems.
write-testthat-tests
Write comprehensive testthat (edition 3) tests for R package functions. Covers test organization, expectations, fixtures, mocking, snapshot tests, parameterized tests, and achieving high coverage. Use when adding tests for new package functions, increasing test coverage for existing code, writing regression tests for bug fixes, or setting up test infrastructure for a package that lacks it.
write-standard-operating-procedure
Write a GxP-compliant Standard Operating Procedure (SOP). Covers regulatory SOP template structure (purpose, scope, definitions, responsibilities, procedure, references, revision history), approval workflow design, periodic review scheduling, and operational procedures for system use. Use when a new validated system requires operational procedures, when existing informal procedures need formalisation, when an audit finding cites missing procedures, when a change control triggers SOP updates, or when periodic review identifies outdated procedural content.
write-roxygen-docs
Write roxygen2 documentation for R package functions, datasets, and classes. Covers all standard tags, cross-references, examples, and generating NAMESPACE entries. Follows tidyverse documentation style. Use when adding documentation to new exported functions, documenting internal helpers or datasets, documenting S3/S4/R6 classes and methods, or fixing documentation-related R CMD check notes.