Shiny in production on AWS: one private workspace per scientist, with login, plans and payments built in.

Foundations: a safe, cost-capped account

1. Separate accounts from day one. An AWS Organization with a management account (billing, budgets, credits) and a dedicated workload account for the app. Nothing runs in the management account.
2. Lock the root user with MFA and never use it for daily work. Daily sign-in goes through a named identity with MFA.
3. Set the budget alarm before creating anything that costs money. Alerts at 50%, 80% and 100% of actual and forecast spend.
4. Pin the region. A service control policy keeps work in Mumbai (ap-south-1), which also matches our privacy policy: data is processed in India.
5. Tag everything (Project, Env, Owner, ManagedBy) so the bill splits per product when the next app arrives.
6. Apply for AWS Activate early. Credits now cover the running costs for months.

Make the app cloud-ready, then containerise it

Most "it works on my laptop" failures are fixed before Docker. We ran a readiness audit on the Shiny code and fixed ten things, one commit at a time:

1. No outside servers in the browser. CDN fonts and icon links removed, so the app works on a locked-down network and leaks nothing.
2. Cap CPU per user. parallel::detectCores() - 1 would grab the whole server; it now reads a per-plan DVP_CORES value.
3. No stray files. A null graphics device stops Rplots.pdf appearing in the app folder.
4. Pin every package with renv: 395 packages, R 4.5.3, Bioconductor 3.22. Every build is identical.
5. A tight .dockerignore cut the build context from about 540 MB to 58 MB.
6. One environment variable decides the plan. Unset means full access (developer laptop); a typo falls back to the free plan, never to full access.
7. Check the CPU architecture. All packages built on ARM, so we chose Graviton: more memory per dollar.

# The app never decides access by itself: the platform tells it.
plan <- tolower(Sys.getenv("DVP_PLAN", unset = "full"))
if (!plan %in% c("explorer", "researcher", "bigdata", "xl", "full")) {
  plan <- "explorer"   # unknown value = free plan, never full access
}

# CPU per user comes from the platform too (default 2 cores)
n_cores <- max(1L, min(parallel::detectCores() - 1L,
                       as.integer(Sys.getenv("DVP_CORES", "2")), na.rm = TRUE))

# Simplified. Pinned R from renv.lock, built for Graviton (arm64).
FROM rocker/r-ver:4.5.3

