GuideNovember 10, 20267 min read

The DevOps Engineer's Config Sync Setup

kubectl contexts, Terraform state, cloud credentials for three providers, SSH configs for a fleet of servers. Here is how to sync it all without going insane.

DevOps Has the Most Configs of Any Role

DevOps engineers sit at the intersection of development and infrastructure. That means you have developer configs (editor, shell, git) plus infrastructure configs (kubectl, terraform, cloud CLIs, SSH for dozens of servers, Helm repositories, Ansible vaults). The total number of configuration files can easily exceed a hundred.

The stakes are higher too. A misconfigured kubectl context can point at the wrong cluster. An outdated AWS profile can deploy to the wrong account. A missing SSH key means you cannot access production during an incident. When you manage infrastructure, your local configuration is part of the production toolchain.

ConfigSync handles the complexity by syncing everything encrypted and organized by module. Here is the complete setup for a DevOps engineer.

Kubernetes Configuration

Your kubeconfig is arguably the most critical file on your machine. It contains cluster endpoints, authentication certificates, and context mappings. Losing it means you cannot interact with any cluster until you regenerate credentials.

Track kubeconfig

# Track kubeconfig (encrypted because it contains certs) $ configsync add config ~/.kube/config --encrypt # If you use multiple kubeconfig files: $ configsync add config ~/.kube/config-staging --encrypt $ configsync add config ~/.kube/config-production --encrypt # Track kubectx/kubens favorites $ configsync add config ~/.kube/kubectx

Always use the --encrypt flag for kubeconfig files. They contain cluster certificates and tokens that provide direct access to your infrastructure.

Terraform Configuration

Terraform stores provider credentials, plugin caches, and CLI configuration in ~/.terraform.d/. This directory is easy to forget because Terraform mostly uses per-project directories, but the global config matters.

Track Terraform config

# Track Terraform global config $ configsync add config ~/.terraform.d/credentials.tfrc.json --encrypt $ configsync add config ~/.terraformrc # Store Terraform Cloud tokens as secrets $ configsync secret set TF_CLOUD_TOKEN $ configsync secret set TF_VAR_db_password

Terraform Cloud and Terraform Enterprise tokens live in the credentials file. These are long-lived tokens that grant access to your state files and workspaces, so encryption is essential.

Multi-Cloud CLI Credentials

Most DevOps engineers work with at least two cloud providers. Each has its own CLI, its own configuration directory, and its own authentication flow.

Track all cloud CLIs

# AWS (built-in module) $ configsync enable module aws # Captures ~/.aws/config and ~/.aws/credentials (encrypted) # GCP $ configsync add config ~/.config/gcloud/properties $ configsync add config ~/.config/gcloud/credentials.db --encrypt # Azure $ configsync add config ~/.azure/config $ configsync add config ~/.azure/accessTokens.json --encrypt

Provider	Config Path	Contains Secrets
AWS	~/.aws/config, ~/.aws/credentials	Yes
GCP	~/.config/gcloud/	Yes
Azure	~/.azure/	Yes
DigitalOcean	~/.config/doctl/	Yes

SSH for Fleet Access

DevOps SSH configs are an order of magnitude more complex than a typical developer's. You might have entries for dozens of servers with bastion host proxying, different keys per environment, and port forwarding rules.

Complex SSH config with templates

# Enable the SSH module $ configsync enable module ssh # Your SSH config might include: Host bastion-prod HostName bastion.prod.example.com User ops IdentityFile ~/.ssh/prod_key Host bastion-staging HostName bastion.staging.example.com User ops IdentityFile ~/.ssh/staging_key Host prod-* ProxyJump bastion-prod User deploy StrictHostKeyChecking accept-new Host staging-* ProxyJump bastion-staging User deploy # Template variables help with dynamic hosts Host web-prod-* HostName %h.prod.internal.example.com ProxyJump bastion-prod

The SSH module encrypts all private keys and restores them with correct file permissions (600 for keys, 644 for public keys, 700 for the .ssh directory). This is critical because SSH refuses to use keys with overly permissive permissions.

Helm and Ansible

Helm repositories and Ansible configurations round out the DevOps toolkit. Helm stores repository lists and cached chart data. Ansible stores vault passwords, inventory files, and connection settings.

Track Helm and Ansible configs

# Helm repositories $ configsync add config ~/.config/helm/repositories.yaml # Ansible configuration $ configsync add config ~/.ansible.cfg $ configsync add config ~/.ansible/vault_password --encrypt # Docker module for registry auth $ configsync enable module docker

The DevOps Module Stack

Here is the recommended module and config set for a DevOps engineer:

Complete DevOps setup

# Enable core modules $ configsync enable module ssh $ configsync enable module docker $ configsync enable module aws $ configsync enable module git $ configsync enable module shell $ configsync enable module homebrew $ configsync enable module vim # Add DevOps-specific configs $ configsync add config ~/.kube/config --encrypt $ configsync add config ~/.terraform.d/credentials.tfrc.json --encrypt $ configsync add config ~/.terraformrc $ configsync add config ~/.config/helm/repositories.yaml $ configsync add config ~/.ansible.cfg $ configsync add config ~/.config/gcloud/properties # Push the complete environment $ configsync push -m "DevOps environment - full stack" Scanning 7 modules... Tracking 6 additional configs... Encrypting 14 secret files... Pushed snapshot (4.7 MB) in 8s.

With this setup, you can go from a fresh machine to a fully configured DevOps workstation in under ten minutes. Every kubectl context, every SSH key, every cloud credential is exactly where it should be, encrypted in transit and at rest.

Ready to try ConfigSync?

Sync your entire dev environment across machines in minutes. Free forever for up to 3 devices.

Get Started Read the Docs