Questions

A way to ship desktop apps as one file. An app is a single .krate file, and the Krate player on macOS, Windows or Linux opens it as a native window.

You make apps in Rust, by hand or by describing them to AI in Krate Studio. The person you send one to installs the player once, then double-clicks.

One file instead of a build for every system, and the person you send it to sees what it can touch before it opens.

macOS, Windows and Linux, on Intel and ARM. The same file opens on all of them.

Krate is a desktop platform today; phones are not supported yet.

The app does not call AppKit, Win32, or Linux APIs directly. It calls Krate interfaces, and the Krate player on each operating system translates approved calls into local behavior.

The .krate file carries the WebAssembly component and its requested access. It is one portable app, and the same bytes run on all three desktops.

Krate is the player, like a media player for application files. Its native runtime handles operating-system differences and enforces permissions, so developers can send the same app file to all three desktops.

Install the player once, then open .krate files through it. An app needs a runtime version that supports its interfaces. The opening guide gets you started.

The runtime is free and open source, under MIT or Apache-2.0, and developed in the open on GitHub. Studio has separate licensing; the repository's licence notes say which parts are which.

Rust calls a package a crate, so the similarity is real. Krate uses a different spelling and refers to the portable container that carries an application and its requested access.

We keep the distinction explicit wherever Rust developers could reasonably confuse the two.

WebAssembly is the engine underneath, and it is a good one. Krate is what turns it into an app you can send: one file format, a real window on each desktop, system interfaces, permissions you approve, and sharing.

A browser link works well for web applications. Krate gives developers a file they can distribute directly for local execution. Krate Cloud is optional; an app's own online features still need their services.

An Electron app bundles Chromium and Node.js and uses platform-specific packages. Krate apps share a native runtime rather than bundling a browser per app. See the desktop distribution comparison.

Tauri and Flutter build a separate app for each operating system, and each one is installed on its own. Krate builds one file that opens on every desktop through a player that is installed once and shared by every app.

A Krate app also starts with no access to your files or the network, and asks for what it needs before it opens.

Java made programs portable. Krate also makes the app something you send like a document: one small file, a real window on each desktop, and a list of what it can touch before it opens.

Go builds a separate binary for each system and chip, so three desktops on two kinds of chip means several builds to make and test, and each binary runs with your full rights. A .krate is one file for all of them, and Krate blocks anything the app did not declare.

Cosmopolitan builds one native binary that runs directly on many systems at full speed, which is impressive work. A .krate runs through the Krate player instead, and that is what lets the app ask before it touches your folders, websites and devices, and open as a real desktop window on each system.

Two reasons: portability and control. A WebAssembly component is the same bytes on every system and every chip, so one small file serves macOS, Windows and Linux, on Intel and ARM, with no build per platform.

Krate runs it with Wasmtime, the WebAssembly runtime from the Bytecode Alliance. Code inside it can reach nothing on its own; every call to the outside goes through Krate, which checks it against what the app was granted.

It is closer to the JVM than to a script runner. On the desktop, Wasmtime compiles the app's WebAssembly into native machine code for your processor before it runs, so nothing is interpreted line by line.

A Rust app manages its own memory, the way it does anywhere else, inside a sandboxed block of its own. There is no garbage collector.

No. A Krate app has no web view and no bundled browser engine. The window is a real window of your system; the player draws its contents and runs the app's code as WebAssembly.

Not hidden. The file holds compiled WebAssembly, which is much harder to read than JavaScript but can be disassembled, like any native binary or Java bytecode. Apps made in Studio also carry their source inside the file, so they can be changed later.

What Krate does enforce is what the app can access.

Newer versions of Krate are built to keep opening older apps. If an app needs something your Krate does not have yet, it says what is missing instead of failing silently, and updating Krate fixes it.

Not to make an app with Studio: you describe it, and the AI writes the Rust, builds it and checks it runs. To change the code yourself, yes. Rust is the language for real apps today.

Rust is the language today. The format does not depend on Rust: anything that compiles to a WebAssembly component can run once it has bindings to Krate's interfaces. C and C++ are the likely next ones, because they already compile to WebAssembly well.

Rust today, compiled to a WebAssembly component. Apps use krate:* interfaces for system access rather than wasi:* imports. You can write the code yourself or use AI in Krate Studio.

