Skip to content
rConfig V8 Core Documentation rConfig V8 Core Documentation rConfig V8 Core Documentation

Git-First Storage for Configurations in rConfig V8 Core

After reading this page, you can explain how rConfig V8 Core stores device configurations on disk, and how to put that data directory under Git version control yourself so every backup becomes a tracked, diffable commit. Git is an optional layer you add around rConfig, not a feature you switch on inside it.

How V8 Core stores configurations

Section titled “How V8 Core stores configurations”

rConfig V8 Core writes every captured configuration to a plain text file in a hierarchical directory structure, then records a reference to that file in the database. Each backup is a new, timestamped file, so the directory itself already holds a full history of every version rConfig has ever collected.

The on-disk layout is organised by category, device, and date:

/storage/app/rconfig/data/
  └── [Category Name]/
      └── [Device Name]/
          └── [YYYY]/
              └── [MMM]/
                  └── [DD]/
                      └── [command-name]_[timestamp].txt

Because configurations live as ordinary text files in a predictable tree, that directory is a natural fit for Git. Pointing a Git repository at it turns rConfig’s append-only file history into a commit history you can branch, diff, and clone with standard tooling. This is what “Git-first storage” means in the context of V8 Core: you bring your own Git workflow around the data directory.

Why version the data directory with Git

Section titled “Why version the data directory with Git”

Putting /storage/app/rconfig/data/ under Git gives you a few things the filesystem alone does not:

  • A distributed copy of the configuration history. Every clone is a complete backup of the tree.
  • Standard diff and blame tooling for line-by-line history across any time range.
  • Integration with existing Git workflows, so configuration changes can be reviewed, mirrored, or fed into CI pipelines alongside code.
  • A second, independent retention store separate from the rConfig database.

Git complements the built-in backups rather than replacing them. rConfig keeps writing files and database records exactly as it always does. Git simply tracks what changes in the directory over time.

Setting up Git over the data directory

Section titled “Setting up Git over the data directory”

These steps are run on the rConfig server against the existing data directory. They use only standard, upstream Git. None of this is configured inside the rConfig application.

  1. Confirm the data directory path on your install. The default is /storage/app/rconfig/data/.

  2. Initialise a Git repository in that directory:

    Terminal window
    cd /storage/app/rconfig/data
    git init

  3. Stage the current configuration files and create the first commit:

    Terminal window
    git add .
    git commit -m "Initial snapshot of rConfig configuration data"

  4. Schedule a periodic commit so new backups are captured. A cron job that commits any changes after each backup window is the simplest approach:

    Terminal window
    cd /storage/app/rconfig/data && git add -A && git commit -m "rConfig snapshot $(date -Iseconds)" --allow-empty

  5. (Optional) Add a remote and push, so an off-box copy of the history exists:

    Terminal window
    git remote add origin <your-remote-url>
    git push -u origin main

Tamper-evidence and signed commits

Section titled “Tamper-evidence and signed commits”

If you need cryptographic authenticity on top of the directory history, that is a property of your Git setup, not of rConfig. Standard Git supports GPG-signed commits and tags, and most hosting platforms support branch protection and signed-commit enforcement. rConfig V8 Core does not generate or verify commit signatures itself, so any signing, signature verification, or large-file handling is configured and operated by your team using upstream tooling. The relevant upstream references are linked below.

External tooling references

Section titled “External tooling references”

The Git workflow on this page relies entirely on upstream open-source tools. Their official documentation is the authoritative source:

What’s next

Section titled “What’s next”