How Redline is actually built

Redline is a handful of free, no-signup developer tools sharing one Next.js app: an API Tester for firing one-off HTTP requests, a Webhook Debugger for watching real webhook traffic land in a disposable inbox, a JWT Decoder, and a Timestamp Converter. None of them require an account — there's no auth system, no user table. Access to a webhook inbox is simply knowing its (unguessable) URL; the JWT Decoder and Timestamp Converter don't touch the server at all.

The app was designed with an optional-module architecture from the start — pieces like sign-in or analytics can be switched on later without dragging in code or dependencies for the ones nobody's using. Right now, the only one turned on is the database, because the Webhook Debugger needs somewhere durable to keep captured requests.

app/
  page.tsx                  # landing page
  tools/page.tsx            # hub page — a card per tool
  tester/page.tsx           # API Tester
  webhooks/page.tsx         # create a new inbox
  webhooks/[id]/page.tsx    # a single inbox
  jwt/page.tsx              # JWT Decoder (fully client-side)
  timestamp/page.tsx        # Timestamp Converter (fully client-side)
  api/[[...route]]/route.ts # hands every /api/* request to Hono

server/
  hono/app.ts               # composes all API routes
  hono/routes/               # proxy.ts, webhooks.ts, hook.ts
  hono/lib/ssrf-guard.ts    # blocks the proxy from hitting private IPs
  db/admin.ts                # the only client allowed to touch the database

components/
  ui/                        # shadcn primitives
  sections/                  # landing-page sections
  tester/, webhooks/, jwt/, timestamp/  # each tool's own pieces

lib/
  types.ts                   # shared request/response contracts
  relative-time.ts           # bidirectional "in 3 hours" / "2 days ago"

1. You fill in method, URL, headers, and body in the browser, then hit Send.
2. Your browser posts that as JSON to /api/proxy— never straight to the target API. That's what lets Redline bypass CORS entirely: the request happens server-side, not in your browser.
3. The server validates the target URL (see Security model), then makes the real request with a 20-second timeout.
4. Status, headers, body, timing, and size come back as one JSON object and render in the response panel, color-coded by status class.
5. The sent request is saved to your browser's localStorage, capped at 15 — the only place tester history lives. Redline's server never stores your requests or responses.

1. Creating an inbox inserts one row into a webhook_bins table and returns its random ID.
2. You get an ingest URL — /api/hook/:id — and hand it to whatever should send you webhooks.
3. Any request to that URL, any method, any path, is captured in full: method, path, query string, every header, the raw body, and the sender's IP — stored against that inbox's ID. There's no auth on this endpoint by design; the inbox ID is the access control.
4. The inbox page polls for new requests every few seconds and shows them newest-first, with a detail view for headers, query params, and body.
5. Deleting an inbox cascades to every request captured in it, at the database level.

webhook_bins
  id uuid primary key
  name text
  created_at, last_active_at timestamptz

webhook_requests
  id uuid primary key
  bin_id uuid references webhook_bins(id) on delete cascade
  method text, path text, query jsonb, headers jsonb
  body text, content_type text, ip text
  received_at timestamptz

Both tables have row-level security enabled with zero policies defined. That's deliberate: the public/anonymous database credential has no access to this data at all, full stop. Every read and write goes through a single privileged server-side client that bypasses RLS — there's only one trusted caller, so there was never a need for granular policies.

Three full color scales — scarlet, orange, and a warm neutral grey — are mapped onto semantic tokens (primary, background, destructive, and so on), plus two custom tokens for status-code coloring across both tools.

Type is three faces: a sans for body and UI, a monospace face used heavily for anything technical (URLs, headers, JSON), and a display serif reserved for statement headings rather than every heading. Every component under components/ui/ is source in the repo, not an installed package — added via a CLI, then owned and editable directly.

The main nav stays to three items — Tools, About, Contact — rather than listing both tools individually; Tools links to the hub page where each tool gets its own card. On genuinely wide screens the nav bar shows those links inline. Below that, the inline links and CTA disappear entirely and a single hamburger trigger takes their place — opening a full-screen panel that slides in from the right with a real focus trap and portal, and closes itself the moment you tap a link or press Escape.

The footer carries the full site map — product, company, and legal links — so none of the legal pages needed to clutter the main nav bar itself.

Every page and both tools are covered by Playwright tests that run against an actual production build — not mocked, not a dev server. That includes a realproxied HTTP request in the API Tester tests, and a full create → capture → inspect → delete round trip against the real database for the Webhook Debugger. The database-dependent tests check that real credentials are configured before running, and skip cleanly with a clear reason if they aren't, rather than reporting a false failure.