daedalOS: a desktop environment in the browser, built on Next.js and BrowserFS

What daedalOS actually solves, and for whom

daedalOS is a desktop environment that runs entirely inside a browser tab. The README describes it as a "Desktop environment in the browser" and the package.json names the project daedalos at version 2.0.0 under the MIT licence. It reconstructs the familiar pieces of a desktop OS: a file explorer, resizable and draggable windows, a start menu, a taskbar with window peek previews, a clock, wallpapers and a screensaver. The audience is narrow but real. Developers who want a working reference for window management, virtual file systems and Web Workers in a single codebase can read it. Retro-computing users who want to run DOS games or 16/32-bit Windows applications without installing a virtual machine get a zero-install option through js-dos and BoxedWine. Anyone expecting a general-purpose operating system replacement will be disappointed, because the environment is a web application and its storage is browser storage.

How the file system, windows and workers fit together

The file system is the load-bearing part. daedalOS uses BrowserFS, and the README states that writes go to IndexedDB. That means the desktop's files survive a page reload but live in the browser's origin-scoped database, not on disk in a way other applications can read. The build step generates a JSON index of the bundled public files: the package.json shows build:fs:public running scripts/fs2json.js with --exclude .index,private and --out public/.index/fs.9p.json ./public. A private variant exists for a private directory. This is how the environment presents a populated file system on first load. Windows are handled by react-rnd for resizing and dragging, with Framer Motion for open and close animations, and the README notes that window size, position and maximized state persist. The clock is a Web Worker drawing to an OffscreenCanvas, and the animated wallpapers use the same OffscreenCanvas plus Web Worker combination. That choice keeps animation off the main thread, which matters because the desktop is otherwise a React application competing for the same thread. The taskbar's peek preview uses html-to-image to render window thumbnails. The Run dialog launches apps by alias or path and can open ipfs: and nostr: URIs.

Installing daedalOS locally and loading a file by URL

The repository is a Next.js project managed with Yarn. The package.json exposes dev, build and serve scripts, and the README does not document a separate install section, so the standard Yarn flow applies. Clone the repository, install dependencies, then start the development server. The dev script runs next dev, which serves the environment on the default Next.js port.

yarn install
yarn dev

For a production build, the build script runs a prebuild step and then next build. The prebuild step runs scripts/robots.js, scripts/rssBuilder.js, scripts/searchIndex.js, scripts/preloadIcons.js, scripts/cacheShortcuts.js and the public file-system indexer, so it does more than compile code.

yarn build
yarn serve

The Dockerfile gives the shortest path if you do not want a local Node toolchain. It uses node:22-alpine, installs git, copies the repository, runs yarn and yarn build, and starts with yarn serve. The package.json defines docker:build and docker:run, with the run command publishing port 3000.

docker build -t daedalos .
docker run -dp 3000:3000 --rm --name daedalos daedalos

Once the environment is open, the URL query parameters are the first real feature to try. The README gives the examples /?url=/CREDITS.md and /?app=Browser, so loading a specific file or launching a named app is a matter of editing the address bar rather than clicking through the interface.

Where daedalOS breaks down or is the wrong tool

The storage model is the sharpest limitation. Because writes go to IndexedDB, the file system is tied to one browser profile on one machine. Clearing site data removes the files. There is no documented sync, backup or export path in the README, and no server-side component that would let two people share a directory. The README also does not document rollback for the emulator save states that js-dos writes to /Users/Public/Snapshots, so treat those as local conveniences. Performance is another boundary: the desktop, the window animations, the wallpapers and the clock all run in the browser, and the README's own design choices (Web Workers, OffscreenCanvas) exist because the main thread is a constrained resource. On low-end hardware or in a tab competing with other work, that shows. Finally, the app list is a set of embedded emulators and viewers, not native applications. If you need a real shell, real process isolation or real file permissions, this is the wrong layer.

daedalOS compared with a cloud desktop like Kasm Workspaces

The closest conceptual alternative is a container-streamed desktop such as Kasm Workspaces, which runs a real Linux desktop in a container and streams pixels to the browser. The difference in approach is total. daedalOS ships the desktop logic to the client and stores state in the browser; Kasm runs the desktop on a server and treats the browser as a display. That means Kasm gives you real Linux applications, real persistent volumes and multi-user access, at the cost of running and securing server infrastructure. daedalOS gives you a single-page application you can host as static output, with no server-side session, but its file system is only as durable as the browser's IndexedDB and its applications are browser ports. A second comparison is a plain web-based IDE such as a hosted VS Code instance: it solves editing and terminals well but has no window manager, no start menu and no desktop metaphor, which is precisely what daedalOS is built to demonstrate.

Maintenance, build cost and the MIT licence

The repository is not archived, and the last push was on 2026-09-05, so it is currently being worked on. That is a statement about commit activity, not about release cadence: no recent releases were retrieved, and the package.json still declares version 2.0.0. The build is heavier than a typical static site. Because build:prebuild regenerates the robots file, the RSS feed, the search index, preloaded icons, cached shortcuts and the public file-system JSON, a full build touches several generated artifacts, and the Dockerfile pays that cost inside the image build. Upgrades are managed with yarn upgrade-interactive --latest through the update script, which is interactive and therefore not suitable for unattended dependency bumps. The licence is MIT, which is permissive and places few obligations on redistribution, but the bundled applications carry their own licences: EmulatorJS, js-dos, BoxedWine, jspaint, Monaco Editor and others are separate projects with their own terms. Review those before shipping a build commercially. This is not legal advice.

Editorial conclusion

Adopt daedalOS if you want a self-contained browser desktop demo, a teaching artifact for Next.js and BrowserFS, or a sandbox for running DOS and Windows binaries without a VM. Do not adopt it if you need durable storage, multi-user access, or a production shell for real work; the file system lives in IndexedDB and the whole environment is a single-page app. Before committing, verify that your browser supports the File System Access API and IndexedDB, and check whether the Docker image's node:22-alpine base and yarn build step complete on your network.

Frequently asked questions

Official sources

1. DustinBrett/daedalOS on GitHub
2. Issues
3. License: MIT
4. Project website
5. README