Real-Time Collaborative App on Cloudish

Screenshots

Technologies

Runtime

Node.js 22

Frameworks

Node.js http module (built in)

Data

Files on a persistent volume

Libraries

ws

Packaging

Docker (node:22-alpine)

Hosting

Cloudish container (shared) with a persistent volume

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

None: the agent got everything it needed on its own.

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 club chat app is a small Node/ws service that Cloudish built from the uploaded Dockerfile. It runs as a non-root user over valid HTTPS with an HTTP-to-HTTPS redirect and platform-added HSTS, it handles its single API key cleanly, and nothing beyond the app is exposed. The main weaknesses: the app depends on about 9 hours of free credit on an unclaimed key, the public message endpoints have no rate limiting and rooms and logs grow without limit, the app sets no security headers, the base image is pinned only by tag, and the platform reflects any Origin in CORS.

Findings

• medium deployment App depends on ~9 hours of free credit on an unclaimed key

  Evidence: process/context.json: balance_usd 0.097334; app/deployment.json human_steps: 'The free grant of 0.1 credits covers only about 9 hours of running time... Once it runs out, the app returns 402/503', marked "blocking": false

  Fix: Have the club claim the key and fund the account (or set up auto top-up) before relying on the app, and treat this as a blocking step.

• medium app No rate limiting or flood protection on public endpoints

  Evidence: app/server.js:151-158 (POST /api/rooms/<room>/messages) and :207-219 (WebSocket messages) post every valid message with no per-IP or per-connection throttle; there's no cap on connections or SSE streams (:160-173)

  Fix: Add per-IP and per-connection rate limits (for example a token bucket), cap concurrent connections per IP, and cap the number of rooms.

• low app Unbounded room creation and log growth

  Evidence: app/server.js:18-25 getRoom() creates a room for any valid name on a GET as well (:149), and rooms are never freed; :97 appends every message to messages.jsonl, which is compacted only at startup (:42-45). The container is billed at 0.2 GB of memory and the volume is 1 GB.

  Fix: Don't create rooms on read, evict idle empty rooms, and compact or rotate the log periodically.

• low app WebSocket upgrade does not check Origin

  Evidence: Request: GET /ws?room=probe&user=reviewer with 'Origin: https://evil.example' and WebSocket upgrade headers -> HTTP 101. app/server.js:184-197 has no Origin check.

  Fix: Allow WebSocket upgrades only from the app's own origin. The impact is small because there's no authentication.

• low deployment Base image not pinned by digest

  Evidence: app/Dockerfile:1 'FROM node:22-alpine'

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

• low deployment Deployed from a local tarball, not owner-controlled source control

  Evidence: process/deploy.md: 'tar --exclude=... -czf /tmp/context.tar.gz .' then 'curl -X POST https://cloudish.ai/api/v1/projects ... -F context=@/tmp/context.tar.gz'

  Fix: Commit the source to a repository the club controls and deploy from a tagged commit so the running build can be traced to its source.

• low app Missing nosniff, frame protection and CSP headers

  Evidence: GET /?room=general -> HTTP/2 200 with only content-type, vary, access-control-allow-credentials, cache-control and strict-transport-security (HSTS comes from the platform); app/server.js:135 sets only Content-Type and Cache-Control

  Fix: Set X-Content-Type-Options: nosniff, a CSP with frame-ancestors 'none' (or X-Frame-Options: DENY), and Referrer-Policy in server.js.

• low platform Ingress reflects any Origin in CORS with credentials allowed

  Evidence: OPTIONS /api/rooms/general/messages with 'Origin: https://evil.example' -> 204, access-control-allow-origin: https://evil.example, access-control-allow-credentials: true, access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE (the app code sets no CORS headers)

  Fix: The platform should make permissive CORS opt-in. The app has no cookies or auth, so the practical impact is small.

• info deployment Account key minted by the agent; the club doesn't yet own it

  Evidence: process/deploy.md: 'curl -s -X POST https://cloudish.ai/api/v1/keys ... -d {"agent":"claude-code","alias":"adb-2bmxu-realtime"}' with the key saved to .env

  Fix: Transfer control to the club by claiming the key, and keep the .env copy out of shared storage.

• info deployment API key kept out of logs and the build context

  Evidence: process/deploy.md: the key is written to .env via jq without being echoed; the build context listing shows no .env; app/.dockerignore:2 '.env*'

  Fix: No change needed.

Cloud resources and cost

Resources the agent created

The agent estimated $7.84 a month.

Code

Code

496 lines in 9 files (JavaScript 360, HTML 125, JSON 37, Docker 11, Markdown 8)

Dependencies

1 npm, 0 Python

Deploy config

Dockerfile .dockerignore

The agent's sessions

The agent's deploy summary

Raw data

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