Ansible works best when you only have Linux/BSD systems to manage, due to its heritage and doing everything through SSH.

If you have other systems to manage, like Windows or VMware ESX etc., it feels like a kludge with the delegation to localhost to get to the plugins.

Also, it can be tricky to use if your Linux systems have different Python interpreter versions because it's not at all straightforward to override the python interpreter used.

Looping constructs and sub-tasks etc. are also awkward to use, and the initial setup for a small automation project might be overwhelming for newcomers.

On the other hand you get a massive community with plugins for almost every conceivable system/OS, so that's definitely a huge plus

Word of advice: Whatever you use, try to be relatively consistent with commiting your changes. A traversable git history and clean enough state to keep track of what's fresh can be super helpful especially when troubleshooting or coming back after messing around with whatever.

And never commit inline secrets. Find out one of the ways to inject/separate/template secrets that's workable for you to stick with it.

For home use definitively recommend Ansible. I've used/uses both and for a handful of servers/VM and for a single administrator I'd always pick Ansible. Realistically what you want is just a tool that store a configuration in some VCS and an a why to apply that configuration quickly.

Ansible will allow you to do that with just "pip install ansible". Puppet requires you to setup so infrastructure, which you need to way of bootstrapping.

Personally I also find Ansible easier to work with, in the sense that you can more easily do stuff in small increments. Upgrading Ansible is also a lot simpler. Puppet really cool and powerful, but for home stuff or a small business I'm not sure the overhead of managing Puppet itself is worth it.

Both are solid and will do the job.

Ansible is a little bit easier to get started for a few reason (yaml instead of a DSL, ssh only...) ; it's also mostly tasks running through SSH which may feel a bit more "natural" when you are configuring machines initially.

In terms of idempotency I find it is easier in ansible to mess up something but if you are careful they are on par. I've used mostly ansible over the past few years in various jobs but the first I got in touch with ~10 years ago was puppet and it felt very solid especially for heterogeneous environments (we had different archs and OSes to manage). Also puppet scales very well because it has agents as well as many tools to manage large infrastructures which I tried and were already quite convenient 10 years ago.

TL;DR probably use ansible unless you have a very specific use case.

Step #1 keep your CM files in Git.

My favorite part of puppet is demonstrated well by the trifects:

   package { 'openssh-server':
     ensure => installed,
   }
   
   file { '/etc/ssh/sshd_config':
     source  => 'puppet:///modules/sshd/sshd_config',
     owner   => 'root',
     group   => 'root',
     mode    => '0640',
     notify  => Service['sshd'], # sshd restarts whenever you edit this file.
     require => Package['openssh-server'],
   }
   
   service { 'sshd':
     ensure => running,
     enable => true,
   }

That will keep SSH installed, a service running, and the puppet config file managed forever. If you accidentally replace the config file it will be fixed and the service restarted. If you remove the package it will be reinstalled, config file updated, and service started.

Not a fan of ansible, it's more of a "run this playbook", which translates to reinstall and "run this playbook", which in environments that don't reinstall very often can be painful. Since ansible playbooks don't know the current machines state they never know exactly what commands to run.

Generally if you spin up containers or similar short term servers I think ansible is fine. If it's a larger and more complicated environment with longer lived servers I'd use puppet.

Oh, one other think I like about puppet is if you say apply X to all nodes, you can literally not run puppet (it will fail to compile the manifests) if you try to override it. Which security auditors LOVE.

I've repeatedly tried to make Puppet work for "small" installations, be it a single dev laptop, our fleet of default base VMs (before containers were a thing), or home use. You couldn't really do anything without community packages, and their update rate was kinda meh. A lot of churn.

Puppet always seemed to me like a scalable enterprise solution, but you either need a team to keep it in check, or just never update.

I'm not specifically recommending Ansible, but it's what I've been using for a couple years, and I would always recommend that for home use over Puppet.

Disclaimer: I last used Puppet in 2017, but for like 7 years extensively before that and everything I mentioned happened several times.

Second disclaimer: By now I think parametrizing everything is a huge mistake - the real worth is editing the config in one place and having it in SCM. if you only parametrize 2 lines out of a 100 line config file and basically copy it over with 2x `sed` - that's fine.

Ansible looks like a default choose for this use case but for my personal server (running in a VM) I'm planning to migrate away from Ansible and try puppet. I tried to use Ansible for a few years and abandoned it because it was too tedious to maintain configuration in Ansible. Puppet of course also requires time but if feels so much easier, mainly because it has ruby-like DSL (not YAML).

If you like Python, consider pyinfra.

https://pyinfra.com/

You may want to consider NixOS as yet another option.