What if your operating system was designed to forget by default?

Most conventional operating systems are designed around persistence. They remember your files, application history, caches, configurations, network activity, and previous sessions. This is convenient for everyday computing, but there are situations where leaving less information behind is a fundamental requirement.

Privacy should not depend entirely on individual application settings. It should be considered at the operating system level.

Today, we're excited to introduce Snigdha OS Decentralize, a new initiative from the Snigdha OS project focused on building a privacy-first, security-oriented Linux operating system.

Our goal is ambitious: develop an Arch Linux-based live operating system that combines amnesic computing, fail-closed network privacy, encrypted persistence, application isolation, and verifiable software supply chains into one integrated environment.

And we've just published our first public release candidate.

Welcome to Snigdha OS Decentralize.

What is Snigdha OS Decentralize?

Snigdha OS Decentralize is an independent Arch Linux-based live operating system designed around privacy, anonymity, and security-conscious computing.

It isn't simply another Arch Linux distribution with a different desktop theme and a collection of preinstalled applications.

We are building an integrated security architecture where the operating system itself participates in enforcing privacy boundaries.

The project brings together several major subsystems:

Snigdha Amnesia: Volatile, RAM-backed operating system sessions.
Snigdha NetGuard: System-wide Tor traffic enforcement and fail-closed networking.
Snigdha Persistence: Optional encrypted storage using LUKS2 and Argon2id.
Snigdha Isolation: Application confinement using Bubblewrap, AppArmor, seccomp, and D-Bus filtering.
Snigdha Security Center: A centralized interface for system security management.
Snigdha Penetration Center: A curated environment for authorized security testing.
Verified Boot and Supply Chain: Cryptographic boot integrity and verifiable release artifacts.

These components are designed to work together rather than operate as unrelated applications.

Amnesia: An operating system designed to forget

Snigdha Amnesia is one of the most important components of this project.

The fundamental idea is simple: the default live session should not leave normal operating system changes behind after shutdown.

Instead of allowing the writable root filesystem to modify the underlying storage directly, Snigdha OS uses a read-only system image with a volatile OverlayFS upper layer backed by RAM.

The architecture looks conceptually like this:

 SNIGDHA AMNESIA Read-only system image | v OverlayFS | +-------+-------+ | | v v Read-only layer Writable layer (EROFS) (RAM / tmpfs) | v Live session | v System shutdown | v Volatile session discarded

This means ordinary session changes, application caches, temporary files, and user configuration changes are intended to disappear when the system shuts down.

The architecture also includes:

RAM-backed volatile filesystem layers.
Disabled swap and hibernation.
Protection against unintended internal disk mounting.
Early-boot checks for critical filesystem invariants.
Shutdown-time memory sanitization measures.
A watchdog mechanism for removable-media events.

Amnesia is not just a cleanup script. It is integrated into the boot process, initramfs, filesystem layout, system services, and shutdown lifecycle.

The objective is to make session volatility a system-level property.

NetGuard: Network privacy enforced at the kernel level

Installing Tor Browser is not equivalent to protecting the entire operating system's network traffic.

A terminal application, background daemon, package manager, or another application could still attempt to connect directly to the internet.

This is the problem Snigdha NetGuard is designed to address.

NetGuard uses Linux nftables rules to enforce a Tor-oriented networking policy across the operating system.

Its core principle:

Applications should either use the approved Tor network path or have their traffic blocked.

The architecture includes:

Transparent TCP redirection through Tor.
Dedicated DNS handling.
nftables-based network enforcement.
Fail-closed behavior when Tor becomes unavailable.
IPv6 and UDP leakage controls.
Tor circuit isolation for different classes of applications.
Secure time synchronization over Tor-routed connections.

We are also integrating support for Tor bridges and pluggable transports.

Depending on the installed transport clients, the system can support:

Standard Tor bridges.
obfs4.
Snowflake.
WebTunnel.
Additional runtime-detected transports.

Users can explicitly control the Tor connection lifecycle through the desktop interface and command-line tooling.

An important design decision is that network connectivity should not silently fall back to ordinary direct internet access when Tor fails.

When the network security boundary is unavailable, the intended behavior is to block traffic rather than silently weaken the privacy configuration.

Encrypted persistence: Keep what matters, forget everything else

A completely volatile operating system is useful, but users sometimes need to retain selected information across sessions.

That's why we developed Snigdha Persistence.

Instead of making the entire operating system persistent, we provide an optional encrypted storage mechanism based on:

