NOW IN PUBLIC BETA · v0.9

A Linux filesystem built for machines that never stop changing.

alberry brings instant snapshots, self-healing integrity, and live resizing to every workload — from a single edge node to a fleet of Kubernetes clusters.

BUILT FOR

Kubernetes nodes Bare metal Edge / IoT CI runners Database hosts
format.sh
snapshot.sh
status.sh
mkfs.alberry /dev/nvme0n1
alberry-utils 0.9.2
device: /dev/nvme0n1 (1.92 TB)
block size: 4096 bytes
checksum: blake3
compression: zstd (transparent)
✓ filesystem created in 1.4s
mount /dev/nvme0n1 /data
✓ mounted read-write, journal replayed (0 entries)
alberry snapshot create --tag pre-migration
volume: /data
mode: copy-on-write
✓ snapshot "pre-migration" created in 38ms
alberry snapshot list
TAG CREATED SIZE
pre-migration 2s ago 0 B (COW)
nightly-0300 14h ago 1.1 GB
alberry status /data
health: OK
used: 842 GB / 1.92 TB
compression: 1.7x average
checksum errs: 0 (auto-healed: 3, last 30d)
scrub: scheduled in 6h
The problem

Storage hasn't caught up to how you actually deploy.

ext4 and xfs were designed for machines that stay put. Enterprise SAN/NAS solves scale but drags in cost and complexity most teams don't need.

ext4 / xfs

  • No native snapshots
  • Offline resize only
  • Silent bit-rot goes undetected
  • No built-in compression

Enterprise SAN / NAS

  • Solves it, at 6-figure cost
  • Dedicated storage team required
  • Proprietary management plane
  • Overkill below petabyte scale

alberry

  • Instant COW snapshots, built in
  • Live resize, no downtime
  • Self-healing checksums by default
  • Transparent compression, one CLI
Features

Everything the kernel should have shipped with.

One filesystem, one CLI, no bolt-on tooling.

Instant snapshots

Copy-on-write snapshots complete in milliseconds regardless of volume size — take one before every deploy.

Self-healing checksums

Every block is checksummed with BLAKE3. Corruption is detected and repaired automatically from redundant copies.

Live resize

Grow or shrink a mounted volume with zero downtime — no unmount, no reboot, no maintenance window.

Transparent compression

Zstd compression applied at the block layer, invisible to applications, typically 1.5–2.5x on real workloads.

🔒

Encryption at rest

Per-volume AES-256 encryption with key rotation, managed through the same CLI you use for everything else.

Unified CLI / API

One binary for format, mount, snapshot, and scrub operations — plus a gRPC API for automation and orchestration.

Use cases

Wherever storage state gets complicated.

Containers

Kubernetes persistent volumes

Snapshot stateful sets before every rollout and roll back a volume as fast as you roll back a deployment.

Databases

Point-in-time recovery

Take a consistent snapshot before migrations and schema changes without taking the database offline.

Edge / IoT

Resilient remote nodes

Self-healing checksums catch flash-media corruption on remote hardware nobody can walk up to.

CI / CD

Disposable build volumes

Clone a golden snapshot for every build runner in milliseconds instead of re-provisioning disks.

Data & AI

Dataset versioning

Snapshot training datasets alongside model checkpoints so every run is exactly reproducible.

Hosting

Multi-tenant isolation

Per-tenant volumes with independent quotas, encryption keys, and snapshot schedules on shared hardware.

Architecture

Copy-on-write, from the block layer up.

alberry is built around a B-tree metadata layer and a copy-on-write allocator, the same family of design as ZFS and Btrfs, tuned specifically for fast local NVMe and predictable resource use on small hosts.

Every write is checksummed before it's acknowledged. A background scrubber walks the tree on a schedule you control and repairs any block that fails verification using redundant metadata.

  • Written in Rust, no kernel patches required (FUSE + native module)
  • Snapshots are metadata-only until blocks diverge
  • Scrub, balance, and resize run online, never blocking I/O
SPECIFICATION
Block size4 KiB – 64 KiB
ChecksumBLAKE3
Compressionzstd, lz4
Journal modewrite-ahead, async
Snapshot modelcopy-on-write
EncryptionAES-256-XTS
Max volume size256 TiB
InterfaceFUSE / native module
LicenseApache 2.0
Media-aware I/O

Same filesystem, tuned to the disk underneath.

alberry batches writes differently depending on what it's talking to — sequential bursts to spare a spinning platter, fanned-out parallel writes across NAND channels on flash.

Traditional HDD

Mechanical seek — one write at a time, latency dominated by head movement.

Solid-state (SSD)

Parallel NAND channels — many writes complete simultaneously, no moving parts.

Try alberry on your next server.

Linux x86_64 / arm64 · kernel 5.10+

curl -sSL https://get.alberry.tech | sh

Prefer a package? .deb · .rpm · source tarball