I've been researching IaC options for our on-prem VMware environment, and OpenClaw keeps coming up as a tool that supports "multi-cloud and on-prem." The documentation mentions providers for vSphere and OpenStack, but I'm trying to understand what that actually looks like in practice.
My main questions are:
* **State Management:** How does OpenClaw handle state files in a bare metal scenario? Is it stored locally, or is there a recommended remote backend option that works well without a cloud service?
* **Provider Coverage:** For vSphere specifically, does it cover the full range of resources we'd need? I'm thinking about:
* Virtual machines
* Networks (distributed switches, port groups)
* Datastores and folders
* Any experience with Proxmox would be a bonus.
* **Team Learning Curve:** Coming from a background with Terraform, how steep is the transition? The declarative syntax seems similar, but I'm curious about the nuances in provider configuration and module structure for on-prem.
We're evaluating this against Terraform's vSphere provider and potentially Crossplane. The appeal of OpenClaw is the single toolchain for both our cloud and on-prem resources, but I want to make sure the bare metal story is mature enough for day-to-day operations.
State management is the same headache as Terraform, honestly. You can use a local file, but you'll want a remote backend for any team. They support S3-compatible storage, so you could run MinIO on-prem. It's functional, not magical.
For vSphere coverage, it's decent but check the provider docs closely. It handles VMs, networks, and datastores, but I've hit gaps with advanced DVS configurations. The Proxmox provider is community-driven and feels like it - works for basic VM lifecycle, but don't expect parity with vSphere.
On the learning curve: if you know Terraform, you're 90% there. The main nuance is their configuration merging logic, which can bite you when you start composing modules for on-prem versus cloud. I'd argue if you're already using Terraform for cloud, adding their vSphere provider might keep your stack simpler than introducing another tool. The "single toolchain" promise often just means two different problems in one place 😉
That's a really good point about the "single toolchain" just centralizing problems. It sounds like a trade-off between operational simplicity and technical debt.
When you say the merging logic bites you with on-prem vs cloud modules, is that because the provider attributes are so different? Like trying to define a generic "network" that works for a vSphere port group and an AWS VPC? 😅
We're considering this for a hybrid rollout, and I'm now wondering if we'd just be creating one huge, brittle config.
"One huge, brittle config" is exactly what you'll get if you try for true abstraction. The merging logic issue isn't just about differing attributes. It's about OpenClaw's deep merge on maps, which works fine until you have a cloud module that sets `tags = { environment = "prod" }` and an on-prem module that tries to `tags = { backup_tier = "silver" }`. You don't get merged tags. You get the last write wins, silently.
The real contrarian take is that a single toolchain for hybrid is a trap. You're not gaining simplicity, you're just hiding two wildly different operational models behind a common syntax. When your vSphere datastore fills up, the "remediation playbook" looks nothing like an AWS EBS quota increase, but your "unified" config implies it should.
Stick to separate configs per substrate. Share only the bits that are genuinely identical, like some naming conventions. Trying to make a port group and a VPC the same object is how you end up with a 3am page because the merge evaluation order changed.