Secrets stay separate
Logical references such as secret://github/personal keep configuration definitions apart from secret material.
OPEN SOURCE · CONCEPT STAGE
Deliver your setup.
Work anywhere.
Configuration, tools, and credentials included. Define your setup once, then reproduce it safely across machines, projects, CI, and AI agents.
delivery / developer● SECURE
$ dlvy sync
✓Definitionsfetched
✓Configurationresolved
✓Secretsauthorized
TARGETmacbook-work
STATEdeveloper
CHANGES04 planned
$ dlvy apply _
DEFINE ONCE
→DELIVER SAFELY
→WORK ANYWHERE
01 — THE PROBLEM
Dotfiles alone can’t
restore your environment.
A setup state is everything that makes a working environment usable: configuration, tools, credentials, and the rules that decide which values apply. Those parts are scattered across files, machines, projects, and services.
- 01
Your working state lives beyond files.
Environment variables, installed tools, OS keychains, service settings, and runtime processes all shape the environment. Cloning a dotfiles repository restores only the file-based portion.
- 02
The same definition does not win everywhere.
A value may be overridden by a profile, machine, workspace, or project. Copying the source file cannot explain which scope should take precedence on the machine you are restoring.
- 03
Secrets need delivery rules, not file copies.
Credentials must be encrypted, authorized, rotated, and exposed only where they are needed. Putting them in dotfiles is unsafe; omitting them leaves the environment incomplete.
Restoring files is not the same as restoring active state. Setup State Delivery resolves both the value and the reason it applies before delivering it to a target.
02 — ONE STATE, FOUR VIEWS
Know what is active—and why.
Setup State Delivery follows a setting through four concrete stages. This makes it possible to see what was requested, what won, what was written, and what is actually running.
01
Declared
Definitions organized by user, profile, machine, workspace, and project.
02
Effective
The final value after precedence rules and conditions are resolved.
03
Materialized
The file, environment variable, or tool-specific format written for a target.
04
Runtime
The value actually active on the machine or inside the running process.
CORE FEATURE
Every value has a reason.
dlvy explain shows more than a value. It reveals which scope won and which definitions were overridden.
$ dlvy explain editor.fontSize
EFFECTIVE VALUE16
Project/example
16ACTIVEProfile/developer
14SHADOWEDUser
13SHADOWED03 — SECURITY BY DESIGN
Plaintext never leaves
your device.
The server is never trusted with readable secrets. Data is encrypted on your device, transported only as unreadable ciphertext, and decrypted only by a device you have explicitly approved.
YOUR DEVICEPlaintextCLIENT-SIDE
ENCRYPT
SYNC STORECiphertextSERVER CAN’T DECRYPT
DECRYPT
TRUSTED DEVICERuntimeAUTHORIZED
Identity for every device
Each device owns a unique key pair and requires explicit approval from an existing trusted device.
One encryption key per state
Personal, work, and project states use separate keys. When a device is revoked, only the affected state keys need to change.
04 — BUILT FOR PEOPLE & AGENTS
Let AI act—without
revealing your secrets.
Give an agent permission to perform one approved action instead of handing it the credential itself. CLI, API, and MCP all connect to the same configuration and authorization engine.
AI AGENTREQUEST
run_with_secret({
secret: github.personal,
command: "gh pr create"
})✓
Action completedSecret value was never exposed
05 — THE LOOP
A short, reviewable loop.
Sync does not mean overwrite. Create a change plan you can inspect, apply it deliberately, then observe the resulting state.
01DefineDescribe the state
02DeliverSend it safely
03UseWork anywhere
04ObserveDetect drift
05CaptureBring changes back
$ dlvy syncFetch definitions and create a change plan
→$ dlvy diffInspect semantic differences
→$ dlvy applyApply reviewed changes
→$ dlvy statusSee sync health and drift
→$ dlvy captureTurn local changes into candidates
→06 — PROJECT ROADMAP
From an open design
to a working system.
Setup State Delivery is currently a public product and architecture concept. The next goal is a usable reference implementation, followed by secure delivery across more tools and environments.
Product model and security architecture
The configuration hierarchy, delivery model, secret references, device identity, and agent access principles are documented publicly.
Core CLI and resolution engine
Build a reference implementation for defining scopes, resolving effective values, creating change plans, and explaining results.
Adapters and secure delivery
Add target adapters, encrypted secret delivery, device approval, drift detection, and structured interfaces for AI agents.
JOIN THE PROJECT
Join on GitHub ↗Help shape what gets built first.
Review the architecture, challenge an assumption, propose an adapter, or contribute to the first implementation on GitHub.
07 — BUILD IT WITH US
Choose how you want
to move it forward.
Setup State Delivery is at the stage where concrete environments, security constraints, and tool integrations can shape the reference implementation. Follow progress, share the idea, or bring a real use case.
Take your environment
wherever work happens.
Portable. Explainable. Reproducible. Securely deliverable.
Explore the project on GitHub ↗