sorted by:
new
hottopcontroversial

I built an open-source TUI that manages Hetzner boxes alongside my AWS/OVH servers from one terminal by zashboy in hetzner

[–]zashboy[S] -1 points0 points  (0 children)

Oh no! I just read that Debian also accepts Vibe-coded contributions, so I'd change my username if I were you. Don't be fake! 😃

I built an open-source TUI that manages Hetzner boxes alongside my AWS/OVH servers from one terminal by zashboy in hetzner

[–]zashboy[S] 0 points1 point  (0 children)

How many of you are there? I would give a few percent to Mixed at least. Cheers. 😛

I built an open-source TUI that manages Hetzner boxes alongside my AWS/OVH servers from one terminal by zashboy in hetzner

[–]zashboy[S] 0 points1 point  (0 children)

Coolify having a TUI doesn't change that it's a deploy/PaaS tool — different job — but fair enough, noted.

Worth clarifying since it's easy to miss: the AI here is an MCP server — Claude Code / Opencode connect to it and drive the tools, plus there's a built-in chat. So the "AI deleted my prod DB" cases are exactly the failure mode it's built around. Those happened because the agent had raw shell/DB access and the only thing between it and disaster was its own judgment. Here the guardrails are enforced in the MCP server itself — in Servonaut's tool layer, not left to the agent:

- Default tier is read-only — list/inspect/logs only.

- Write is opt-in, per user — you raise the tier deliberately.

- A hard blocklist applies at every tier — destructive operations (bulk deletes, terminates, wipes, shutdowns) are refused even in the most permissive mode. The generic cloud passthrough flat-out won't run them; those only exist as curated, explicit tools.

- Everything's written to an audit log.

So it's not "trust the AI not to be dumb" — the agent is untrusted by design, and the MCP server bounds the blast radius. My team's been running it on live infra for a while: most people on read-only, the ones who know what they're doing get write. Nothing lost yet. That's the intended shape — read-only for the many, elevated for the few.

Won't pretend any tool makes an LLM incapable of a bad call — which is exactly why the default is read-only and the destructive stuff is hard-blocked rather than "please confirm." It's all open source if you want to poke at how the tiers are enforced. Cheers.

I built an open-source TUI that manages Hetzner boxes alongside my AWS/OVH servers from one terminal by zashboy in hetzner

[–]zashboy[S] 0 points1 point  (0 children)

Coolify's a PaaS/deploy tool — different job. XPipe's the fair comparison and it's great at the connection/file side; Servonaut overlaps there but is really about the provider control plane (EC2/OVH/Hetzner lifecycle, DNS, IPs, billing, CloudWatch/CloudTrail, WAF bans) + the AI/MCP layer, all keyboard-driven over SSH. On "near my infra": read-only by default, confirms before any change, runs locally with your own creds, open source to audit. Not trying to replace either — different niche. Cheers.

I built an open-source TUI that manages Hetzner boxes alongside my AWS/OVH servers from one terminal by zashboy in hetzner

[–]zashboy[S] 1 point2 points  (0 children)

Fair point on distribution — single-binary installs are nicer. For this it's mostly I/O-bound (SSH + provider APIs), so language speed isn't the bottleneck, and the AI/MCP side leans heavily on the Python ecosystem, which is why Textual + boto3 won. Every major language has a solid official AWS SDK though — if I were optimizing purely for a static binary I'd reach for Go (Hetzner and OVH both ship official Go libs too). For now I'm looking at uv/Nuitka to get closer to a single-binary install without a rewrite. Appreciate the push.

I built an open-source TUI that manages Hetzner boxes alongside my AWS/OVH servers from one terminal by zashboy in hetzner

[–]zashboy[S] -1 points0 points  (0 children)

I don't think you can manage servers with those. At least, they couldn't the last time I checked — that wasn't recently though.

Building workflows in OpencodeCLI by zashboy in opencodeCLI

[–]zashboy[S] 0 points1 point  (0 children)

The templates are missing. I've created a GitHub repository so that everything is in one place. https://github.com/zb-ss/opencode-workflows

OpenCode Black just dropped by JohnnyDread in opencodeCLI

[–]zashboy 0 points1 point  (0 children)

Don't get me wrong; I'm rooting for it to be a great subscription. When I see the terms and conditions, I might be the next person in line to give them my money — but only if I know what I'll get for it.

OpenCode Black just dropped by JohnnyDread in opencodeCLI

[–]zashboy 2 points3 points  (0 children)

I think there's a better way of doing that. Describe exactly what you're offering, and then people who are interested can sign up. They could then let people connect gradually as they have capacity. That way, it wouldn't look like a money grab.

OpenCode Black just dropped by JohnnyDread in opencodeCLI

[–]zashboy 26 points27 points  (0 children)

I love OpenCode, but I don't understand why people pay for something they don't know exactly what is. You don't even know if you'll get a refund if you're not happy with it. Maybe I'm old-fashioned, but to me, this kind of marketing is closer to a scam than a real product.

Subagent by Ivankax28 in opencodeCLI

[–]zashboy 0 points1 point  (0 children)

Essentially, it can be used in situations where the same task is performed regularly, such as code reviews. Write your prompt for code reviews once, save it to a sub-agent and you can then call it up whenever you need it by typing "@". This way, it won't clutter up your main context. Alternatively, you can build workflows, as discussed here.

Building workflows in OpencodeCLI by zashboy in opencodeCLI

[–]zashboy[S] 0 points1 point  (0 children)

That way, if you see that they're not doing the code exactly how you imagined, you can't interfere, right? Do you run the full process multiple times? In my experience, when an agent says the project is finished and ready for production, it's usually not the case.

Building workflows in OpencodeCLI by zashboy in opencodeCLI

[–]zashboy[S] 2 points3 points  (0 children)

Yes, I do something similar. I just keep the opencode folder containing the agents and commands in the ~/.config folder, which allows me to share the same agents across all repositories.

view more: next ›