ish-bot-deploy: Terraform, but make it the control plane
This repo does not stop at provisioning instances. It bootstraps Kubernetes by hand, then layers a browser bot on top with VNC, VPN, and multi-cloud routing.
- ish-bot-deploy treats Terraform as a full deployment engine, not just a cloud resource manager.
- Its most unusual move is regenerating Kubernetes certificates after the nodes exist, then pushing them back into the bootstrap path.
- The bot runtime is built for visible, stateful browser work, with VNC, VPN, and identity controls baked into the config.
- The real comparison point is not another app, but managed Kubernetes and the abstractions this repo deliberately rejects.
Most bot projects are judged by the model, the prompt, or the UI. This repo cares about a lower layer: the machinery that keeps a browser bot running long enough to do real work. It provisions raw instances, bootstraps Kubernetes by hand, and ships the bot with the networking and observability it needs to look less like a scraper and more like an operator.
The cluster starts as scripts, not a service
The structure is blunt. Terraform handles the cloud, Bash handles the machine bootstrap, and Kubernetes manifests handle the application layer. That split appears twice, once under terraform/AWS and again under terraform/GCP, which tells you the goal is not portability by abstraction. It is parity by repetition.
That choice matters because the repository is not leaning on EKS or GKE to hide the hard parts. Instead, it wires together raw compute, routes, certificates, and startup scripts. The result is more legible than a managed stack in one sense, and far more demanding in another.
The bot is not a thin scraper
The ConfigMap reads like the operational spec for a very picky desktop session. Settings such as fetch-by = random, engage-reader = True, and maximum-window-probability = 0.92 suggest behavior shaping, not just request sending. Add vnc-service, screen dimensions, and NordVPN OVPN file paths, and the browser becomes a monitored, tunneled workspace rather than a headless afterthought.
That is the main clue to the project’s intent. The application is built around a real browser surface, with human-like interaction patterns and network egress controls baked into the runtime. Even the naming of the base host endpoints points to a system that expects external services, not a toy demo.
The hard way is enforced in the control plane
The most striking files are the ones that let Terraform behave like an orchestration engine. In execs.tf, a null_resource and local-exec generate a certificate authority and component certificates before the nodes are fully ready. In instances.tf, certificates are uploaded and remote shell scripts finish the control-plane setup on the host itself.
That approach creates a stateful loop on purpose. The repository waits for private IPs, regenerates certificates with those IPs as SANs, and then pushes the corrected artifacts back into the cluster. It is an unusual way to manage Kubernetes, but it is also the reason the stack can be recreated from first principles instead of being assembled from opaque managed services.
| Approach | Strength | Weakness |
|---|---|---|
| Managed Kubernetes | Fastest path to a working cluster and far less bootstrap plumbing. | You give up low-level control over certificates, routing, and host setup. |
| Terraform plus Ansible | Keeps provisioning declarative while leaving machine setup to a purpose-built tool. | The handoff between tools can hide drift and blur ownership. |
| ish-bot-deploy | Keeps instance creation, cluster bootstrap, and bot runtime inside one repeatable repository. | You inherit the full complexity of certificates, routes, and cloud-specific networking. |
What this pattern is good for
This repository is opinionated in a useful way. It favors explainability over convenience, and that makes sense for a browser bot that may need fixed versions, visible sessions, and tightly controlled network paths. The tradeoff is obvious in the code too, with hardcoded Kubernetes versions, fixed IP ranges, and TODO notes that acknowledge the stack still needs hand care.
That is the real takeaway. ish-bot-deploy is not trying to be the cleanest possible abstraction, and it is not pretending the hard way is free. It is making the hard way repeatable enough that a browser bot can be rebuilt, watched, and routed on demand.