# system libraries for graphics, genomics packages and exports
RUN apt-get update && apt-get install -y --no-install-recommends \
      libcurl4-openssl-dev libssl-dev libxml2-dev libmagick++-dev \
      libfontconfig1-dev libharfbuzz-dev libfribidi-dev pandoc zip \
    && rm -rf /var/lib/apt/lists/*

ENV R_GC_MEM_GROW=0          # gentler memory growth on big data
WORKDIR /app
COPY renv.lock renv.lock
RUN R -q -e "install.packages('renv'); renv::restore(prompt = FALSE)"
COPY . .

ARG DVP_VERSION
ENV DVP_VERSION=${DVP_VERSION}
RUN useradd -m shiny && chown -R shiny /app
USER shiny                    # never run as root
EXPOSE 3838
CMD ["R", "-q", "-e", "shiny::runApp('/app', host='0.0.0.0', port=3838)"]

# tag = app version + git commit, so every image is traceable
TAG="v1.1.2-$(git rev-parse --short HEAD)"
REPO="<account>.dkr.ecr.ap-south-1.amazonaws.com/datavizpro"

aws ecr get-login-password --region ap-south-1 \
  | docker login --username AWS --password-stdin "${REPO%%/*}"

docker build --platform linux/arm64 --build-arg DVP_VERSION=$TAG -t $REPO:$TAG .

# test every plan locally before pushing
for p in explorer researcher bigdata xl typo; do
  docker run --rm -e DVP_PLAN=$p -p 3838:3838 $REPO:$TAG   # check, then Ctrl-C
done

docker push $REPO:$TAG          # never deploy :latest

Run it: server, ShinyProxy, load balancer, HTTPS

1. Two security groups, nothing else open. The load balancer accepts 80/443 from the internet; the server accepts port 8080 only from the load balancer's security group. No SSH port at all: admin access is through Session Manager.
2. The server: Amazon Linux 2023 on Graviton, encrypted disk, IMDSv2 required, termination protection, and an IAM role (no access keys on the machine). We started on a small instance and resized after load tests.
3. ShinyProxy runs as a Docker container on the server and talks to the Docker daemon to start one app container per user.
4. Certificate: ACM issues the certificate for app.plantnura.com, validated by two CNAME records added in Hostinger DNS. Keep those records; ACM uses them to renew.
5. Load balancer: HTTPS on 443, HTTP redirected with a 301, idle timeout raised to one hour so long Shiny WebSocket sessions are not cut.
6. DNS: a single CNAME app → the load balancer's address, in the same Hostinger panel as the website.

# Shiny keeps a WebSocket open; the default 60 s idle timeout drops quiet sessions
aws elbv2 modify-load-balancer-attributes --load-balancer-arn $ALB_ARN \
  --attributes Key=idle_timeout.timeout_seconds,Value=3600

# ShinyProxy answers /login with a redirect once sign-in is on: accept 2xx-3xx
aws elbv2 modify-target-group --target-group-arn $TG_ARN \
  --health-check-path /login --matcher HttpCode=200-399

Login: Cognito groups are the plans

1. A Cognito user pool (Essentials tier, free up to 10,000 monthly active users) with email-only sign-up, self-registration and deletion protection. Login pages carry PlantNura branding and links to the Terms and Privacy Policy.
2. Groups: researcher, bigdata, xl, admins. No group means the free Explorer plan, so a new user needs no extra step.
3. An app client with callback https://app.plantnura.com/login/oauth2/code/shinyproxy and scopes openid email.
4. The client secret lives in Parameter Store as a SecureString. ShinyProxy's start script reads it with the server's IAM role and passes it in as an environment variable. It is never in git, the image or a config file.
5. One ShinyProxy spec per plan, all using the same image, each restricted with access-groups. Users see only the workspace their plan allows.

proxy:
  authentication: openid
  openid:
    auth-url:  https://<your-domain>.auth.ap-south-1.amazoncognito.com/oauth2/authorize
    token-url: https://<your-domain>.auth.ap-south-1.amazoncognito.com/oauth2/token
    jwks-url:  https://cognito-idp.ap-south-1.amazonaws.com/<pool-id>/.well-known/jwks.json
    client-id: ${COGNITO_CLIENT_ID}
    client-secret: ${COGNITO_CLIENT_SECRET}   # injected from Parameter Store at start
    roles-claim: cognito:groups                 # Cognito groups become ShinyProxy groups
  container-wait-time: 120000                 # ms: allow a heavy R app to boot
  container-wait-timeout: 30000              # ms per readiness probe (default 5 s is too short)
  template-path: /opt/shinyproxy/templates/plantnura
  specs:
    - id: researcher
      display-name: DataViz Pro · Researcher
      container-image: <ecr-repo>/datavizpro:v1.1.2-<sha>
      access-groups: [researcher, admins]
      container-network: dvp-apps                # internal network, no internet
      container-memory-limit: 2g
      max-lifetime: 240                         # minutes
      container-env:
        DVP_PLAN: researcher
        DVP_UPGRADE_URL: https://app.plantnura.com/start
    # ... explorer (1g), bigdata (16g, max-total-instances: 1), xl

Payments: hosted checkout, signed webhooks, no servers

1. Let the load balancer do the routing and the sign-in. ALB listener rules send POST /webhooks/razorpay to the webhook Lambda (no auth, signature-checked instead), and /start and /account through an authenticate-cognito action to the checkout Lambda. Everything else goes to ShinyProxy.
2. Checkout Lambda reads the plan from the link, creates a Razorpay order for one-off passes or a subscription for monthly plans, and opens Razorpay's hosted checkout. PlantNura never handles card or UPI details.
3. Webhook Lambda verifies the HMAC-SHA256 signature on the raw body, checks the amount against the price book, ignores repeats (keyed on the payment ID), adds the user to the Cognito group and records the paid-up date in DynamoDB.
4. Five events drive everything: order.paid, subscription.charged, subscription.cancelled, subscription.halted, refund.processed. A cancelled monthly plan keeps access to the end of the paid month; a full refund removes the plan.
5. A daily expiry job (EventBridge Scheduler at 00:15 IST → Lambda) returns lapsed plans and passes to Explorer. A reminder email three days before a pass ends is rolling out with Amazon SES.
6. Each Lambda has its own least-privilege IAM role: the console's default role is always swapped out.

import base64, hashlib, hmac

def verified(event, secret: bytes) -> bool:
    # Sign the RAW body exactly as received; parsing JSON first breaks the signature
    body = event.get("body") or ""
    raw = base64.b64decode(body) if event.get("isBase64Encoded") else body.encode()
    expected = hmac.new(secret, raw, hashlib.sha256).hexdigest()
    got = event["headers"].get("x-razorpay-signature", "")
    return hmac.compare_digest(expected, got)   # constant-time compare

# secret = Parameter Store SecureString, fetched with decryption by the Lambda's role

# An ALB target Lambda must return statusDescription as "code + reason".
# A bare "400" makes the load balancer answer 502 Bad Gateway.
def reply(code: int, text: str, body: str = "", ctype="text/plain"):
    return {
        "statusCode": code,
        "statusDescription": f"{code} {text}",   # e.g. "400 Bad Request"
        "isBase64Encoded": False,
        "headers": {"Content-Type": ctype},
        "body": body,
    }

Plan limits at runtime

1. Memory per container by plan (see section 6), enforced by Docker, so one heavy session cannot starve others.
2. Session caps: free sessions share their own pool, Big Data runs one session at a time, and the server has an overall cap, so free users can never crowd out paying ones.
3. Idle and lifetime limits: 15 minutes idle; longest session 1 hour on Explorer and 4 hours on paid plans.
4. In-app upgrade buttons point to /start, so "Unlock" in the app and "Buy" on the website share one checkout.
5. Usage events (session start and stop, plan, duration; never data) go to a local log so we can report Big Data hours before enforcing them.

Data and privacy: make the policy true

1. Uploads exist only inside the user's container. No shared disk, no bucket, no database of user files.
2. App containers have no internet. They run on a Docker network created with --internal; only ShinyProxy is on both networks.
3. Containers cannot reach AWS credentials. IMDSv2 with a hop limit of 1 means the server can read its role, but a container (one extra hop) cannot.
4. Logs hold events, not data. Lambda logs keep 30 days; admin shell sessions are recorded for 90 days; usage records are trimmed to 12 months automatically.
5. Then we rewrote the privacy policy to say exactly this, and nothing we could not prove.

# 1. An internal network: containers on it have no route to the internet
docker network create --internal dvp-apps
docker network connect dvp-apps shinyproxy        # ShinyProxy bridges both networks

# 2. Containers cannot borrow the server's IAM role
aws ec2 modify-instance-metadata-options --instance-id $INSTANCE_ID \
  --http-tokens required --http-put-response-hop-limit 1

# 3. Prove it from inside a user container (both must fail)
curl -m 5 https://example.com
curl -m 5 http://169.254.169.254/latest/api/token -X PUT

Load tests before publishing any limit

We generated synthetic files from 25 MB to 4 GB, ran read, box plot, scatter and correlation in each workspace size, and recorded peak memory from the container's cgroup. The results changed two decisions: the server size and the Big Data file limit. Details in section 7.

Go-live: a checklist, not a feeling

1. Terms, Privacy, Refund & Cancellation pages updated to match the plans exactly; prices identical on the website and in Razorpay (INR with GST, USD).
2. Live keys and webhook secret entered by the owner, directly in the console; never in chat, email or code.
3. A real purchase with a real card. It surfaced a live webhook-secret mismatch within minutes, fixed by rotating the secret in both places. A second real purchase proved the full chain.
4. Alarms wired to email; a written rollback plan, including a one-rule "pause sales" switch on the load balancer that returns a fixed maintenance response for checkout.

Operations: boring on purpose

Weekly server images, memory and disk metrics with alarms, a monthly cost review and a fixed release routine. See section 10.