Git instead of a database
"Everything is Git" describes the architectural rule behind Everlock. This article is the more mechanical version of that idea. What does it actually mean to build application storage on top of bare G
Documentation
Tag: storage
Everything is Git
Everlock starts with a fairly unreasonable constraint: > Everything that matters should live in Git. Not just the source code for Everlock. The data managed by Everlock. Photos. Calendars. Configurati
Everlock 0.8.0
The 0.8.0 release adds file shares: a versioned store mounted as a network drive over WebDAV, from Finder, Windows Explorer, a Linux file manager, or `rclone`. Every change is a commit, so a share's h
WebDAV behavior and storage reference
This page covers Everlock's WebDAV behavior and the storage model behind it. - served through `frontend-http` - multi-share and multi-vhost, each share on its own mount path - one dedicated `versioned
Git history retention
A repository that collects build artifacts, uploads, or generated data grows forever, and a large file committed once keeps costing disk long after it was deleted. Everlock can bound that: a repositor
Versioned storage
Versioned storage is Everlock's internal persistence primitive. Every backend that needs to store state — site content, user records, mail, uploaded files, system configuration — uses it. It is a key-
Shared primitives
Everlock's architecture is built on a small set of reusable primitives. These are not optional conveniences; they are the common foundation that backend families are expected to reuse. Git-backed stor