Infrastructure
Infrastructure as code promises that your servers, networks, and databases are described in files you can review, version, and recreate. The promise is real. The execution often turns into wrestling thousands of lines of YAML where a single wrong indent produces a cryptic error twenty minutes into a plan. For a solo developer, that friction is enough to send you back to clicking around a console, which is worse.
The good news is you don't have to adopt the heaviest tool to get most of the benefit. The minimum viable version of infrastructure as code is: your setup is written down somewhere, it's in version control, and applying it is repeatable. You can start with a shell script and a checklist if that's what actually gets done. Tools help, but the habit matters more.
If you're on a single cloud, the provider's native tooling is often the least painful starting point because it matches the console you already understand. If you're multi-cloud or want a single mental model, a general-purpose tool is worth the learning curve. Either way, start by importing existing resources rather than rewriting everything from scratch. Adopting infrastructure as code incrementally beats a big-bang migration that stalls halfway.
Keep your state file sacred. Store it remotely with locking so two runs can't clobber each other, and treat it as sensitive because it often contains secrets and resource identifiers. Structure your configuration by environment, not by resource type, so a change to staging doesn't risk production. Use modules or reusable components for anything you create more than twice, but don't build an internal framework before you have three real use cases.
Run a plan before every apply and actually read it. The plan output is the whole point: it shows what will be created, changed, and destroyed. Pay special attention to anything being destroyed, because that's where data loss hides. For databases and storage, add explicit protection against accidental deletion and keep separate backup mechanisms, since infrastructure tools are not backup tools.
Secrets should never live in your repository. Reference them from a secret manager or inject them at apply time. Add a lightweight CI check that runs formatting and validation on every pull request so drift and syntax errors get caught early. When someone changes something by hand in the console, import it back or revert it, otherwise your code slowly becomes a lie.
Start small: codify one environment, one service, one database. Once that's boring and reliable, expand. The goal isn't purity, it's being able to rebuild your setup on a bad day without panic. That's a win worth a little YAML.
