Issues running workflows with NextJS Experimental HTTPS

[NC-DEV-Theo]

I’m running Next.js 15.6.0-canary.33 with Experimental HTTPS enabled, as I need to use local subdomains (e.g., https://local.dev:PORT) instead of http://localhost:PORT.

After setting up the new Workflow system, I consistently encounter the following error at runtime:

⨯ unhandledRejection: TypeError: fetch failed
    at async (../src/queue.ts:56:26) {
  [cause]: Error [HTTPParserError]: Response does not match the HTTP/1.1 protocol (Expected HTTP/, RTSP/ or ICE/)
      at <unknown> (HTTPParserError: Response does not match the HTTP/1.1 protocol (Expected HTTP/, RTSP/ or ICE/)) {
    code: undefined,
    data: '\x15\x03\x03\x00\x02\x02\x16'
  }
}

Context:
• Experimental HTTPS is required because I rely on local subdomains during development.
• The setup runs fine with standard HTTP, but fails as soon as I enable HTTPS.
• I’m aware that Experimental HTTPS is still unstable and resource-intensive, but this error seems related specifically to Workflow.

Question:
Is there any recommended configuration or workaround to make Workflow work properly with Experimental HTTPS in local development?

[eersnington]

@NC-DEV-Theo have you tried to proxy with rewrite()? I think this is happening cause Local World hard codes "http" internally (you can configure the port and embedded world output dir)

I'll see if I can get a working example with rewrite

[eersnington]

a side-note: the workflow package doesn't play well with next.js < 16 with turbopack enabled, so you'll have to resort to webpack

#92 (comment)

[eersnington]

Screen.Recording.2025-11-04.at.9.14.56.PM.mov

here's a workaround @NC-DEV-Theo

https://github.com/eersnington/workflow-nextjs-https-rewrite-example

[eersnington]

@pranaygp is it cool if I open a PR to support "WORKFLOW_BASE_URL" to https://github.com/vercel/workflow/blob/main/packages/world-local/src/config.ts#L18-L23 with fallback to http://localhost:{PORT} so that it will be non breaking and devs can customize it within the config?

the main reason for this issue is cause local world [queue.ts#L64] (https://github.com/vercel/workflow/blob/main/packages/world-local/src/queue.ts#L64) hard codes the http url for internal workflow queue requests.

This would let a user to set env vars for local world, or with nextjs, do ->

 export default withWorkflow(nextConfig, {
    workflows: {
      embedded: {
        baseUrl: process.env.WORKFLOW_BASE_URL ?? "https://localhost:3001"
      },
    },
  });

[pranaygp]

sounds good to me! i think we should do it but cc @Schniz too for a second opinion but

there's a config spec RFC I need to write for long term thinking on configuration etc. but i think we can ship a fix here and iterate

[pranaygp]

thanks so much @eersnington

[eersnington]

sounds good to me! i think we should do it but cc @Schniz too for a second opinion but

there's a config spec RFC I need to write for long term thinking on configuration etc. but i think we can ship a fix here and iterate

On it. I'll open a draft PR and tag Gal in that 👍

[NC-DEV-Theo]

Hey @eersnington ,
Huge thanks for all the time you put into this, really appreciate the effort. Your rewrite workaround works perfectly on my side, running two local servers in parallel does the job.

It would still be great if workflows could eventually support an HTTPS base directly, just to avoid running both HTTP and HTTPS servers at once in local dev. For now, your example completely unblocked me. Thanks again for jumping in and building that out so quickly!