LUKS2.
AES-XTS encryption.
Argon2id key derivation.
Selective persistence mounts.
Encrypted header backups.
Recovery and lifecycle management.

Users can selectively preserve data such as:

Personal documents.
SSH identities.
GnuPG keyrings.
Application configurations.
Authorized security-testing configurations.

The rest of the operating system can remain volatile.

We consider this distinction important. Persistence should be an explicit decision, not an unavoidable default.

There is also an important security consideration: persistence protects stored data while locked, but it does not protect unlocked files from a compromised active session. Persisting long-term identities can also make sessions more linkable.

Our documentation addresses these operational boundaries rather than presenting encryption as a universal security solution.

Application isolation and sandboxing

Application isolation is another major part of our security architecture.

Traditional Linux permissions alone are not always sufficient when dealing with untrusted applications.

Snigdha Isolation combines several Linux security mechanisms:

Applications can receive restricted filesystem views, isolated process namespaces, limited system interfaces, and controlled network access.

The objective is to reduce the damage an application can cause if it becomes compromised.

We also want to be transparent about the current desktop architecture.

The present i3wm edition uses X11. X11 has an inherent shared-display trust model, meaning sandboxed graphical applications that access the host display can potentially observe or interact with other windows.

Filesystem and process sandboxing do not eliminate this limitation. We document it explicitly rather than claiming complete graphical application isolation.

Security engineering requires acknowledging what a system cannot currently protect against.

Verified boot and software supply-chain integrity

A security-focused operating system should not only consider what happens after boot.

It should also consider whether the system being booted can be trusted.

Snigdha OS integrates multiple layers of boot and release integrity:

Unified Kernel Images (UKI)

The kernel, initramfs, and boot configuration are packaged into a unified boot artifact designed for cryptographic verification.

UEFI Secure Boot

Signed boot artifacts establish a cryptographic trust relationship during the boot process.

dm-verity

A Merkle-tree-based integrity mechanism protects the read-only root filesystem against unauthorized modifications.

Software Bill of Materials (SBOM)

Release artifacts include an SPDX 2.3 software bill of materials describing packaged software components.

Build provenance

We include SLSA v1.0 / in-toto provenance artifacts to improve build traceability.

OpenPGP signatures

Release artifacts and associated verification metadata are accompanied by cryptographic signatures.

Our objective is to make release integrity independently verifiable instead of asking users to blindly trust a download link.

A desktop designed around productivity

Security doesn't mean sacrificing usability.

Snigdha OS currently uses a lightweight, keyboard-driven i3wm desktop environment with the Everblush visual palette.

The desktop includes:

i3 window management.
Picom compositor.
Polybar.
Rofi application launcher.
Kitty and Alacritty terminals.
Dunst notifications.
Thunar file manager.
Native GTK4 security-management interfaces.

We have also integrated dedicated shortcuts for important system components, making it possible to manage security-related operations without navigating through multiple unrelated applications.

Two particularly important applications are:

Snigdha Security Center

A centralized interface for monitoring and managing important system security components.

Snigdha Penetration Center

A curated environment for security auditing and authorized penetration-testing workflows.

The Penetration Center includes a categorized security-tool ecosystem with documentation and ethical usage considerations.

We want security management to feel like a coherent part of the operating system rather than a collection of disconnected scripts.

Built on Arch Linux, with an independent architecture

Why Arch Linux?

We wanted a distribution foundation that gives us control over packages, system configuration, kernel integration, and the overall build process.

ArchISO provides the foundation for building the live image, while our own engineering work handles the privacy and security subsystems.

The project uses a combination of:

Bash for system integration and build orchestration.
Python for selected system services and tooling.
Rust for native system applications and security-related components.
GTK4 for desktop interfaces.
systemd for service lifecycle management.
nftables for network enforcement.
Linux namespaces and security mechanisms for confinement.

We are not simply maintaining a collection of desktop customizations.

We are developing an independent operating system architecture and the applications required to manage it.

The first public Release Candidate is available

We have published Snigdha OS Decentralized 2026.11.13-rc1.

Release information

Release: "2026.11.13-rc1"
Tag: "v2026.11.13-rc1"
Architecture: "x86_64"
Release channel: Candidate
ISO size: Approximately 1.4 GiB
License: GPL-3.0-or-later

Download and explore:

"Download Snigdha OS Decentralize — Release Candidate 1" (https://gitlab.com/SnigdhaOS/decentralize/iso/-/releases/v2026.11.13-rc1)

"Explore the ISO repository" (https://gitlab.com/SnigdhaOS/decentralize/iso)

Verify before booting

Please do not skip release verification.

Download the ISO, checksum manifests, signing key, and detached signatures from the official release.

For example:

Import the release signing key

gpg --import release-signing-key.asc

Verify the checksum manifest signature

gpg --verify SHA256SUMS.sig SHA256SUMS

Verify the ISO checksum

sha256sum -c SHA256SUMS --ignore-missing

Verify the ISO's detached signature

gpg --verify \
snigdhaos-decentralize-2026.11.13-x86_64.iso.sig \
snigdhaos-decentralize-2026.11.13-x86_64.iso

Before trusting the signing key, independently confirm its published fingerprint:

2BDB 00AE 6CAB EF0E 4052
0A8F 553F D42B 02A8 211A

For complete instructions, consult the "official release verification guide" (https://gitlab.com/SnigdhaOS/decentralize/iso/-/blob/v2026.11.13-rc1/docs/getting-started/RELEASE-VERIFICATION.md).

Transparency: What this release is, and what it isn't

We want to be very clear about the current development status.

Snigdha OS Decentralized is currently a Release Candidate, not a stable production release.

Our internal engineering and verification milestones have been completed to the project's current release-candidate requirements. However, the project's release governance explicitly blocks stable promotion until an independent, accredited third-party security audit has been completed.

There are also documented security limitations, including the shared X11 display boundary and risks associated with unlocked persistent storage.

We encourage developers, Linux enthusiasts, privacy researchers, and security professionals to evaluate the project, inspect its source code, and provide feedback.

However, this release candidate should not be treated as an independently audited anonymity solution or relied upon for high-risk operational security.

We believe being transparent about security limitations is more valuable than making impressive but unverified marketing claims.

We want the open-source community involved

Snigdha OS Decentralize is an open-source engineering effort.

We don't want this project to develop in isolation.

There are several areas where community contributions can make a meaningful difference:

Linux kernel and initramfs engineering.
Tor integration and network security.
Rust system applications.
Linux application sandboxing.
LUKS2 and encrypted storage management.
Secure boot and boot-chain verification.
Hardware compatibility testing.
Documentation and reproducible builds.
Security reviews and responsible vulnerability disclosure.

You can start by exploring our repositories and reading the project documentation.

Project resources:

"Snigdha OS Decentralize — GitLab Group" (https://gitlab.com/SnigdhaOS/decentralize)
"ISO and system architecture" (https://gitlab.com/SnigdhaOS/decentralize/iso)
"Documentation repository" (https://gitlab.com/SnigdhaOS/decentralize/docs)
"Official website" (https://decentralize.snigdhaos.org)
"Documentation portal" (https://decentralize.snigdhaos.org/docs)

To build the operating system from source on an Arch Linux host:

git clone https://gitlab.com/SnigdhaOS/decentralize/iso.git

cd iso

Validate the build environment

make check-host

Execute the automated test suites

make test

Build the live ISO

make build

Verify release outputs

make release-verify

Please read the contribution guidelines before submitting changes:

"Contributing to Snigdha OS Decentralize" (https://gitlab.com/SnigdhaOS/decentralize/iso/-/blob/v2026.11.13-rc1/CONTRIBUTING.md)

What's next?

The Release Candidate is an important milestone, but it is not the end of the project.

Our continued development priorities include refining the security architecture, expanding hardware compatibility, improving the desktop experience, strengthening application isolation, improving release infrastructure, and preparing for independent external security evaluation.

We also want to keep growing the surrounding Snigdha OS ecosystem, including its documentation, system utilities, and developer tooling.

Our long-term objective is to build an operating system where privacy and security are architectural considerations rather than optional application-level features.

Final thoughts

Privacy-focused operating systems are not built by adding a browser, a VPN, and a few security tools to an existing desktop.

They require careful decisions throughout the entire system: from boot and memory management to network routing, application execution, storage, and software distribution.

That is the direction we are taking with Snigdha OS Decentralize.

We are building it openly, documenting the architecture, publishing verifiable release artifacts, and inviting the community to participate.

The first public release candidate is available. The next chapter is about making the architecture stronger through testing, review, and collaboration.

Explore the project, test it in a controlled environment, inspect the code, and tell us what you think.

Let's build a more privacy-conscious Linux ecosystem together.

— Eshan Roy

"GitLab" (https://gitlab.com/SnigdhaOS/decentralize) · "Website" (https://decentralize.snigdhaos.org) · "Documentation" (https://decentralize.snigdhaos.org/docs)