Real-Time Collaborative App on Railway

Screenshots

Technologies

Runtime

Node.js 20+

Frameworks

Node.js http module (built in)

Libraries

ws

Packaging

railway.json

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
• Add a payment method to the account · 2 min
  resources: paid resources: adb-klpuj-realtime

Stack fit

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

A minimal Node.js + ws service on one Railway container fits a small realtime chat well and follows the reasoning in STACK.md. The main gap is in-memory history, which doesn't survive restarts.

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).

This is a small single-service Node.js chat app on Railway that handles secrets cleanly and exposes nothing beyond its own routes over valid HTTPS, with HTTP redirected. The main weakness is in the app: an unguarded decodeURIComponent lets one malformed request crash the process, and there's no rate limiting or WebSocket Origin check. Smaller issues are missing security headers, unpinned Railpack/npm build inputs and a root container.

Findings

• medium app One unauthenticated request can crash the server (uncaught decodeURIComponent)

  Evidence: app/server.js:72 calls `decodeURIComponent(m[1])` with no try/catch inside the http request handler. A path like /api/rooms/%E0/messages throws URIError, which is uncaught, so Node exits. railway.json sets restartPolicyType ON_FAILURE with restartPolicyMaxRetries 5, so a few requests could keep the service down and wipe the in-memory history. Judged from the code; I didn't send it to the live service, to avoid causing an outage.

  Fix: Wrap the decode in try/catch and return 400. Also add a process-level error guard, or use a router that handles bad encodings.

• low app No rate limiting, connection limits or room cap

  Evidence: app/server.js:78-90 (POST messages) and 110-140 (WebSocket) accept unlimited anonymous posts and connections. getRoom (line 14) creates a room for every new valid name and never evicts it, so memory grows without limit.

  Fix: Add per-IP rate limits on posts and connections, cap the number of rooms and SSE/WS clients, and evict rooms that are empty and idle.

• low app WebSocket upgrade doesn't check Origin

  Evidence: app/server.js:110-117 accepts any upgrade on /ws without looking at the Origin header, so any website can open sockets and post as any display name. There's no auth, so the impact is limited.

  Fix: Only accept upgrades whose Origin is the app's own host.

• low app Security headers missing

  Evidence: `curl -D - https://adb-klpuj-realtime-web-production.up.railway.app/` returns only content-type, date, server: railway-hikari and x-railway-* headers. There's no Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options or X-Frame-Options.

  Fix: Set HSTS, a strict CSP (the page is self-contained), X-Content-Type-Options: nosniff and frame-ancestors 'none' in the server's responses.

• low deployment Build inputs not pinned

  Evidence: app/railway.json uses builder RAILPACK with its default base image. package.json has `"node": ">=20"` and `"ws": "^8.22.0"`, and the app bundle has no package-lock.json, even though `npm i ws` was run in process/build.md. Deployed with `railway up --service adb-klpuj-realtime-web --ci` straight from the local workspace, with no commit to tie the release to.

  Fix: Commit and deploy package-lock.json (npm ci), pin the Node major version, and deploy from a tagged git commit or a Dockerfile with a digest-pinned base image.

• low deployment Container runs as the default root user

  Evidence: The build goes through Railpack (railway.json `builder: RAILPACK`) and no non-root user is configured. The build log in process/deploy.md shows apt packages being installed into the image.

  Fix: Use a Dockerfile with `USER node`, or set a non-root user for the Railpack image.

• info deployment Account plan not confirmed

  Evidence: process/context.json shows `account: {}`. deployment.json says the plan is the "existing account plan (unchanged)", with costs that 'free or included credits may cover'.

  Fix: Confirm the account is on the Hobby (or higher) plan, not a trial whose credits expire, so the club's chat stays up.

Cloud resources and cost

Resources the agent created

The agent estimated $1.00 a month.

Code

Code

329 lines in 10 files (JavaScript 218, HTML 98, JSON 43, Markdown 21, Shell 13)

Dependencies

1 npm, 0 Python

Deploy config

railway.json

The agent's sessions

The agent's deploy summary

Raw data

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