Stlite runs your Python code on Pyodide, a CPython runtime compiled to WebAssembly. Pyodide’s underlying runtime, Emscripten, provides a virtual file system that your Python code interacts with through the standardDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/whitphx/stlite/llms.txt
Use this file to discover all available pages before exploring further.
open() call and the os / pathlib modules — just as it would with a real file system. When Stlite starts your app, it mounts your source files onto this virtual file system automatically.
Default File System (MEMFS)
By default, Emscripten usesMEMFS — an in-memory file system. Any files your Python code creates or modifies at runtime exist only in memory and are lost when the application is closed or restarted. This is fine for temporary computation but unsuitable for storing user data, preferences, or any output that needs to persist.
To retain data across restarts, you can use one of two persistence mechanisms: IndexedDB-backed storage (IDBFS) or direct host OS file system access (NODEFS).
IndexedDB Persistence (IDBFS)
IDBFS mounts a virtual directory that is backed by the browser’s (or Electron’s) IndexedDB storage. Files written to an IDBFS-mounted path are serialised to IndexedDB and automatically restored the next time the app starts. Data is stored inside Electron’s app-data directory on the user’s machine.Enabling IDBFS
Add theidbfsMountpoints field to stlite.desktop in your package.json, then re-run npm run dump:
Accessing IDBFS in Python
Once mounted, you can use the path exactly like any ordinary directory in Python:/mnt/persistent directory is IDBFS-backed, counter.txt will still be there the next time the user opens the application.
IDBFS works without
nodeJsWorker: true. It is backed by Electron’s IndexedDB implementation and does not require access to the host OS file system.Local File System Access (NODEFS)
NODEFS maps a directory on the host operating system into the Pyodide virtual file system. This gives your Python code direct read/write access to real files on the user’s machine — for example, their home directory, a project folder, or a shared network drive.Requirements
NODEFS requires the NodeJS worker mode to be enabled. This shifts Pyodide’s execution from the renderer process’s sandboxed Web Worker into a NodeJS worker thread in Electron’s main process, where Node.js file system APIs are available.Configuration
Set bothnodeJsWorker: true and nodefsMountpoints in your package.json:
nodefsMountpoints field is an object where each key is a virtual file system path and each value is the corresponding host OS path. In the example above, "." (the current working directory of the Electron process) is accessible inside Python at /mnt/local.
Path Placeholders
Hard-coding absolute host OS paths is fragile across different user machines. Instead, use placeholder variables that Stlite resolves at runtime using Electron’sapp.getPath:
| Placeholder | Description | Example (Linux) |
|---|---|---|
{{home}} | User’s home directory | /home/alice |
{{userData}} | App-specific user data directory | /home/alice/.config/my-app |
{{temp}} | System temporary directory | /tmp |
app.getPath can be used as a placeholder by wrapping it in double curly braces.
Accessing Host Files in Python
With the configuration above, Python code reads and writes host OS files through the virtual paths:/mnt/home/example.txt is immediately reflected as ~/example.txt on the user’s actual machine.
Security Considerations
Comparison of Worker Modes
| Default Web Worker | NodeJS Worker (nodeJsWorker: true) | |
|---|---|---|
| Execution context | Sandboxed Chromium renderer | Node.js main process |
| Host file system access | ✗ Not available | ✓ Via NODEFS |
| Sandbox | ✓ Browser sandbox | ✗ No sandbox |
| Privilege level | Browser (restricted) | Full Node.js (OS-level) |
| Recommended for | Most apps | Apps requiring direct file I/O |