krate check-app checks compilation, imports and a headless run. It helps catch integration errors; you still test the app's behaviour. Start with the developer quickstart.

The one you already have. Studio on your computer works with Claude, Codex, Grok or Gemini. In the browser, Krate's own AI makes your first app.

Usually a few minutes from a sentence to a working app on a recent Mac, and it then opens in about two seconds. Each change you ask for after that becomes a new version, built the same way.

Yes. The Rust source travels inside the .krate file. In Studio, the Files and Code tabs show it, and the IDE (in beta) lets you edit and run it. Prefer your own editor? The krate command line builds and packages.

Krate exposes interfaces for desktop UI, drawing, storage, networking and other system resources. The capability and limits reference records what is implemented and the boundaries to check for your app.

For examples you can inspect, see the app gallery and repository inventory.

Yes, over HTTP and WebSockets. Network access is granted per host and port: the app names the hosts it needs, and you see them before it opens. An app that asks for none cannot reach the network at all.

Yes. Each app has its own key-value store, SQL database and secret store, plus a shared store that syncs across machines. A key-value entry holds up to 1 MiB, and an app's key-value store up to 16 MiB.

Yes. Apps get a canvas, GPU drawing, audio, and keyboard and pointer input, which is what 2D games need. Demanding 3D games are early.

krate port reads your project and reports what maps cleanly, what needs a capability, and what will not work. It is read-only: it never builds, runs or edits your source.

Reusable application logic is a good starting point. UI code and direct operating-system calls need Krate interfaces, and dependencies must support the WebAssembly target. The porting guide walks through the process.

The same way you send any file: attach it to an email, drop it in a chat, or put it on a drive. You can also publish it and share the link. The person opens it with Krate.

Small, because it carries only the app. The notes app we measured is 36.6 KiB. Apps made in Studio are usually tens to a few hundred kilobytes, and that includes their source.

The player is installed once, and every app shares it.

Yes. An app runs on your computer from its file. Only an app that uses the network needs a connection, and only to the hosts it was granted.

We measured a Krate notes app against MarkText, an Electron editor, on the same 50,000-line document on an Apple M4: 178.5 MiB of memory against 2,299.4 MiB, and a visible window in 237.1 ms against 611.5 ms, the median of ten opens.

The method, the machine and the raw results are on the measurements page.

Only harmless things: open its window, draw, play sound, read the clock and your language settings, and show a dialog. Your files, the network, the camera, the microphone and its own storage each have to be declared by the app, and you see that list before it opens.

The runtime checks protected calls at the boundary, so the list is not only something the app writes about itself: if the app tries a checked call that was not granted, the call is denied before it reaches the operating system. The limits page lists the gaps.

If a required permission is denied, the app refuses to start and explains what is missing.

Only what it was granted, such as a folder of its own, and any file you choose for it in a dialog. There is no way for an app to read everything, by design.

Not a full one today. An app works inside a folder of its own and with files you choose for it; it cannot browse your whole disk, by design. A file tool that works in the folders you hand it is fine.

Each server is declared with its port, such as api.example.com:443, and an app can list as many as it needs. A wildcard like *.example.com covers one level of subdomain: api.example.com, not a.b.example.com.

WebSockets use the same grant. Redirects are not followed, so a granted server cannot send the request somewhere you did not approve. An app cannot ask for more while it runs; anything new comes in its next version, and you see it before that version opens.

No, it adds a layer. Your operating system still checks the Krate player itself; Krate then decides what each app inside it may touch.

No. An app is running or it is not; nothing outlives its window. An app also cannot type into other applications or click in them.

Not yet. The capability boundary is working and useful, but Krate is young and we are not claiming production hardening against hostile third-party code today.

Open apps from people you know, or from the gallery. The current limits and threat model are public.

In your browser, Krate's own AI makes one app for you and one change to it, and we pay for it. No API key, no card, nothing to install.

Only an app that is actually made counts. A build that fails, or that we could not finish, costs you nothing and you can try again.

The app is a file, and it stays yours: open it, publish it, send it to anyone.

To keep making, use Krate Studio on your own computer, which is free and unlimited with the AI you already use. Or add your own API key in Studio's settings in the browser and keep going there.

Not to open apps. Not to make apps in Krate Studio on your own computer, either; there you only sign in to publish.

Making an app in the browser does need one, so your free app is counted once and your work is kept. Sign in with GitHub, Google or a link sent to your email.