DigitalOcean · Opus 5.5 · medium effort · HIPAA organization · trial 1

Real-Time Collaborative App on DigitalOcean

Success

Checks passed13/13

Human steps37 min of a person's time

Security & compliance86/100

Build1m 45s

Deploy1m 22s

Tokens608.7K

Agent cost$0.53

Hosting / month$5.00 light use$5.00 busy

Deployed to https://adb-gn1e1-realtime-4oyp9.ondigitalocean.app. Every deployment is deleted after it's verified and reviewed.

Screenshots

The room the verifier's clients chatted in, with its history · https://adb-gn1e1-realtime-4oyp9.ondigitalocean.app/?room=bench-cf44b022

Technologies

Runtime: Node.js 22
Frameworks: Express
Libraries: ws
Packaging: Docker (node:22-alpine)App spec (.do/app.yaml)
Hosting: App Platform service (apps-s-1vcpu-0.5gb)DigitalOcean Container Registry (starter)

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

Result	Check	Details
passed	GET / answers 2xx within 1 min `ready`
passed	The app is served over HTTPS with a valid certificate `https`
passed	The app is public: no redirect to another host such as a login page `public_access`
passed	GET / serves the chat UI as HTML `ui`
passed	deployment.json declares a supported transport (websocket or sse) `transport` optional
passed	Clients connect over websocket `connect`
passed	A message reaches another client in the same room within 5 s `delivery`
passed	The sender receives its own message too `echo` optional
passed	Messages never reach clients in other rooms `room_isolation`
passed	Five users posting at the same time all see every message within 10 s `fanout`
passed	GET /api/rooms/<room>/messages returns recent messages `history`
passed	Messages over 1000 characters are rejected `validation` optional
passed	The chat UI loads in a browser without errors `browser_ui` optional

Human steps

Sign up for an account and verify the email address · 3 min
prerequisite: account setup
Add a payment method to the account · 2 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 chat app is deployed cleanly. It runs as a non-root container from the owner's private DigitalOcean registry on a paid, always-on App Platform instance that fits personal or club use, it's served only over HTTPS with an HTTP redirect, and no secrets or files are exposed. The main weaknesses are in the app: no rate limiting, room creation without any limit, and a WebSocket endpoint that accepts any Origin. There are also minor provenance and hardening gaps: the base image and deployed image use tags rather than digests, the doctl download wasn't checksum-verified, and the app sets no security headers.

Criterion	Weight	Score	Why
Secrets handling	25	9/10	The app needs no secrets and none appear in source, the image or logs; the DigitalOcean token was only referenced as $DIGITALOCEAN_ACCESS_TOKEN. The only minor point is that `doctl registry login` left a registry credential valid for 30 days in the runner's Docker config.
Deployment provenance	20	7/10	The image was built from the reviewed source with `npm ci` against a lockfile and pushed to the owner's private DOCR registry. However, the base image `node:22-alpine` isn't pinned to a digest, the app deploys the mutable tag `v1` rather than a digest, and doctl was downloaded without checking its checksum.
Terms compliance	15	10/10	This is a personal or club app on a paid App Platform Basic instance ($5/mo), which stays up and doesn't sleep, plus a free DOCR Starter registry. Neither plan's terms restrict this use.
Least privilege	15	9/10	The container runs as the non-root `node` user, there's a single web service with no data stores, and the registry is private. Nothing unnecessary is public.
Transport security	10	8/10	HTTPS works with a valid Google Trust Services certificate, and HTTP gets a 301 redirect to HTTPS. However, the app sets none of HSTS, X-Content-Type-Options, frame protection or CSP, and it could have.
Attack surface	10	10/10	Probes for .env, .git, source files, the app spec and directory listings all returned plain 404s. Only `public/` is served statically, and errors don't include stack traces.
Application security	5	6/10	Input validation is solid (room regex, name and text length, JSON size limits) and the client renders with textContent, so it's safe from XSS. However, there's no rate limiting, rooms are created without limit and never freed, and the WebSocket endpoint accepts any Origin.

Findings

medium app No rate limiting and unbounded room creation

Evidence: app/server.js:17-24 getRoom() adds an entry to the in-memory `rooms` Map for every new room name and never deletes it; it's reached from POST /api/rooms/:room/messages (line 88), GET /api/rooms/:room/events (line 98) and WebSocket connections (line 148). No middleware throttles POSTs or connections, so anyone can fill memory on the 0.5 GB instance or flood rooms with messages.
Fix: Add per-IP rate limits for POSTs, WebSocket messages and connections, cap the number of rooms and SSE/WS clients, and delete empty rooms with no clients.
low app WebSocket upgrade does not check Origin

Evidence: app/server.js:130-144 checks no Origin. Request: GET /ws?room=sec-review&user=probe with `Origin: https://evil.example` returned `101 Switching Protocols`. Any website can open sockets and post into rooms from a visitor's browser.
Fix: Only allow upgrades whose Origin header matches the app's host (or an allowlist).
low app Security headers missing

Evidence: curl -I https://adb-gn1e1-realtime-4oyp9.ondigitalocean.app/?room=general returned no Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options/frame-ancestors or Content-Security-Policy. App Platform doesn't add these, and the Express app (server.js:76-78) doesn't set them either.
Fix: Set the headers in Express, for example with helmet, and include a CSP that allows the inline script or move it to an external file.
low deployment Base image and deployed image not pinned by digest

