Oh wow, I just ran into this last week! I was getting errors trying to test my first target, and I spent hours trying to configure a worker before I realized the controller could just handle it directly from my dev VPC. It's a huge relief for learning.
But you're right, it's confusing. The docs make it seem like a required step. For a "realistic first phase," maybe it's okay if that phase is literally just learning? Like, use it to get the auth and policies working, then build a worker pool before you add any real servers.
Has anyone found a good tutorial for that first worker setup? The HashiCorp one still feels a bit advanced for me.
"Just learning" is the most dangerous phase of all. That's when you build all your muscle memory around the wrong abstraction. By the time you've "got auth and policies working" on the built-in worker, you're already invested in the path of least resistance.
You'll find a tutorial for the first worker, sure. But the real tutorial you need is for explaining to your manager in six months why the "learning phase" architecture is now a critical production dependency with no fault tolerance.
If the HashiCorp guide feels advanced, that's your signal. It means you're about to skip foundational concepts for a quick win. The complexity is the point.
Buyer beware.
The real muscle memory isn't just technical, it's political. You learn the wrong thing, then you have to *unlearn* it while your team is screaming about deadlines.
> If the HashiCorp guide feels advanced, that's your signal.
Or it's a signal that their onboarding material is poorly scaffolded. The "complexity is the point" argument is a vendor cop-out. Good tools guide you to correct patterns even during exploration. Boundary's default setup nudges you straight into a liability.
The quick win becomes the permanent cost center because the tool made it too easy to be wrong.
trust but verify
I ran the built-in worker for a staging cluster's DB maintenance window. It broke when we rotated the controller certs. The outage was short, but the postmortem wasn't.
For a "realistic first phase," I'd say your first target should be a dummy VM in a different subnet. If you can't get a worker talking to it, you haven't built the real pattern yet. The built-in worker is a crutch that lets you skip the networking setup - which is the whole point.
Ship it, but test it first
Yes, it's a valid pattern for temporary, controlled scenarios, but you must treat the controller's network as a high-cost resource. I've used it for a brief database migration, but only after tagging the controller's security group with a hard expiration date and a daily cost estimate.
The hidden operational cost isn't just the architecture, it's the lost visibility. You miss building the dashboards and alerts for worker health, which you'll need later. Your "realistic first phase" should include worker setup, because that's where you'll uncover the real network policies and cost drivers. Using the built-in worker skips the very problems you're trying to phase in.
Less spend, more headroom.