[{"_1":2,"_32":-5,"_33":-5},"loaderData",{"_3":4},"routes/_main._index",{"_5":6},"latestPost",{"_7":8,"_9":10,"_11":12,"_13":14,"_15":16,"_26":27,"_28":29,"_30":31},"slug","2025-10-05-yoga-in-cloudflare-workers","title","Yoga Layout Engine in Cloudflare Workers in 2025","description","Running Facebook's Yoga layout engine in Cloudflare Workers for server-side layout calculations and OpenGraph image generation at the edge.","date","2025-10-05","tags",[17,18,19,20,21,22,23,24,25],"2025","cloudflare-workers","edge-computing","javascript","layout-engine","opengraph","wasm","web-development","yoga-layout","content","

I would like to run @vercel/og or similar to generate OpenGraph images in Cloudflare Workers. @vercel/og uses satori to convert a layout to svg. And satori uses yoga for the internal layout calculations. However, getting the latest yoga to run in Cloudflare Workers is still tricky.

The Problem: Workers WASM Constraints

Cloudflare Workers has strict requirements for WebAssembly instantiation. Unlike other runtimes, Workers doesn't support compiling WASM from arbitrary data blobs. You must import it as a module:

import yogaModule from './yoga.wasm' // WebAssembly.Module\n

For comparison, you could produce a WebAssembly.Module in Node.js with WebAssembly.compile(fs.readFile()) and browsers with WebAssembly.compileStreaming(fetch()).

On the positive side, the @cloudflare/vite-plugin, as of 2025, also supports Cloudflare's special syntax by importing via either .wasm or .wasm?module. (There was a time where it did not support this and it was even harder to use wasm in Cloudflare Vite projects.)

Historical Solutions

Yoga 3.0 introduced inline base64 WASM bundling, but this format is incompatible with Workers. Previously, I used shuding/yoga-wasm-web, which was designed for web environments and worked well in Workers. Unfortunately, it hasn't been updated since 2023.

The ecosystem is fragmented. Even Satori (Vercel's SVG generator) now uses an inline patched version of yoga-layout instead of yoga-wasm-web. Many Yoga forks get abandoned over time, making long-term maintenance challenging.

Technical Deep Dive

Yoga is built with emscripten, and the config flag causing Workers incompatibility is SINGLE_FILE=1, which inlines the WASM binary in the JavaScript wrapper.

To make Yoga Workers-compatible, you would also need to override emscripten's instantiateWasm() function. The yoga-wasm-web fork demonstrates this pattern:

import wrapAsm from './yoga/javascript/src_js/wrapAsm.js'\nimport yoga from './tmp/yoga.mjs'\n\nexport default async function (wasm: WebAssembly.Module) {\n    const mod = await yoga({\n        instantiateWasm(info, receive) {\n            WebAssembly.instantiate(wasm, info).then((instance) => {\n                if (instance instanceof WebAssembly.Instance) {\n                    receive(instance)\n                } else {\n                    receive(instance.instance)\n                }\n            })\n        },\n    })\n    return wrapAsm(mod)\n}\n

The abandoned worker-emscripten-template suggests a similar approach:

import yogaModule from './yoga'\n\nlet emscripten_module = new Promise((resolve, reject) => {\n    emscripten({\n        instantiateWasm(info, receive) {\n            let instance = new WebAssembly.Instance(yogaModule, info)\n            receive(instance)\n            return instance.exports\n        },\n    }).then((module) => {\n        resolve({\n            init: module.cwrap('init', 'number', ['number']),\n            resize: module.cwrap('resize', 'number', ['number', 'number']),\n            module: module,\n        })\n    })\n})\n

Current State & Options

Creating a Workers-compatible Yoga build requires two changes:

Remove the SINGLE_FILE=1 flag to generate separate WASM files
Create a custom wrapper providing instantiateWasm

The yoga-wasm-web fork has a clean design. It's a lightweight repo with the main yoga as a submodule, overriding compilation and providing platform-specific wrappers. However, maintaining a personal fork just for this use case seems tedious.

Conclusion

While Yoga in Cloudflare Workers is technically feasible, the ecosystem fragmentation makes it challenging to maintain. Cloudflare has a non-standard way of loading wasm, and emscripten yoga and satori all seem not particularly interested in supporting this approach.

","excerpt","I would like to run @vercel/og or similar to generate OpenGraph images in Cloudflare Workers. @vercel/og uses satori to convert a layout to svg. And satori uses yoga for the internal layout...","readingTime",3,"actionData","errors"]

Hi, I'm Patrick Miller

Full-stack Software Engineer based in Kyoto, Japan