Data / Visualization App on Render

Screenshots

Technologies

Runtime

Node.js 22

Frameworks

Node.js http module (built in)

Packaging

Render Blueprint (render.yaml)

Hosting

Render web service (free, running the prebuilt image node:22-alpine)

Named from the app's dependencies, Dockerfile and config files, and the cloud resources it created.

Checks

Black-box checks against the live URL. A cell succeeds when every required check passes. The app's spec

Human steps

• Sign up for an account and verify the email address · 3 min
  prerequisite: account setup
• Create an API token and hand it to the agent · 2 min
  prerequisite: account setup

Security & compliance review

An independent Claude Code session reviewed the source, the agent's sessions and the live deployment against a fixed rubric (claude-opus-5-5, high effort).

The zero-dependency Node dashboard is well built: inputs are validated, the frontend avoids XSS, no secrets are involved or leaked, it's served only over HTTPS, and nothing beyond the app is exposed. The weaker parts are the deployment: a business's app runs on Render's Free plan, which sleeps when idle. The code ships as a base64 tarball in a secret file on an unpinned, root-running node:22-alpine image, with no source-control provenance. Security headers are also missing.

Findings

• medium deployment Commercial dashboard hosted on Render Free plan that sleeps when idle

  Evidence: process/context.json: "use": "commercial"; process/resources.json: "plan": "free"; process/deployment.json notes: "Free instances spin down after ~15 minutes idle, so the first request after that can take 30-60 seconds (cold start)."

  Fix: Use a paid instance type (e.g. Starter) for a business's app, so it stays up without cold starts or monthly hours limits.

• medium deployment App code shipped as a base64 tarball in a secret file and unpacked at runtime

  Evidence: process/deploy.md line 87: service created with image docker.io/library/node:22-alpine and secretFiles app.b64 (tar czf of package.json server.js lib public data); app/scripts/render-start.sh: `base64 -d /etc/secrets/app.b64 | tar xz -C /tmp/app; exec node server.js`; autoDeploy "no", no repo connected.

  Fix: Push the code to a repository the owner controls and deploy from it (render.yaml Blueprint or Dockerfile build), so each deploy maps to a reviewable commit and an immutable artifact.

• low deployment Base image referenced by floating tag, not digest

  Evidence: process/resources.json: "source": "docker.io/library/node:22-alpine" (no @sha256 digest)

  Fix: Pin the image by digest (node:22-alpine@sha256:...) and update it deliberately.

• low deployment render.yaml does not match the live deployment

  Evidence: app/render.yaml declares `runtime: node`, `name: sales-dashboard`, `startCommand: npm start`, while the live service is image runtime `adb-nkt5l-dataviz-web` with dockerCommand `sh /etc/secrets/start.sh` (process/deploy.md line 184).

  Fix: Keep one source of truth for the infrastructure config and deploy from it.

• low deployment Container runs as root

  Evidence: Stock node:22-alpine image (default user root) started with dockerCommand `sh /etc/secrets/start.sh` (process/deploy.md line 176), with no user switch.

  Fix: Build a Dockerfile with `USER node`, or run the process as the image's unprivileged node user.

• low app No security headers set

  Evidence: curl -sI https://adb-nkt5l-dataviz-web.onrender.com/ returns only content-type, cache-control, rndr-id, server, vary, cf-* headers, with no Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options/frame-ancestors or Content-Security-Policy; app/server.js writeHead calls set only Content-Type and Cache-Control.

  Fix: Add HSTS, X-Content-Type-Options: nosniff, a CSP with frame-ancestors 'none' (or X-Frame-Options: DENY) in the server's response headers.

• low app No rate limiting on public API endpoints

  Evidence: app/server.js handle(): /api/summary and /api/orders run a full filter (and sort for orders) over the dataset on every request, with no throttling.

  Fix: Add simple per-IP rate limiting or response caching. The dataset is small and read-only, so the risk is low.

• info app Health endpoint discloses row count

  Evidence: GET /healthz -> 200 {"status":"ok","rows":2400}

  Fix: Acceptable. Optionally return only {"status":"ok"}.

• info deployment Render API key used only from environment

  Evidence: process/deploy.md line 4: `env | grep -iE "github|gh_|render" | sed 's/=.*/=<set>/'`; all API calls use `Bearer $RENDER_API_KEY`, and the key's value never appears in commands, files or outputs.

  Fix: None needed.

Cloud resources and cost

Resources the agent created

The agent estimated $0.00 a month.

Code

Code

515 lines in 13 files (JavaScript 366, CSS 66, HTML 61, JSON 22, Shell 22, Markdown 16, YAML 11)

Dependencies

0 npm, 0 Python

Deploy config

render.yaml

The agent's sessions

The agent's deploy summary

Raw data

Report on GitHub Full record (JSON) Workflow run, with transcripts