From ef7735d681648637aaaadbcf38ca061db4e09c34 Mon Sep 17 00:00:00 2001
From: Eddie Nielsen <“ed”@edcore.dk”>
Date: Sat, 21 Mar 2026 22:37:01 +0000
Subject: [PATCH] docs: finalize README with logo and structure

---
 README.md | 195 +++++++++++++++++++++++++++++++++---------------------
 1 file changed, 120 insertions(+), 75 deletions(-)

diff --git a/README.md b/README.md
index 300d452..1366df8 100644
--- a/README.md
+++ b/README.md
@@ -2,12 +2,30 @@
   <img src="images/dockervault-logo.png" alt="DockerVault logo" width="840">
 </p>
 
+<br>
+
 <p align="center">
   <b>Simple, reliable backups for Docker environments.</b>
 </p>
 
 ---
 
+## 📑 Contents
+
+* [🚀 What is DockerVault?](#-what-is-dockervault)
+* [✨ Goals](#-goals)
+* [⚙️ Technology](#-technology)
+* [🏗 Architecture](#-architecture)
+* [📦 What DockerVault backs up](#-what-dockervault-is-expected-to-back-up)
+* [🔁 Restore philosophy](#-restore-philosophy)
+* [🧩 Planned Features](#-planned-features)
+* [🛣 Roadmap](#-roadmap)
+* [📁 Project Structure](#-project-structure)
+* [🤝 Philosophy](#-philosophy)
+* [📜 License](#-license)
+
+---
+
 ## 🚀 What is DockerVault?
 
 DockerVault is a CLI-first backup system for Docker environments.
@@ -22,12 +40,12 @@ DockerVault is aimed at homelabs, self-hosted infrastructure, and small-scale se
 
 DockerVault is being built to:
 
-- Discover Docker containers automatically
-- Identify volumes, bind mounts, and relevant configuration data
-- Keep track of backup history and metadata
-- Use a proven backup backend instead of reinventing backup logic
-- Make restore operations easier and safer
-- Stay simple enough to understand and debug
+* Discover Docker containers automatically
+* Identify volumes, bind mounts, and relevant configuration data
+* Keep track of backup history and metadata
+* Use a proven backup backend instead of reinventing backup logic
+* Make restore operations easier and safer
+* Stay simple enough to understand and debug
 
 ---
 
@@ -37,18 +55,18 @@ DockerVault is planned as a modular, CLI-first tool.
 
 ### Current design direction
 
-- **Core language:** Python
-- **Backup engine:** BorgBackup
-- **Metadata storage:** SQLite
-- **Interface:** CLI first
-- **Platform focus:** Linux Docker hosts
+* **Core language:** Python
+* **Backup engine:** BorgBackup
+* **Metadata storage:** SQLite
+* **Interface:** CLI first
+* **Platform focus:** Linux Docker hosts
 
 ### Why this stack?
 
-- **Python** makes it fast to build, maintain, and extend
-- **BorgBackup** is mature, reliable, and well-suited for deduplicated backups
-- **SQLite** keeps metadata simple, local, and easy to inspect
-- **CLI first** keeps the project transparent and easy to debug
+* **Python** makes it fast to build, maintain, and extend
+* **BorgBackup** is mature, reliable, and well-suited for deduplicated backups
+* **SQLite** keeps metadata simple, local, and easy to inspect
+* **CLI first** keeps the project transparent and easy to debug
 
 The project philosophy is clear: use proven tools where it makes sense, and avoid building complexity just for the sake of it.
 
@@ -73,11 +91,11 @@ More detailed architecture notes will live in `docs/architecture.md`.
 
 DockerVault is intended to focus on the parts of Docker environments that actually matter:
 
-- Docker volumes
-- Bind mounts
-- Selected configuration files
-- Backup metadata
-- Restore-related information
+* Docker volumes
+* Bind mounts
+* Selected configuration files
+* Backup metadata
+* Restore-related information
 
 It is not intended to blindly copy everything without structure. The purpose is to know what is being backed up and why.
 
@@ -89,12 +107,12 @@ Backups are only useful if restore is realistic.
 
 DockerVault is being designed with restore in mind from the beginning:
 
-- Clear mapping between containers and stored data
-- Metadata that explains what belongs to what
-- Predictable restore flow
-- Minimal guesswork during recovery
+* Clear mapping between containers and stored data
+* Metadata that explains relationships between services and data
+* Predictable restore flow
+* Minimal guesswork during recovery
 
-The long-term goal is not just to create archives, but to support actual recovery when needed.
+The goal is not just to store backups, but to enable actual recovery.
 
 ---
 
@@ -102,81 +120,108 @@ The long-term goal is not just to create archives, but to support actual recover
 
 ### Core features
 
-- Docker container discovery
-- Volume detection
-- Bind mount detection
-- Backup job creation
-- Borg-based backup execution
-- SQLite-based metadata tracking
-- Restore workflow
+* Docker container discovery
+* Volume detection
+* Bind mount detection
+* Backup job creation
+* Borg-based backup execution
+* SQLite-based metadata tracking
+* Restore workflow
 
 ### Future possibilities
 
-- Scheduled backups
-- Retention policies
-- Pre-backup and post-backup hooks
-- E-mail notifications
-- `ntfy` notifications
-- Web interface
-- Multi-node support
-- Remote repository support
-- Backup health/status reporting
-- Configuration profiles
-- Selective backup policies per container
+* Scheduled backups
+* Retention policies
+* Pre/post backup hooks
+* E-mail notifications
+* `ntfy` notifications
+* Web interface
+* Multi-node support
+* Remote repository support
+* Backup health/status reporting
+* Configuration profiles
+* Selective backup policies per container
 
 ---
 
 ## 🛣 Roadmap
 
 ### Phase 1 – Foundation
-- Repository structure
-- Documentation
-- CLI skeleton
-- Initial project design
+
+* Repository structure
+* Documentation
+* CLI skeleton
+* Initial project design
 
 ### Phase 2 – Discovery
-- Scan Docker environment
-- Detect containers
-- Detect volumes and bind mounts
+
+* Scan Docker environment
+* Detect containers
+* Detect volumes and bind mounts
 
 ### Phase 3 – Backup Engine
-- Integrate BorgBackup
-- Build backup job flow
-- Store metadata in SQLite
+
+* Integrate BorgBackup
+* Build backup job flow
+* Store metadata in SQLite
 
 ### Phase 4 – Restore
-- Basic restore workflow
-- Restore metadata mapping
-- Safer recovery process
+
+* Basic restore workflow
+* Restore metadata mapping
+* Safer recovery process
 
 ### Phase 5 – Usability
-- Better CLI commands
-- Config handling
-- Scheduling support
-- Notifications
+
+* Better CLI commands
+* Config handling
+* Scheduling support
+* Notifications
 
 ### Phase 6 – Expansion
-- Web interface
-- Multi-node support
-- More advanced backup policies
+
+* Web interface
+* Multi-node support
+* Advanced backup policies
 
 ---
 
 ## 📁 Project Structure
 
-Planned structure:
-
 ```text
 dockervault/
-├── cmd/          # CLI commands
-├── core/         # core logic
-├── scanner/      # Docker discovery
-├── backup/       # backup engine integration
-├── restore/      # restore logic
-├── config/       # configuration handling
-├── database/     # SQLite handling
-├── docs/         # project documentation
-├── scripts/      # helper scripts
-├── images/       # logos and visual assets
+├── cmd/
+├── core/
+├── scanner/
+├── backup/
+├── restore/
+├── config/
+├── database/
+├── docs/
+├── scripts/
+├── images/
 ├── README.md
 └── LICENSE
+```
+
+---
+
+## 🤝 Philosophy
+
+DockerVault is built on a few simple principles:
+
+* Keep it simple
+* Be transparent
+* Avoid unnecessary complexity
+* Prefer proven tools over hype
+* Build something practical and maintainable
+
+No magic. No hidden behavior. No unnecessary abstraction.
+
+---
+
+## 📜 License
+
+This project is licensed under the **GNU General Public License v2.0**.
+
+See the `LICENSE` file for details.