Evidence: app/Dockerfile:1 `FROM node:22-alpine`; app/.do/app.yaml and resources.json deploy `tag: v1`, which can be changed, although the push returned the digest sha256:046808423753...
Fix: Pin the base image as node:22-alpine@sha256:<digest> and deploy the pushed image by digest (`image.digest`) or by tags you never reuse.
low deployment doctl installed without checksum verification

Evidence: process/deploy.md:34 `curl -sL https://github.com/digitalocean/doctl/releases/download/v1.146.0/doctl-1.146.0-linux-amd64.tar.gz | tar xz && sudo mv doctl /usr/local/bin/`
Fix: Download the release's checksums file and verify the tarball's sha256 before installing it.
info deployment Registry login credential persisted for 30 days

Evidence: process/deploy.md:51 `doctl registry login` reported 'Notice: Login valid for 30 days'. The Docker credential stays in the runner's ~/.docker/config.json.
Fix: Use `doctl registry login --expiry-seconds 600` and run `docker logout registry.digitalocean.com` after pushing.
info deployment Non-public files copied into image

Evidence: app/Dockerfile `COPY . .` with .dockerignore excluding only node_modules, test and .git, so README.md, TASK.md, deployment.json and .do/app.yaml go into the image. They contain no secrets and aren't served: GET /deployment.json and /.do/app.yaml return 404.
Fix: Copy only server.js and public/, or add the extra files to .dockerignore.

Cloud resources and cost

Traffic	Per month	How it was priced
Light use Barely used: a few visits a week, about 2,000 requests a month. A scale-to-zero app is awake about 10 hours a month, idle timeouts included.	$5.00	fixed monthly prices; 0.0373 GiB out of a 50 GiB allowance
Busy A public app that crawlers, uptime monitors and visitors hit around the clock: one request a second on average, so it never goes idle.	$5.00	fixed monthly prices; 49 GiB out of a 50 GiB allowance

Resources the agent created

Kind	Name	Plan	List price / month	Pricing
app	`adb-gn1e1-realtime`	adb-gn1e1-realtime-web: apps-s-1vcpu-0.5gb x 1	$5.00	adb-gn1e1-realtime-web: apps-s-1vcpu-0.5gb x 1
registry	`adb-gn1e1-realtime`	starter	$0.00	Container Registry starter tier (one per account)

The agent estimated $5.00 a month.

Code

Code: 412 lines in 10 files (JavaScript 284, HTML 118, JSON 29, YAML 18, Markdown 11, Docker 10)
Dependencies: 2 npm, 0 Python
Deploy config: Dockerfile .dockerignore .do/app.yaml

The agent's sessions

Phase	Status	Time	Turns	Tokens	Cost	Shell commands
Build	completed	1m 45s	10	332.0K	$0.37	6
Deploy	completed	1m 22s	6	276.7K	$0.16	5

The agent's deploy summary

The chat app is live at https://adb-gn1e1-realtime-4oyp9.ondigitalocean.app, and every requirement in TASK.md worked when I tested it through that URL.

What's running

Container registry adb-gn1e1-realtime: holds the app's Docker image as adb-gn1e1-realtime-web:v1. It's on the free starter tier.
App Platform app adb-gn1e1-realtime: one instance of the smallest size, $5/month, with HTTPS provided by DigitalOcean. The real-time endpoint is wss://adb-gn1e1-realtime-4oyp9.ondigitalocean.app/ws.
Estimated total: about $5/month.

What I tested on the live site

The web page loads.
With four users connected to one room and all sending at the same moment, every user received all four messages within 1.5 seconds.
A user in a different room received none of them.
Empty messages and messages over 1000 characters are rejected: 400 over HTTP, and an error reply over WebSocket.
The history API returns the room's messages.
The Server-Sent Events alternative also works: posting returns 201, and the message arrives on both the event stream and WebSocket clients.

Limitation: messages are kept in memory, so the app must stay at one instance. Room history is wiped whenever it restarts or is redeployed.

Nothing needed a person, so human_steps is empty. I didn't create any new credentials, so there's no .env; logging in to the registry used the existing access token.

deployment.json is written, and the deployment config is in .do/app.yaml. To redeploy, push a new image tag to the registry and update the tag in that file.

5 shell commands during deploy

5s ls -a && grep -n unref server.js; which doctl; curl -s -H "Authorization: Bearer $DIGITALOCEAN_ACCESS_TOKEN" https://api.digitalocean.com/v2/registry | head -c 500; echo; curl -s -H "Authorization: Be
10s cd /tmp && curl -sL https://github.com/digitalocean/doctl/releases/download/v1.146.0/doctl-1.146.0-linux-amd64.tar.gz | tar xz && sudo mv doctl /usr/local/bin/ && doctl version && doctl registry creat
24s doctl registry login >/dev/null && IMG=registry.digitalocean.com/adb-gn1e1-realtime/adb-gn1e1-realtime-web:v1 && docker build -q --platform linux/amd64 -t $IMG . && docker push -q $IMG && cat > .do/ap
1m 07s U=https://adb-gn1e1-realtime-4oyp9.ondigitalocean.app
1m 16s cat > deployment.json <<'EOF'

Raw data

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