Skip to content

G-Labs + cloudflared Setup

The Generation Runner and the PatchWork web app both need a G-Labs backend running. G-Labs is the local service that proxies generation API calls to NanoBanana 2 and Veo 3.1. This page walks through getting it running on your machine.

The architecture

flowchart LR
    A[PatchWork Web App<br/>patchwork-33m.pages.dev] --> B[cloudflared tunnel<br/>public HTTPS URL]
    C[workflow-runner.js<br/>headless] --> B
    B --> D[G-Labs<br/>http://localhost:8765]
    D --> E[NanoBanana 2 API]
    D --> F[Veo 3.1 API]

G-Labs sits between PatchWork and the actual model APIs. It runs locally on http://localhost:8765. For PatchWork (which lives on a public domain) to reach it, you expose your local port through a cloudflared tunnel — a temporary public HTTPS URL that proxies to localhost.

Quick start

Two commands, in order:

# Terminal 1: start G-Labs (port 8765)
# (Specific command depends on your G-Labs installation — see "Installing G-Labs" below)

# Terminal 2: start the tunnel
cloudflared tunnel --url http://localhost:8765

The second command prints a URL like https://random-words-12345.trycloudflare.com. This is the URL you give to the Generation Runner (via --server) or set inside PatchWork's settings.

Installing G-Labs

(One-time setup. Skip if G-Labs is already installed.)

G-Labs is internal tooling — installation instructions are kept in the internal docs separate from this wiki. Once installed, you start it the same way every session:

  1. Open a terminal in the G-Labs directory.
  2. Run the start command (typically npm start or similar — see the G-Labs README).
  3. Confirm it's serving on http://localhost:8765 by hitting http://localhost:8765/health in a browser. You should see a 200 OK response.

Installing cloudflared

If cloudflared isn't on your PATH yet:

Download the latest cloudflared-windows-amd64.exe from the Cloudflare releases page, rename it to cloudflared.exe, and put it somewhere on your PATH (e.g. C:\Windows\System32\ or a folder you add to PATH).

Verify: cloudflared --version

brew install cloudflared

# Debian/Ubuntu
sudo curl -L --output /usr/local/bin/cloudflared \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64
sudo chmod +x /usr/local/bin/cloudflared

No login or account required for the temporary --url tunnels we use. (Cloudflared also supports named tunnels with auth, but we don't need that.)

Starting the tunnel

Every session, from any terminal:

cloudflared tunnel --url http://localhost:8765

You'll see output like:

2026-05-12T17:00:00Z INF Requesting new quick Tunnel on trycloudflare.com...
2026-05-12T17:00:01Z INF +-------------------------------------------------------+
2026-05-12T17:00:01Z INF |  Your quick Tunnel has been created! Visit it at:     |
2026-05-12T17:00:01Z INF |  https://lemon-banana-cabbage-pie.trycloudflare.com   |
2026-05-12T17:00:01Z INF +-------------------------------------------------------+

That URL is what you copy. The tunnel URL changes every session — quick tunnels are ephemeral by design. If you restart cloudflared, you get a new URL and any place still pointing to the old URL will fail.

Using the tunnel URL

Generation Runner (headless) — pass it as --server:
bash node workflow-runner.js workflow.nbflow \ --server "https://lemon-banana-cabbage-pie.trycloudflare.com" \ --api-key "..." \ --concurrency 3
PatchWork web app — open the settings panel, paste the URL into "G-Labs Server URL".
The PatchWork web app stores this in browser local storage, so you only set it once per browser. But you have to update it every time the tunnel URL changes (i.e. every session).

Common issues

"Connection refused" from the runner
G-Labs isn't running on localhost:8765, or it crashed. Hit http://localhost:8765/health in a browser — if that fails, restart G-Labs.
"522 Connection timed out" from cloudflared
The tunnel is up but G-Labs isn't responding on the target port. Same diagnosis as above — check G-Labs is running.
Tunnel URL works for ~30 minutes then stops
Quick tunnels can drop. Restart cloudflared and update the URL in PatchWork settings or the runner's --server arg.
"API key invalid" from generations
The --api-key value the runner has doesn't match what G-Labs expects. Double-check the key is current. (API key is separate from the tunnel URL — the tunnel URL changes every session; the API key stays the same until rotated.)
PatchWork shows "no backend configured"
You haven't set the G-Labs server URL in PatchWork's settings, or you set the wrong URL. Open settings, paste the current tunnel URL, save.

Why a tunnel at all?

PatchWork is hosted on Cloudflare Pages at https://patchwork-33m.pages.dev/. Browsers won't let a public HTTPS page make requests to http://localhost:8765 (mixed-content + cross-origin restrictions). The tunnel solves this: PatchWork sends requests to https://<tunnel>.trycloudflare.com, which cloudflared proxies down to your local localhost:8765. Same goes for the runner if you're running it on a different machine from G-Labs.

If you're running everything (PatchWork local dev + runner + G-Labs) on the same machine, you can skip the tunnel and use http://localhost:8765 directly. But for the production PatchWork URL, the tunnel is required.

Session checklist

Every session before running a workflow:

  1. Start G-Labs (port 8765).
  2. Start cloudflared tunnel --url http://localhost:8765. Copy the printed URL.
  3. If using the headless runner: pass the URL as --server.
  4. If using PatchWork web app: paste the URL into settings.
  5. Run the workflow.

The Manager is configured to auto-start the cloudflared tunnel when you start a workflow — you don't need to do this manually unless you're running things outside the Manager.