I built a runtime that runs Tauri apps in the browser — no server, no backend, just a URL

[main jolt]

I've been building something I think this community would find interesting — R1, a runtime that lets Tauri apps run in the browser with no server required.

🔗 Live demo: https://r1-todo-demo.netlify.app/
📦 Source: https://github.com/12errh/r1-tauriweb-runtime-v1

The idea: take your existing Tauri app (Rust backend + JS frontend), run npm run build with the R1 Vite plugin, deploy the output as a static site. End users visit a URL and your app just works — no installer, no download.

How the Rust backend runs in the browser:

• Compiled to WASM via wasm-pack, runs in a dedicated Web Worker
• WASI shim intercepts std::fs calls → redirects to OPFS (files persist across refreshes)
• IPC bridge patches window.__TAURI_INTERNALS__ → your invoke() calls work unchanged
• Rust → JS event bridge for emit / listen
• Serde JSON bridge for complex data passing

Current status: 31/31 tests passing, todo demo working end-to-end. Works well for simple/medium Tauri apps. Heavy native deps won't work (can't spawn real processes in a browser).

Would love for people to try running their own Tauri apps through it and tell me what breaks — that's the best way to find the gaps. Happy to answer any questions about the architecture! 🦀

[gilded arrow]

Whaaat that's so crazy😅👍

[main jolt]

did it help full or not

[gilded arrow]

It's interesting
Not sure if I need it

[main jolt]

currently it can be use as. if user want to showcase its app with zero installation. like if user just click on the url and you it can use you dektop app.

[gilded arrow]

Ok nice use case👍

In my case, my app is a saas product first then I am making it a desktop app with the same front end code, so it doesn't apply
But it's a good idea

[fierce gate]

I'm interested in this! Let me look at the source code and see how you did it. I run my Tauri app demo in the browser at https://seaquel.app/demo. I'll share my feedback in a bit

[fierce gate]

Very interesting, I like the wasm approach. That was my initial idea as well, but didn't get to it and instead opted for a more lightweight solution along the lines of this:

/**
 * Get the database provider for the current environment.
 * Returns TauriDatabaseProvider in desktop app, DuckDBProvider in browser.
 */
export async function getProvider(): Promise<DatabaseProvider> {
  if (provider) return provider;

  if (isTauri()) {
    const { TauriDatabaseProvider } = await import("./tauri-provider");
    provider = new TauriDatabaseProvider();
  } else {
    const { DuckDBProvider } = await import("./duckdb-provider");
    provider = new DuckDBProvider();
  }

  return provider;
}

Wasm for my SQL app specifically won't work for everything given wasm limitations to open connections to database engines. However, I'd love to replace my isTauri() and two providers approach with R1. I'll keep an eye on SQLite support.

[strong silo]

That's so cool!
I may use this approach for bridging golang with tauri

[main jolt]

Hey Mike — thanks for taking the time to actually read the source, that kind of feedback means a lot.

Your isTauri() dual-provider pattern is exactly the pain point R1 is trying to eliminate. The fact that you independently arrived at the WASM approach and then had to abandon it because of database connection limits tells me SQLite support is the right next priority.

I'm planning SQLite via VFS for v0.3 — the idea is rusqlite compiled to WASM with file I/O redirected to OPFS, so your Rust database code works unchanged in the browser. No isTauri() check needed.

Would you be up for testing it against seaquel.app when that's ready? Your app is exactly the kind of real-world case I need to verify it against — a SQL tool with actual database connections is a much harder test than a todo app.

I'll tag you when v0.3 is out if you're interested.

[main jolt]

Hey Jacob — theoretically yes, the WASM layer is language-agnostic at the binary level. If Go compiles to wasm32-wasi the IPC bridge should work the same way. I haven't tested it but I'd be very curious what you find. If you try it, open an issue and let me know what breaks — that would be useful data.

[fierce gate]

Yes absolutely, tag me, DM me, send me a letter via mail, anything to get my attention to help test that and get rid of isTauri() 🙂

[main jolt]

Haha noted — you're on the list 😄

Seriously though, having a real SQL app to test against is exactly what I need. The todo demo is too simple to find the hard bugs.

I'm currently on v0.2 which closes the API compatibility gaps (fs, path, event, dialog, window all getting proper direct exports). After that v0.3 is SQLite via VFS — rusqlite compiled to WASM, file I/O goes through OPFS, your Rust database code stays unchanged.

When that's ready you'll hear from me. In the meantime if you want to follow progress the repo is at https://github.com/12errh/r1-tauriweb-runtime-v1 — all the work is happening in the open.

[fierce gate]

Sounds like a plan. I'm ready to test any time and see what is needed to make things work. I like the R1 approach over my currnet provider pattern

[main jolt]

i am continuously updating things. and testing it with smok test and test on demos. if you can please folloe the get-started guide on my git hub and follow instruction and see if it run the defult tauri app on the web with the greet function working. in my case it works. but i want to know how it performe on other devices.

[fierce gate]

I'll give that a go this week

[main jolt]

ok

[quasi trellis]

Nicee! I already thought about running a Tauri app directly in the browser but I didn't think somebody was on it already 😁 I'll definitely try this and let you know

[main jolt]

thanks

[main jolt]

it is in development you can check it roadmap for all info

[main jolt]

hi! i just complete its v0.2. you can look at it. i also add skill and promts in it. if you use ai agent like claude code or any just paste the migration promt it will automaticaly reday the app for web. also it have promts for debug and ai guides.

[quasi trellis]

Cool!

Still haven't tried it yet

[undone seal]

dude you have no idea how helpful this will be to me tysm 🙏 🙏 I want to learn more about tauri, but I need to create a website project for one of my classes, but I want to make it super elaborate and complex because I'm the star student and its fun. So this way I can kill 2 birds with one stone!

[main jolt]

appriciat. but can you tell what do you want to make so i can tell you is it suitable to you or not. becaue it is under development.

[undone seal]

Sure, as a general idea I was thinking of making a web app search engine for some kind of topic that’ll be determined later, kind of like a google search for animal pics or certain galaxy formations

[main jolt]

how much days you have

[undone seal]

I was thinking in making it in from the idea it could be like a nature website, each photo would have its own information and description of the content

Oh about a month

[main jolt]

ok. why not react or next.js

they suite better to you project. like you want to make an web base search engine. tauri only works when you want to make it desktop native. and if you want only web app like pwa. every framwork have there plugin to conver you app into an pwa.

[undone seal]

Because I was thinking of using meilisearch as the engine and I saw it works in rust

So figured it would be e more practice

Oh wait, I probably should have read the docs more, cuz they have a react quick start😅

[main jolt]

ok you can use tauri as you wraper. like if you know react then write all you app logic in react and just rust as a wraper that complie you app as a native desktop app. by it you can get insane performance and you do not need to know much rust. and rust is very complex. you can use ai to write you code.

[undone seal]

Okay, doesn’t sound too bad, I know a little of react so thats good, and if it shouldnt use much rust then I’ll totally be fine