Blog
Problems, engineering ideas, and lessons from shipping ShipLocal — written for developers and agencies using the product.
A field guide from one debugging week — hydration, reload loops, observer timing.
The debugging playbook we wish we had on day one: Network → JS, Network → WS, overlay injection, CSP, and measure before streaming.
Read article →Your browser works on localhost but the CLI cannot reach your dev server.
Trying `127.0.0.1` and `::1` — and why `next dev -H 0.0.0.0` shows up in tunnel error messages.
Read article →How a Framer Motion portfolio matured ShipLocal faster than synthetic benchmarks.
Sophisticated Next.js apps expose hydration, HMR, CSP, and injection bugs that hello-world tunnels never surface.
Read article →Pasteable output beats guessing when someone says “the tunnel is slow.”
A CLI command that checks API health, auth, WebSocket handshake, local vs tunnel transfer times, compression, and HMR connectivity.
Read article →Streaming is protocol v2. Adoption is the bigger unknown.
response-start/chunk/response-end sounds attractive, but binary frames, caching, and benchmarks deliver ROI without redesigning backpressure and cancellation.
Read article →The tunnel buffers every asset through WebSocket JSON + base64 — hydration waits.
Navbar and text appear immediately; Framer Motion heroes lag. That is not slow SSR — it is delayed JS bundles over a fully buffered tunnel path.
Read article →Share the Review URL for feedback on any stack — or use the in-page overlay on production-like serves.
ShipLocal Cloud offers a Review URL (feedback outside your app HTML) plus an optional in-page overlay. Prefer the Review URL; use next start / vite preview when you want overlay on the Public URL.
Read article →HTTP-only tunnels break Next.js and Vite dev — until you relay browser WebSockets.
Dev servers depend on `/_next/webpack-hmr` and Vite's client socket. We added ws-open, ws-message, and ws-close to the tunnel protocol and wired browser ↔ server ↔ CLI ↔ localhost.
Read article →Injecting a `<script>` into every HTML response can fight Next.js Fast Refresh.
ShipLocal injects a client feedback overlay into proxied HTML. On Next.js dev pages, that innocent DOM change can trigger reload → reinject → reload forever.
Read article →Three problem classes we found testing a real Framer Motion portfolio — not a todo-list demo.
Navbar appears instantly, hero animations lag, section headers never fire — and another app reloads forever. Same tunnel, three different root causes.
Read article →Flat subdomains, proxy-layer CORS, and the gap between one tunnel and a full-stack graph.
Coordinated frontend + API preview URLs sound simple. The scars are in TLS wildcard limits, CORS placement, reconnect semantics, legacy migration, and knowing when not to show every historical tunnel row.
Read article →One project, two URLs, no staging deploy for the API.
ShipLocal v0.2 lets you expose frontend and API on coordinated preview URLs under one project — with CORS, cookie fixes, and a CLI env rewrite helper. Here is why that matters and how to use it.
Read article →A beginner-friendly tour of what happens after you run shiplocal 3000.
A beginner-friendly explanation of how ShipLocal turns localhost into a public preview URL, forwards browser requests back to your laptop, and collects client feedback without a staging deploy.
Read article →From CLI registration to WebSocket forwarding, subdomain routing, response rewriting, and feedback capture.
A practical architecture walkthrough of how ShipLocal turns a local development server into a public preview URL, forwards requests over WebSocket, and layers collaboration features on top of the tunnel.
Read article →It's everything that assumes the world is localhost — not the WebSocket part.
The hard part of building a developer tunnel isn't forwarding HTTP over WebSocket. It's everything that assumes the world is localhost — headers, addresses, URLs, cookies, CORS, compression, bundle sizes, reconnect loops, and the gap between "works in my terminal" and "works for a client on their phone."
Read article →The problem is not hosting. The problem is collaboration.
Every developer who ships work for clients hits the same wall — deploy just to show progress, or explain localhost over WhatsApp. The gap is collaboration, not hosting.
Read article →