WebAssembly (WASM) is one of those technologies that feels like it should change how we build backend services — but the real question is: how well does it actually work in practice?
I recently tried building and deploying a WASM-based Pixel Art Generator on OSC My Apps using Codex and the OSC MCP Connector. This post walks through the process, what worked smoothly, and where things got a bit messy.
If you haven’t worked with WASM before, the idea is pretty simple. Instead of running your backend in a full container, you compile it into a small, sandboxed binary that can run almost anywhere. Compared to containers, WASM apps start almost instantly, are lightweight and portable, and run in a secure sandbox. That makes them especially interesting for serverless and edge workloads.
For this experiment, I built a simple HTTP API in Rust. The app exposes a GET /health endpoint and a POST /pixelate endpoint that takes an image and returns a pixelated version. I used Codex to generate most of the initial structure, which made getting started surprisingly fast.
To build the app, I first added the WASM target:
rustup target add wasm32-wasip1
Then I compiled the project:
cargo build --target wasm32-wasip1 --release
To run it locally, I used Spin:
spin up
This gave me a local server at http://127.0.0.1:8080, and I could verify everything worked with:
curl http://127.0.0.1:8080/health
At this point, everything behaved like a normal backend — just powered by WASM instead of a traditional runtime.
Frontend app running locally
Next came deployment. The intended workflow was to push the project to GitHub, use Codex together with the OSC MCP Connector, deploy it through OSC My Apps, and then verify that the endpoint was live.
Codex actually handled a lot of this quite well. It was able to create a My App from the GitHub repository, inspect logs and status, and restart the service. The workflow from code to deployment felt smooth and well integrated at this stage.
However, this is where things started to break.
Even though the app deployed and the service was reachable, the API didn’t behave correctly. The issue turned out to be that the WASM module generated with Spin wasn’t compatible with OSC’s current runtime expectations. In practice, this meant that my /health and /pixelate endpoints didn’t work the way they did locally.
Intial error that I got when deploying through OSC
Another limitation I ran into was that the MCP Connector doesn’t currently support running spin build, and there’s no direct way to deploy a Spin-based app through MCP. This creates a mismatch between local development, where Spin works great, and deployment, where it doesn’t translate cleanly yet.
To work around this, I asked Codex to refactor the app to remove Spin entirely. This version did deploy successfully, but it came with tradeoffs. Instead of returning raw images, the app returned base64-encoded JSON. The routing model also changed, exposing only a single generic WASM execution endpoint. As a result, my original /health and /pixelate endpoints couldn’t be preserved.
Deployed backend app on OSC after the fixes
So while the deployment technically worked, it didn’t behave like the original API anymore.
That said, there were still things that worked really well. Codex was great for generating the Rust and WASM code, and it significantly sped up development. The OSC MCP Connector was also useful for creating apps, inspecting logs, and managing deployments. The overall flow from writing code to attempting deployment felt smooth.
Where things required extra effort was in understanding the differences between Spin and raw WASM execution, figuring out what OSC’s runtime actually expects, and adapting the app to fit those constraints.
Overall, WASM as a backend runtime is genuinely exciting. The idea of shipping a small, fast, portable service without containers feels like a natural next step. But right now, there’s still a gap between building locally with tools like Spin and deploying to platforms like OSC. Once that gap is closed, this could be a really powerful workflow.
If you want to experiment with WASM deployments yourself, you can try it here:
If you’ve tried deploying WASM apps in production, I’d be curious to hear how it went — especially if you ran into similar issues.
Here is the link to the deployed frontend app: https://a5ccefa8b3.apps.osaas.io
Final deployed frontend app on OSC
Top comments (1)
Hi Vincent — thanks for writing this up. Honest, specific developer feedback like this is exactly what moves the platform forward.
You nailed the root cause: OSC's wasm-runner uses WasmEdge (WASI _start entry point), not Spin/Wasmtime. That distinction isn't documented anywhere today, and that's on us. We've filed issues to add clear warnings in the catalog, README, and My Apps flow.
We've also filed an issue for raw binary HTTP response support — you shouldn't have to base64-encode image output. And the MCP connector build-step gap (no spin build) is by design (security boundary), but we're adding documentation so the next developer knows to build locally first.
If you're interested, we'd love to help you get multi-endpoint routing working natively with WasmEdge for a Part 2. Happy to jump on a call or chat in our community Slack.
Thanks again for putting this out there. — Alex, Eyevinn