Comtrya applies dotfile manifests without the configuration management baggage

The problem is provisioning one machine, not a fleet

Comtrya is described as a tool to help provision a fresh OS with the packages and configuration, the dotfiles, you need to become productive again. The motivation paragraph is unusually specific about why it exists. The author describes wiping their own operating system roughly every thirty days and having relied primarily on SaltStack to automate that, then growing frustrated with the mismatch between configuration management and personal provisioning. Ansible, Chef, Puppet and mgmt were all tried, and the stated reason each fell short is the same: a flaw that makes it too cumbersome to adopt for what is, in their words, the trivial use case. That framing sets the expectation correctly. Comtrya is not competing with Ansible on orchestration, inventory or idempotency at scale. It is aimed at the single laptop that was reinstalled last night, where the entire desired end state fits in a few YAML files and the only consumer is you.

Manifests are YAML and the schema is generated from code

A manifest is the unit of work. The examples directory in the repository shows how many shapes a manifest can take, with separate example folders for binary, command, directory, file, git, group, http, labels, macos, onlyvariants, plugin, toml-examples, user, variables and where, plus a top level Comtrya.yaml. That list is the best available map of what the tool can express: fetch a binary, run a command, create a directory or a file, clone a git repository, group several actions under one name, make an HTTP request, apply labels, target macOS specific behaviour, restrict a manifest to certain variants, run a plugin, and use variables or a where condition. The schema itself is generated rather than hand written. The workspace in Cargo.toml lists three members, app, jsonschemagen and lib, and the jsonschemagen crate name says what it does: it produces a JSON schema for the manifests, so an editor can validate and complete them. The library crate holds the manifest model, and the app crate is the binary. Comtrya also supports TOML examples, and a docs folder in the repository.

Applying is one command and manifests are selectable

Running everything is deliberately simple. The documented usage shows the whole interface for picking work.

comtrya apply
comtrya apply -m one,two,three
comtrya -d ./manifests apply

The first form runs all manifests in the current directory, the second restricts the run to a named subset through the --manifests or -m option, and the third points the tool at a different directory of manifests with -d. That subset option is the feature that makes the tool practical for daily use rather than a once-per-machine ritual. Restoring a single application and its configuration after a reboot is a different operation from a full provision, and being able to name the manifests you want keeps the tool in the loop without re-running everything. The directory flag also means manifests can live in a dotfiles repository with its own layout, which is the usual way people keep this kind of thing, and it means the tool does not impose a project layout on top of the one you already have.

Installing means a shell one-liner or a binary from releases

Binaries are published on the releases page, and the README offers a one-liner for people who are not risk averse.

curl -fsSL https://get.comtrya.dev | sh

There is a pinned variant for anyone who prefers a known version, and the example uses the last tagged release, v0.9.2.

curl -fsSL https://get.comtrya.dev | VERSION=v0.9.2 sh

Piping a remote script into a shell is the pattern every dotfile installer uses, and it deserves the scepticism that pattern deserves. The alternative is downloading the binary from the releases page yourself, which is what the README lists first. The README also asks readers to open an issue if the installer does not cover their operating system or architecture, which tells you the installer script maintains a matrix of platforms that you may need to check. The project publishes packaging metadata to Repology, and the repository contains a Justfile, a shell.nix and a deny.toml for cargo license checks, so there is more than one path to getting the binary onto a machine.

The author intends to archive the project

The most important fact about Comtrya is at the very top of the README. The author writes that they could not find any new maintainer in the last two months and will therefore archive comtrya, inviting people to fork it and continue, and thanking the previous maintainers including rawkode. That is a stated intention rather than a completed action, because the repository is not marked archived, and the last push to the main branch was on 2026-10-12, which is more recent than the last tagged release of v0.9.2 from 2025-04-27. So the code is still moving while the maintainer has announced an intention to stop. Practically, that combination points at one option: if Comtrya is going to be part of your setup, plan for the fork now rather than after the archive happens. The MIT licence permits that without asking anyone. The licences of the dependencies are a separate question, and the deny.toml file in the repository is the tool for checking them.

Two known rough edges: output verbosity and serial execution

The roadmap section in the README is unusually candid about what is not finished. The first gap is output. A quiet or summary option is listed as a goal that would restrict the output to the run time, and the sample of the intended format is short: how long the run took, how many packages were installed, how many files were provisioned. Until that lands, the default output is the only output. The second gap is concurrency. The project builds its dependency graph with petgraph but does not traverse it in a way that allows manifests at the same depth to execute concurrently, and the author describes fixing that as something to sort out soon. That is a real architectural limit rather than a polish item, because manifests with a dependency relationship between them are the ones that matter, and same-depth manifests that could safely run in parallel do not. A third gap is packaging granularity: currently the tool executes arbitrary packager install commands, and the intended provider specification is richer, supporting list refresh, upgrades and version pinning.

Editorial conclusion

Comtrya suits people who wipe their machines often and want one declarative YAML file to restore packages and dotfiles, and it suits users comfortable reading a small Rust codebase. It does not suit anyone who needs configuration management for infrastructure, since that is the mismatch the author set out to fix, and it does not suit anyone starting a new deployment because the author has stated an intention to archive the project. Before adopting it, run comtrya apply -m with one manifest on a spare machine, check the examples/ directory for the manifest kinds that match your setup, and read the README notice about archiving before you commit anything to it.

Frequently asked questions

Official sources

1. comtrya/comtrya on GitHub
2. License: MIT
3. Project website
4. README
5. Releases