Template Variables: Machine-Specific Config Without the Headache

Your .gitconfig has your email address. Your .zshrc references a path that differs between macOS and Linux. Your editor config points to a font that is not installed on every machine. These are all the same config file, but they need different values depending on where they run.

Without templates, you have two bad options: maintain separate config files per machine (defeats the purpose of syncing), or manually edit files after every pull (tedious and error-prone). ConfigSync templates give you a third option: one file that adapts automatically.

Any tracked file can be marked as a template using the --template flag:

Template files are stored with their template syntax intact. When ConfigSync restores them during a pull, it evaluates the template expressions and writes the resolved output. The template source is preserved in the cloud; only the local file gets the resolved values.

ConfigSync provides several built-in variables that are always available without any setup:

These are resolved at pull time based on the machine receiving the config. A .zprofile that uses {{platform}} renders differently on macOS versus Linux without any manual intervention.

For values that are specific to a machine but not derivable from the system (like your preferred editor or a custom path), set machine variables:

Use them in templates as {{vars.editor}}, {{vars.font}}, and {{vars.projects_dir}}. Each machine can have different values for the same variable names, and the correct value is always substituted during pull.

Templates support conditional blocks for platform-specific or context-specific configuration:

You can also check tags assigned to the current machine or profile:

When a profile is active, its variables take precedence over machine-level variables of the same name. This creates a clean layering system:

This is useful when a single machine serves multiple contexts. Your machine default might be nvim, but your work profile overrides editor to code because your team standardizes on VS Code.

Here is a real-world example that combines built-in variables, machine variables, conditionals, and tag checks in a single .gitconfig template:

One file. Every machine gets the right email, the right editor, the right credential helper, and the right signing configuration. Push it once, pull it everywhere, and never manually edit .gitconfig after a sync again.