Configuration
Understanding the Datakraften YAML config structure in depth
Quick summary
Datakraften uses a single YAML file at ~/.config/datakraften/config.yaml to define your development environment. For source: default and source: custom, every setting lives in this one file. For source: team, it is a thin pointer — just ~source: team~ and ~url~ — and the actual tool settings are fetched fresh from the remote URL on each `dk apply`.
Common tasks
source
dk init --team https://example.com/team-config.yamlsource
dk applyOverview
Datakraften uses a single YAML file at /.config/datakraften/config.yaml to define your development environment. For source: default and source: custom, every setting lives in this one file. For source: team, it is a thin pointer — just source: team and url~ — and the actual tool settings are fetched fresh from the remote URL on each dk apply.
The config is split into top-level sections, each controlling a different aspect of your workstation. Here is the full structure:
source
The source field selects where your configuration comes from. Three options:
- default — built-in config embedded in dk, full developer workstation defaults
- custom — local-only, edit everything yourself. Created with dk init --custom
- team — thin config pointing to a remote YAML URL (single source of truth)
When source: team is active, a url field must be set pointing to a YAML file hosted anywhere accessible via HTTPS. The remote YAML defines every tool setting — system_packages, brew_packages, runtimes, shell, editors, ai_tools, and ai_apps. The local config stores only source: team and url; it is never a full config.
Set up team config:
After the URL is set, every dk apply fetches the remote YAML fresh and applies it:
system_packages
Packages installed via your native package manager (apt, dnf, yum, pacman, or brew). The bootstrapper auto-detects which manager to use.
These are installed with sudo (where applicable) before any other step. dk apply skips already-installed packages automatically.
brew_packages
Packages installed via Homebrew. Datakraften installs Homebrew if it's not already present, then uses it for the tools listed here. Most developer tooling comes through brew.
runtimes
Programming language runtimes and their version managers. Each runtime has its own enabled flag and optional version.
- Node.js is managed by fnm (Fast Node Manager). Set version to lts for the latest LTS, or pin a specific version like 20 or 22.
- Python is managed by uv. It installs the latest stable Python version and sets up uv as the default package manager.
- Go is installed via Homebrew. Enabled by default.
- .NET SDK is installed via Homebrew. Disabled by default.
shell
Shell configuration managed by Datakraften. Currently supports Fish shell with managed config blocks.
When enabled, dk apply:
- Installs Fish shell via Homebrew
- Sets Fish as your default shell (effective after re-login)
- Writes a managed config to ~/.config/fish/config.fish with Homebrew PATH, fnm integration, uv completions, Atuin, FZF, Starship, and aliases
- Sets managed blocks so Datakraften can safely re-apply without duplicating entries
editors
Code editor detection and auto-install. Datakraften detects which editors are already installed and optionally installs Zed.
- VS Code — detected on the Windows side when running under WSL (via Windows Registry), or as a native Linux install. Not installed by Datakraften; install manually from code.visualstudio.com.
- Zed — detected on Linux/WSL. Can be auto-installed by dk apply if missing.
- Cursor — detected on Windows side under WSL.
ai_tools & ai_apps
AI-powered developer tools — the differentiating feature of Datakraften. Two sections control what gets installed:
**ai_tools** — CLI tools installed via npm or Homebrew:
**ai_apps** — desktop apps installed via Homebrew Cask or VS Code extension:
dk apply handles both sections. CLI tools are installed first, then desktop apps. Apps that require a specific platform (e.g., macOS-only brew casks) are skipped gracefully.