# SerenityOS: one repository, a QEMU launch, and a spreadsheet that runs JavaScript > SerenityOS is a graphical Unix-like operating system for 64-bit x86, Arm and RISC-V, built by the people who use it, with the kernel, the browser, the toolchain, the package manager and every application in a single repository with no external dependencies. The default build launches a QEMU instance, the man pages are generated from markdown inside the root filesystem, and the browser publishes its JavaScript, CSS and WebAssembly conformance pages rather than asking you to trust it. **SerenityOS/serenity** — The Serenity Operating System 🐞 - Repository: https://github.com/SerenityOS/serenity - Website: https://serenityos.org - Stars: 33,850 · Forks: 3,544 - Language: C++ - License: BSD-2-Clause - Published: 2026-08-17 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/serenityos-serenity ## The kernel, the browser and the chess engine are all in this repository The README makes a claim that is easy to skim past. Everything described above is described as being right in the repository, with no extra dependencies, built from scratch by the authors. Then there are over three hundred ports of popular open-source software, including games, compilers, Unix tools and multimedia applications. The tree shows what that means in practice. AK/ is the package manager, Base/ is the root filesystem, Kernel/ is the kernel, Meta/ holds the port recipes, Ports/ the port sources, Toolchain/ the cross-compilers, Userland/ the applications, services and libraries, Tests/ the test suites, and Ladybird/ the browser, which has its own directory and its own build instructions. The practical consequence is that the unit of work is the repository rather than a component. There is no way to take the browser and leave the operating system, and no way to build a library without a toolchain and a root filesystem around it. That is the trade the project is making, and it is why the build, not the source layout, is where a newcomer's time goes. ## The default build launches QEMU rather than producing an image The build section is short, and the load-bearing sentence is about what happens when you run the commands. The build system supports a cross-compilation build from Linux, macOS, Windows with WSL2 and many other Unix-like systems, and the default build system commands will launch a QEMU instance running the operating system, with hardware or software virtualization enabled as supported. So the expected loop is build, then boot an emulator, and the emulator is part of the default path rather than something you opt into for testing. That is a reasonable choice for a hobby operating system: it removes the need for you to find a bootable image format and a disk-writing tool. It also means your first build needs a working QEMU, and if you want the hardware acceleration rather than the software emulation, you need the host to permit nested virtualization, which is off by default on several platforms. The two build documents to read are Documentation/BuildInstructions.md for the system and Documentation/BuildInstructionsLadybird.md for the browser. The browser is worth calling out separately: Ladybird runs on the same platforms that can host a cross build of SerenityOS, and on SerenityOS itself. ## A spreadsheet whose formulas are JavaScript is the acceptance test The applications list is where the system's ambition becomes concrete. Every-day programs include a Spreadsheet with JavaScript, a TextEditor, a Terminal, PixelPaint, various multimedia viewers and players, Mail, Assistant and a Calculator. Then games, with Solitaire, Minesweeper, 2048, chess and Conway's Game of Life, and demos including CatDog, Starfield, Eyes, a mandelbrot set renderer and a WidgetGallery. A spreadsheet whose formulas are JavaScript is the item that explains the rest. It is not a toy in a demo folder; it is a real application exercising the widget toolkit, the font rendering, the event loop, the file system and the JavaScript engine at the same time, on every run. A regression in any of those layers shows up as a broken spreadsheet before it shows up anywhere else. The WidgetGallery and the HexEditor play the same role as conformance tests, and there is a kernel-supported profiler, a CrashReporter and an interactive GUI playground in the development tools list. Read that as the project's own answer to the question of how you know the system still works: you run the applications, because they are in the same repository and they are built by the same command. ## pledge and unveil are the two calls to look up first The security list is specific rather than aspirational, and it is worth reading closely. The README names hardware protections, limited userland capabilities, W^X memory, pledge and unveil, (K)ASLR, OOM-resistance, web-content isolation and state-of-the-art TLS algorithms. Two of those are syscall-level interfaces you can go and read. pledge restricts what a process may do, and unveil lifts a restriction, so they form a small declarative sandbox model applied at process start rather than a policy engine. W^X means a page of memory is either writable or executable, never both. (K)ASLR is kernel and userspace address space layout randomisation, and OOM-resistance is the set of changes that keep the system alive when memory runs out rather than panicking it. The practical note is where to look. Each of these is implemented in the kernel or in LibC, both of which are in the repository, so the mechanism is available as source rather than as a configuration option. If you are evaluating the security model, start with the pledge and unveil implementation and the web-content isolation work, because those are the two claims that do the most work in a system that also ships a browser and a mail client. ## The browser links its conformance pages instead of claiming compliance The Browser entry is unusual for a README. It links to the application directory, then gives three separate places to check the engine's behaviour: a test262 results page for JavaScript, a site for CSS, and a page for WebAssembly. That is a deliberate choice. A browser project's compliance is a number that decays, because the specifications move, and a README that says the engine is compliant is making a claim you cannot check. Linking the live results means the claim expires visibly, and it tells you which specification level to hold the engine to. The JavaScript engine is also not only for the browser. The Spreadsheet with JavaScript depends on it, as do the services, so the same engine is a platform component rather than a browser feature. If you are following the project for the browser, expect the engine work to continue for its own sake, and read the conformance pages as the way to tell whether a change helped or hurt. ## Three hundred ports are recipes in Meta/, installed with AK/ The port story is a single sentence in the README and three directories in the tree. There are over three hundred ports of popular open-source software, including games, compilers, Unix tools and multimedia apps, and the tree has Meta/ for the recipes, Ports/ for the sources, and AK/ for the package manager that installs them. That structure is what makes a self-hosted operating system usable, and it is also what makes it enormous. A compiler port means a build recipe that has to track a toolchain that is itself being written; a multimedia app means a port of somebody else's code onto a libc that is still changing. Every port is a recurring maintenance obligation rather than a one-time contribution. So the honest way to size SerenityOS is by its ports and its applications, not by its kernel. The compiler ports tell you whether the toolchain is usable, the Unix tool ports tell you whether POSIX compatibility is real, and the game ports tell you whether the graphics stack holds up. A repository that ships three hundred of these is a different proposition from one that ships a browser, and that difference is the project. ## The man pages are generated from markdown inside the root filesystem Documentation is split three ways, and the split tells you where to look for what. Man pages are published online at man.serenityos.org, and those pages are generated from the markdown source files in Base/usr/share/man and updated automatically. Inside a running system you use man for the terminal interface and help for the GUI. Code-related documentation lives in the Documentation/ directory. The arrangement has one advantage worth naming. Because the man page sources are inside the root filesystem, they are versioned with the code they document, and the online copy is generated from that same source rather than written separately. A fork changes the filesystem and the documentation changes with it. It also has a cost for a newcomer. There is no single index of what the system can do in prose; the feature list in the README is the index, and everything below it is a man page or a source directory. Reading Base/usr/share/man is a reasonable way to find out how much of the system is actually specified, and it is more informative than the README's own list. ## Conclusion Use SerenityOS to read a from-scratch operating system where the boundaries are legible: a 64-bit kernel with W^X, (K)ASLR and pledge and unveil, a POSIX-ish userspace, a browser with published conformance pages, and a spreadsheet whose formulas are JavaScript. Do not adopt it as infrastructure, since there are no GitHub releases, no distribution packages, and nothing in the repository that describes a support commitment. Before you build: read Documentation/BuildInstructions.md, expect the build to start QEMU rather than produce an image you can flash, confirm your host can do nested virtualisation if you want hardware acceleration, and pick an architecture from the three named, x86, Arm or RISC-V, because the cross-compilation host list and the target list are not the same set. ## FAQ ### What is SerenityOS? It is a graphical Unix-like operating system for 64-bit x86, Arm and RISC-V computers, which the README describes as a love letter to 1990s user interfaces with a custom Unix-like core. Its stated goal is a marriage between the aesthetic of late-1990s productivity software and the power-user accessibility of late-2000s Unix, and everything it lists is in the repository with no extra dependencies, built from scratch. ### What architectures does SerenityOS support? The README names 64-bit x86, Arm and RISC-V. The feature list adds a modern 64-bit kernel with pre-emptive multi-threading, POSIX-like virtual file systems including /proc, /dev, /sys and /tmp, and the ext2 file system. ### How do I build and run SerenityOS? The build instructions are in Documentation/BuildInstructions.md, with a separate document for Ladybird. The build system supports cross-compilation from Linux, macOS, Windows with WSL2 and many other Unix-like systems, and the default build commands launch a QEMU instance running the operating system, with hardware or software virtualization enabled as supported. ### What is Ladybird in the SerenityOS repository? It is the browser, which has its own directory in the repository and its own build instructions. The README notes that it runs on the same platforms that can be the host for a cross build of SerenityOS, and on SerenityOS itself, and that the browser ships with JavaScript, WebAssembly and more. ### Where are the SerenityOS man pages, and how do I read the documentation? They are published online at man.serenityos.org, generated from the markdown sources in Base/usr/share/man and updated automatically. On a running system you use man for the terminal interface and help for the GUI, and code-related documentation sits in the Documentation/ folder. ### What security features does the SerenityOS kernel have? The README lists hardware protections, limited userland capabilities, W^X memory, pledge and unveil, (K)ASLR, OOM-resistance, web-content isolation and state-of-the-art TLS algorithms. pledge and unveil are the syscall-level interfaces worth reading first, since they form the per-process restriction model the rest of the list builds on. ## Sources - [Official documentation](https://serenityos.org) - [Official README](https://github.com/SerenityOS/serenity#readme) - [Project repository](https://github.com/SerenityOS/serenity) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/serenityos-serenity