Team Configs Documentation

Standardized dev environments across your whole team with shared YAML configs

Quick summary

Every team has a stack — specific tools, runtimes, linters, and conventions. Without automation, each new hire spends hours (or days) setting up their machine, and inconsistencies creep in across the team. Datakraften's team config solves this with a single shared YAML file.

Common tasks

Why team profiles?

curl -fsSL https://datakraften.no/install | bash

Why team profiles?

dk init --team https://example.com/team.yaml

Why team profiles?

dk apply

Why team profiles?

The idea is simple: define your team's ideal workstation once, host the YAML file somewhere your team can reach it, and each developer's local config becomes a thin pointer — just source: team and url. On every dk apply, the remote YAML is fetched fresh, validated, and applied. No local copy, no drift.

$curl -fsSL https://datakraften.no/install | bash

$dk init --team https://example.com/team.yaml

$dk apply

~ Onboarding goes from hours to minutes. Every machine is identical. No tribal knowledge needed. Updates to the shared config take effect on the next dk apply.

Setting up a team config

The remote YAML defines everything — it IS the config. Create a file with the exact toolset your team needs and host it somewhere accessible. Each developer's local config only needs:

source: team

url: https://raw.githubusercontent.com/your-org/team-config/main/datakraften.yaml

Here is an example of what the remote YAML file itself might look like:

system_packages:

- build-essential

- curl

- git

- unzip

- postgresql-client

- redis-tools

brew_packages:

- fish

- starship

- atuin

- fzf

- gh

- docker

runtimes:

node:

enabled: true

version: lts

python:

enabled: true

dotnet:

enabled: true

shell:

fish:

enabled: true

managed_config: true

editors:

vscode:

enabled: true

zed:

enabled: true

ai_tools:

codex:

enabled: true

opencode:

enabled: true

copilot:

enabled: true

claude:

enabled: false

gemini:

enabled: false

ai_apps:

codex:

enabled: true

claude:

enabled: false

copilot:

enabled: true

~ Commit this file to your team's infrastructure repo or a shared gist, then share the raw URL. Every developer who runs dk init --team <url> gets exactly this setup — and every dk apply re-fetches it fresh, so updates are instant.

Hosting your YAML

Any HTTPS-accessible URL works. Popular options:

GitHub repository — commit the YAML to your team's repo and use the raw.githubusercontent.com URL
GitHub Gist — create a secret or public gist and use the raw URL
Internal wiki — host it behind your company's SSO or VPN
S3 / Cloud Storage — with a signed URL or public bucket
Your own server — any static file server works

The URL is set during dk init --team <url>. Datakraften fetches the remote YAML to validate it, then stores only the URL locally. On every dk apply, the remote YAML is re-fetched fresh — the remote file is always the single source of truth. This means the environment is always up to date with the latest version of the shared config.

▶ Use a versioned path (e.g. /v1/datakraften.yaml or a git tag) to control when team members pick up changes. When you update the shared config, tell your team to run dk apply to pull the latest version immediately.

Best practices

Start with the default profile, test it, then iterate:

Begin with the default profile on your own machine — run dk init then dk apply

Customize your remote YAML for your team's stack. Add specific packages, remove what you don't need.

Host the YAML and share the raw URL. Ask a teammate to run dk init with it on a fresh machine.

Keep the remote YAML minimal — install only what every developer needs. Let individuals add their own tools on top.

Version your config. Use a git tag or a versioned path so you can roll back if something breaks.

Document exceptions. Not everything fits in YAML. Add a comment or a README alongside your remote config for manual steps.

Run dk doctor after dk apply to verify everything is set up correctly.

Update periodically. Point your team to run dk apply when you push a new version of the remote YAML — changes take effect immediately.

Example: Node.js team config

A minimal remote YAML for a Node.js backend team. Developers point their local config to this URL and get the exact same environment:

system_packages:

- build-essential

- curl

- git

brew_packages:

- fish

- starship

- gh

- docker

runtimes:

node:

enabled: true

version: lts

python:

enabled: false

dotnet:

enabled: false

shell:

fish:

enabled: true

editors:

vscode:

enabled: true

ai_tools:

codex:

enabled: true

opencode:

enabled: true

copilot:

enabled: true

claude:

enabled: false

gemini:

enabled: false

ai_apps:

codex:

enabled: true

claude:

enabled: false

copilot:

enabled: true

~ Every developer gets Node.js LTS, fish shell with Starship, GitHub CLI, Docker, VS Code detection, and AI tools — nothing more, nothing less.

Example: Full-stack team config

A comprehensive remote YAML for a full-stack team working with Node.js, Python, Go, and .NET:

system_packages:

- build-essential

- curl

- git

- unzip

- postgresql-client

- redis-tools

- jq

brew_packages:

- fish

- starship

- atuin

- fzf

- fd

- broot

- bottom

- gh

- docker

- powershell

runtimes:

node:

enabled: true

version: lts

python:

enabled: true

go:

enabled: true

dotnet:

enabled: true

shell:

fish:

enabled: true

editors:

vscode:

enabled: true

zed:

enabled: true

ai_tools:

codex:

enabled: true

opencode:

enabled: true

copilot:

enabled: true

claude:

enabled: false

gemini:

enabled: false

ai_apps:

codex:

enabled: true

claude:

enabled: false

copilot:

enabled: true

~ Extends the minimal setup with additional system tools (postgresql-client, redis-tools, jq) and PowerShell — all from a single shared URL.