Database-Backed CRUD App on Cloudish

Screenshots

Technologies

Runtime

Node.js 24

Frameworks

Node.js http module (built in)

Data

SQLite (on a persistent volume)

Packaging

Docker (node:24-slim)

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.

Stack fit

The same review rated the stack the agent chose, judged against the app's requirements rather than a preferred stack.

A standard-library Node.js server with SQLite on a Cloudish persistent volume is a minimal, durable fit for a multi-user todo app on a container platform without a managed database. The build matches the reasoning in STACK.md.

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 app is well built: there are no secrets in source or the build context, queries are parameterized and scoped to the owner, passwords are hashed with scrypt, the deployment exposes nothing extra, and it's served over valid HTTPS with an HTTP redirect. The main problem is hosting. This commercial app runs on an unclaimed, agent-minted Cloudish key with a free 0.1-credit grant that runs out in about 9 hours, and the owner doesn't control that account yet. Smaller issues are a root container, an unpinned base image, no login rate limiting, and missing security headers and Secure cookie flag.

Findings

• high deployment Commercial app runs on an unclaimed free-credit key that runs out in about 9 hours

  Evidence: process/deployment.json human_steps: 'The key only has the free 0.1 credit grant (about 0.098 left, roughly 9 hours of container run time)... When it runs out the app returns 402/503'; process/context.json use=commercial, balance_usd=0.09767; deploy.md key minted with POST /api/v1/keys without an owner account.

  Fix: Before handover, have the business claim the key under its own Cloudish account and fund it (or use a paid plan whose terms allow commercial use), and treat this as a blocking step rather than optional.

• medium deployment Deployment is owned by an agent-minted, unclaimed key

  Evidence: deploy.md: project created with owner {id:86, username:'adb-lrg47-crud'} using a key from an unauthenticated POST /api/v1/keys; the only control over it is the key in the agent workspace's .env.

  Fix: Attach the key/project to an account the owner controls, and rotate the key once it's claimed.

• medium deployment Container runs as root

  Evidence: app/Dockerfile has no USER directive; node:24-slim defaults to root.

  Fix: Add `RUN chown node:node /data` and `USER node` (and make sure the mounted volume is writable by that UID).

• low deployment Base image not pinned to a digest

  Evidence: app/Dockerfile:1 `FROM node:24-slim`

  Fix: Pin the image as `node:24-slim@sha256:<digest>` and update it deliberately.

• low app No rate limiting on authentication endpoints

  Evidence: 10 consecutive POST /api/auth/login requests with wrong passwords all returned 401 with no throttling; server.js:174-199 has no limiter, and each attempt runs scrypt (N=16384) on a 0.1 CPU instance.

  Fix: Add per-IP and per-account throttling or lockout on login and signup.

• low app Login timing reveals which emails have accounts

  Evidence: server.js:194-195 skips scrypt when the user doesn't exist, so responses for unknown emails come back faster.

  Fix: Run a dummy scrypt verify when the user is missing.

• low app Session cookie missing the Secure flag

  Evidence: POST /api/auth/signup response: `set-cookie: token=...; Path=/; HttpOnly; SameSite=Lax; Max-Age=2592000` (no Secure). server.js:153 only adds Secure when x-forwarded-proto is 'https', which the ingress doesn't appear to pass.

  Fix: Set Secure unconditionally when NODE_ENV=production.

• low app Missing security headers

  Evidence: GET / response headers include only content-type, cache-control and strict-transport-security (HSTS added by the platform); no Content-Security-Policy, X-Content-Type-Options or X-Frame-Options/frame-ancestors.

  Fix: Set CSP, `X-Content-Type-Options: nosniff` and `frame-ancestors 'none'` in server.js responses.

• info platform Ingress error page reveals nginx

  Evidence: GET /%2e%2e/server.js -> 400 with an nginx-branded HTML page.

  Fix: No action needed from the app; the platform could serve neutral error pages.

• info app Bearer token stored in localStorage

  Evidence: app/public/index.html:55,72 localStorage.setItem('token', ...)

  Fix: Rely on the HttpOnly cookie for the web UI and add a CSP to limit the impact of any XSS.

Cloud resources and cost

Resources the agent created

The agent estimated $7.84 a month.

Code

Code

487 lines in 10 files (JavaScript 326, HTML 153, JSON 30, Markdown 27, Docker 8)

Dependencies

0 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