Arch, with a way back.
SakuraOS is an Arch based Linux distribution that ships with KDE Plasma as the desktop, a suite of custom built applications, and a tuned kernel and scheduler selected for modern hardware, with a standard kernel fallback for older processors.
Installing it is not a technical exam. No desktop selection, no bootloader decision, no filesystem comparison, no kernel choice. The system detects what your hardware supports, applies the sensible defaults, and is ready to use when you boot.
Scroll
The idea
A rolling release means current software as it ships. There is no next version to migrate to, because the system never stops moving — no upgrade night, no major-version migration, no finding out in the morning what the jump broke.
The cost is that a bad update, a half-finished command, or an unreviewed build script can leave you at a black screen, and the fix is written for people who already know how to chroot from a live USB.
That is the barrier SakuraOS is built to remove. The model was never the hard part. Recovery was assumed knowledge.
SakuraOS keeps the model and adds the way back.
Try it
Every distribution says it is stable. Here is what actually happens on SakuraOS when an update goes wrong.
What's in the box
What makes SakuraOS special is its core applications, the ones that make using Linux a breeze. Each is there so you can work, game or build without opening a terminal you didn't want to open.
Reads what you're about to run and stops the commands that break Arch systems: partial upgrades, removing the last kernel, force-removing glibc. Every check can be overridden; you just have to read the message first.
Ten short questions, each one saying what it will do rather than naming the thing it configures. It sets up the disk, the restore points, the boot menu and Secure Boot without asking you to understand any of them first, and shows you the work as it happens.
Updates handled for you, on a schedule you set, with a restore point taken first, and a plain-English list of what's actually changing.
One place for repository packages, Flatpaks and the AUR, with the source of every app stated plainly instead of buried.
Windows software runs through Wine, installed the first time you open something that needs it rather than sitting on the disk from the day you install. It is close to a gigabyte with its runtimes, so the switch in Settings turns it off again and takes the gigabyte with it. Turning it off is the half that usually goes missing.
The AUR has been used to ship malware -- Arch reported a high-volume campaign in June 2026 and more in July -- and the packages, files and services from each one get published afterwards. SakuraOS checks what you have installed against those published lists, inside pacman, after every install and upgrade. It runs whether you installed from the store or typed yay yourself. It cannot catch a campaign nobody has reported yet, which is why the AUR is off until you turn it on and why the build script is shown to you first.
Turn the AUR on with one click, with yay already there as the helper. The same place holds the rest of what makes the system yours: what Terminal Assist blocks, when updates install, whether Windows applications are set up at all.
SakuraOS builds the CachyOS kernel, the scheduler work that makes an Arch desktop feel quick, and puts its own defaults on top. We add memory and writeback limits, an I/O scheduler picked per drive, and compressed swap in RAM so a machine with 8 GB stays usable.
Terminal Assist
Immutable distributions have real advantages, but sometimes you need to get work done in the terminal without the operating system standing in your way. Terminal Assist is the middle ground: the system stays fully writable, while commands known to break an Arch installation are caught before they do damage.
When a command trips a rule, Terminal Assist explains what is wrong, shows the safer alternative, and gives you the exact override if you really meant to do it.
You still own the system. Terminal Assist just makes it harder to break by accident.
The important checks run inside pacman itself. That means they still apply whether a package operation starts in the terminal, a script, an AUR helper, or the App Store.
The shell layer is there to catch mistakes early and explain them. The pacman hook is what actually stops a dangerous transaction.
Terminal Assist has a little over thirty rules for commands and package operations that are known to cause trouble on Arch. It is not there to decide what you are allowed to do. If a rule stops something, it tells you why and shows you how to override it.
You can also change how Terminal Assist behaves in Settings. It can block dangerous commands, only warn you about them, or be disabled completely.
Updates
Falling months behind on a rolling release is more dangerous than updating often: one enormous transaction, unread manual steps, and known holes left open the whole time. So SakuraOS updates itself.
Updates are tested on our machines before they reach yours. One of ours installs everything pending, reboots, and re-runs the same checks a fresh install has to pass. When it does not survive, that update is held back on your machine instead of breaking it.
Nothing is held on a schedule. Delay packages for weeks and you get the other problem: the AUR builds against current Arch, your system isn't current Arch, and everything you install from it starts failing. A hold here needs evidence, so it lasts exactly as long as the problem does and not a day longer.
Nobody knows what libjxl is. So the list says: JPEG XL image support, needed by Dolphin, Gwenview, Firefox. An update you can actually consent to.
BTRFS took a restore point before it ran. Pick Recovery at the boot menu and you're back. It can be done by someone who has never heard of a chroot.
The AUR
The Arch User Repository is why you can install almost anything on Arch without hunting for a package. SakuraOS gets that, and it isn't hidden behind a config file or a wiki page.
It's off on a fresh install, because it's build scripts written by other users that nobody reviews, and you haven't agreed to that yet. Turning it on is one checkbox in Settings. Right there, no ceremony.
Off by default. One click away. Never hidden.
The AUR has been used to ship malware, and when it happens the packages, the files they drop and the services they install get published. SakuraOS checks what you have installed against every campaign on record. The check runs inside pacman, after every install and every upgrade, and sweeps the whole system weekly besides. Exact matches, not guesswork.
A scanner only knows about attacks somebody already reported, so it can't be the only thing standing there. Before a package builds you see what the script does, what changed since the version you last accepted, and the signals that matter: a maintainer who changed last week, a package adopted three days ago, a download that isn't coming from the project.
Performance
SakuraOS uses the same kernel scheduling work as CachyOS, whose tuning is why people run it on modern hardware. On a recent CPU you get every bit of it.
And if you don't have a recent CPU? Chasing performance often means dropping older hardware quietly. There's one image, standard x86-64, and a first-generation i7 runs exactly the same one a Ryzen 9000 does. Nothing to work out before you download.
Fast on new hardware. Still works on old.
Hardware
| Graphics | Your card is detected during install and the right driver goes on: nvidia-open for RTX and GTX 16-series and newer, and for older GeForce cards the last driver NVIDIA ever shipped for them, which we rebuild and maintain ourselves because NVIDIA no longer will. AMD and Intel work out of the box. |
| Secure Boot | Set up during install, with keys generated on your machine. Most Arch-based distributions tell you to switch it off in firmware. That's where a lot of people quietly give up. |
| Memory | Compressed swap in RAM by default, so a laptop with 8 GB and a browser open stays usable instead of having something killed. |
| Older CPUs | Standard x86-64, so a first-generation i7 runs the same image a Ryzen 9000 does. No separate build to choose, nothing to work out before downloading. |
Privacy
Not minimised. Not anonymised. Not off by default. There is no telemetry in SakuraOS to switch off, because none was ever put in.
Your machine, your data, your business.
Plasma is made by KDE, and they can accept anonymous information about your hardware and which features you use. It is how they find bugs nobody reports. SakuraOS keeps the option rather than stripping it out: off unless you turn it on, and it goes to KDE, never to us. KDE's privacy policy says what they collect.
Free and open source throughout: every package we build, the installer, and the whole build pipeline. Nothing here is locked down to keep you safe from yourself. You can read it, change it, or take it apart.
Get SakuraOS
No desktop edition, no gaming edition, no "which kernel" question.
Write it to a USB stick of 8 GB or more using
balenaEtcher,
Rufus, or
the dd command.
Verifying the download
The checksum catches a broken download. The signature catches a fake one.
curl -LO https://repo.sakuraos.org/iso/sakura-latest-x86_64.iso
curl -LO https://repo.sakuraos.org/iso/sakura-latest-x86_64.iso.sha256
curl -LO https://repo.sakuraos.org/iso/sakura-latest-x86_64.iso.sig
curl -LO https://repo.sakuraos.org/sakura-signing-key.asc
sha256sum -c sakura-latest-x86_64.iso.sha256
gpg --import sakura-signing-key.asc
gpg --verify sakura-latest-x86_64.iso.sig sakura-latest-x86_64.iso
A good signature names
SakuraOS Signing Key <packages@sakuraos.org>,
fingerprint 6F45 296E DBF1 C57A E762 26E7 131E 22D5 8CBD 7EE6