#11753 b8f3309 Thanks @ruifigueira! - Added the following improvements to local Browser Rendering binding in Miniflare:
#12986 5aaaab2 Thanks @petebacondarwin! - fix: allow mixed d1Databases records containing both string and object entries
Previously, passing a d1Databases config that mixed plain string values and object entries (e.g. { MY_DB: "db-name", OTHER_DB: { id: "...", remoteProxyConnectionString: ... } }) would cause Miniflare to throw an error. Both forms are now accepted and normalised correctly.
#12986 5aaaab2 Thanks @petebacondarwin! - fix: allow mixed kvNamespaces records containing both string and object entries
Previously, passing a kvNamespaces config that mixed plain string values and object entries (e.g. { MY_NS: "ns-name", OTHER_NS: { id: "...", remoteProxyConnectionString: ... } }) would cause Miniflare to throw an error. Both forms are now accepted and normalised correctly.
#12987 f8516dd Thanks @petebacondarwin! - fix: allow mixed pipelines records containing both string and object entries
Previously, passing a pipelines config that mixed plain string values and object entries (e.g. { MY_PIPELINE: "pipeline-name", OTHER_PIPELINE: { pipeline: "...", remoteProxyConnectionString: ... } }) would cause Miniflare to throw an error. Both forms are now accepted and normalised correctly.
#12952 9c9fe30 Thanks @petebacondarwin! - fix: allow mixed r2Buckets records containing both string and object entries
Previously, passing an r2Buckets config that mixed plain string values and object entries (e.g. { MY_BUCKET: "bucket-name", OTHER_BUCKET: { ... } }) would cause Miniflare to throw an error. Both forms are now accepted and normalised correctly.
#13015 6a6449e Thanks @petebacondarwin! - fix: disable undici Pool request timeouts for local dev
Miniflare's undici Pool instances were using the default headersTimeout and bodyTimeout of 300 seconds (5 minutes). Any request taking longer than that — streaming responses, large uploads, long-polling, or compute-heavy Workers — would be silently killed with a "request failed" error.
Setting both timeouts to 0 disables them entirely, which is the correct behaviour for a local development tool where there is no reason to enforce request timeouts.
Fetched March 26, 2026