<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: VincentKumaar</title>
    <description>The latest articles on DEV Community by VincentKumaar (@vincentkumaar).</description>
    <link>https://dev.to/vincentkumaar</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3750565%2Ff695b9e2-3c79-4dab-a9cd-101da9d3d001.png</url>
      <title>DEV Community: VincentKumaar</title>
      <link>https://dev.to/vincentkumaar</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/vincentkumaar"/>
    <language>en</language>
    <item>
      <title>I Tried Deploying a WASM App on OSC My Apps with Codex — Here’s What Worked (and What Didn’t)</title>
      <dc:creator>VincentKumaar</dc:creator>
      <pubDate>Tue, 24 Mar 2026 09:50:24 +0000</pubDate>
      <link>https://dev.to/vincentkumaar/i-tried-deploying-a-wasm-app-on-osc-my-apps-with-codex-heres-what-worked-and-what-didnt-15g1</link>
      <guid>https://dev.to/vincentkumaar/i-tried-deploying-a-wasm-app-on-osc-my-apps-with-codex-heres-what-worked-and-what-didnt-15g1</guid>
      <description>&lt;p&gt;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?&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;To build the app, I first added the WASM target:&lt;/p&gt;

&lt;p&gt;rustup target add wasm32-wasip1&lt;/p&gt;

&lt;p&gt;Then I compiled the project:&lt;/p&gt;

&lt;p&gt;cargo build --target wasm32-wasip1 --release&lt;/p&gt;

&lt;p&gt;To run it locally, I used Spin:&lt;/p&gt;

&lt;p&gt;spin up&lt;/p&gt;

&lt;p&gt;This gave me a local server at &lt;a href="http://127.0.0.1:8080" rel="noopener noreferrer"&gt;http://127.0.0.1:8080&lt;/a&gt;, and I could verify everything worked with:&lt;/p&gt;

&lt;p&gt;curl &lt;a href="http://127.0.0.1:8080/health" rel="noopener noreferrer"&gt;http://127.0.0.1:8080/health&lt;/a&gt;&lt;br&gt;
At this point, everything behaved like a normal backend — just powered by WASM instead of a traditional runtime.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fo2uqofqizniavnkrc154.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fo2uqofqizniavnkrc154.png" alt="App with frontend running locally" width="800" height="591"&gt;&lt;/a&gt;&lt;br&gt;
Frontend app running locally&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;However, this is where things started to break.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fxg56jsp9p3640vo59bb1.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fxg56jsp9p3640vo59bb1.png" alt="Inital error" width="800" height="489"&gt;&lt;/a&gt;&lt;br&gt;
Intial error that I got when deploying through OSC&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F3sjso5gdumq36y61mcwk.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F3sjso5gdumq36y61mcwk.png" alt=" " width="800" height="511"&gt;&lt;/a&gt;&lt;br&gt;
Deployed backend app on OSC after the fixes&lt;/p&gt;

&lt;p&gt;So while the deployment technically worked, it didn’t behave like the original API anymore.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;If you want to experiment with WASM deployments yourself, you can try it here:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://app.osaas.io" rel="noopener noreferrer"&gt;https://app.osaas.io&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Here is the link to the deployed frontend app: &lt;a href="https://a5ccefa8b3.apps.osaas.io" rel="noopener noreferrer"&gt;https://a5ccefa8b3.apps.osaas.io&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fiovqdnqkqt3flz8p6oqa.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fiovqdnqkqt3flz8p6oqa.png" alt="Deployed frontend app" width="800" height="413"&gt;&lt;/a&gt;&lt;br&gt;
Final deployed frontend app on OSC&lt;/p&gt;

</description>
      <category>webassembly</category>
      <category>rust</category>
      <category>cloud</category>
      <category>devops</category>
    </item>
    <item>
      <title>Creating an app for Open Source Cloud(OSC) by Eyevinn technology</title>
      <dc:creator>VincentKumaar</dc:creator>
      <pubDate>Tue, 03 Feb 2026 12:58:34 +0000</pubDate>
      <link>https://dev.to/vincentkumaar/creating-an-app-for-open-source-cloudosc-by-eyevinn-technology-3ll6</link>
      <guid>https://dev.to/vincentkumaar/creating-an-app-for-open-source-cloudosc-by-eyevinn-technology-3ll6</guid>
      <description>&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fz1xvy755u8ghkgnh1tu8.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fz1xvy755u8ghkgnh1tu8.png" alt=" " width="800" height="428"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I created a web app using OpenAI Codex that allows users to log and track their gaming activity. The main purpose of the app is to provide a quick and simple way for users to keep track of the games they play, as well as discover new games they might enjoy. The app is divided into several pages: Home, Search, Library, and Profile. Through the Profile page, users can add friends and select their top five games, similar to Letterboxd.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fygf87p5o2rvy21fl344d.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fygf87p5o2rvy21fl344d.png" alt=" " width="800" height="430"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The app currently uses the MariaDB service from OSC to store user data, including user profiles, saved games, and friend connections.&lt;br&gt;
Developing and uploading the app to “My Apps” on OSC was a smooth process with the help of Codex. Almost all steps, from deploying the app on OSC to connecting it to MariaDB, were handled through prompting Codex. The only part Codex initially struggled with was setting up the parameter store for managing secrets. However, once the parameter store was configured, Codex was able to manage it without issues.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fu1o5xce9g3qso2txxomy.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fu1o5xce9g3qso2txxomy.png" alt=" " width="800" height="323"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fbfpgul8raxeo85ethe4f.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fbfpgul8raxeo85ethe4f.png" alt=" " width="800" height="401"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The development process itself went very smoothly. Building an app like this on my own would likely have taken several months, but with the help of an agentic AI, the development was significantly faster, easily ten times faster, if not more. There were a few minor hiccups where Codex didn’t fully do what I intended, which was likely due to unclear or insufficient prompts on my part.&lt;/p&gt;

&lt;p&gt;Overall, OSC made it easy to manage both the app and its connected services.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>webdev</category>
      <category>cloud</category>
    </item>
  </channel>
</rss>
