The pricing seems draconian... why would anybody choose to pay this way when you can pretty much do the same with exe.dev?
Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
61–70 of 73 posts
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#62The pricing seems draconian... why would anybody choose to pay this way when you can pretty much do the same with exe.dev?
Github already does this, there's an agents tab.
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#63At the risk of replicating the classic Dropbox post (why would you need this when you could just use rsync?)… I have a dev box with 96 GB of RAM, 2x4 TB NVMe drives, and an unbelievably beefy AMD CPU. This box costs me less than $150 per month and is so hyperlocal that I can log into it and use it as a remote desktop, while also using it as an always-on server that I can use to run T3 code and tmux and so forth. I ca…
[dead]
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#64Took me a minute to see the value - my first thought was "this is just cursor's cloud agents..." But the key thing here for me is "Every sandbox boots your app on a live URL." Cursor doesn't easily have that, and that's what would allow me to ditch my local env entirely - the ability to actually try out a PR without needing to check it out locally. So on that note: how does that work? We've had trouble with getting o…
Check out https://superconductor.com: supports docker and env setup is done for you by an agent when you connect repo
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#65The "reviewing product output instead of code" framing is the right direction for where development is heading, and the per thread VM model makes sense for isolation.
One dimension worth thinking through as you scale: the security surface of cloud-hosted agents is meaningfully different from local agents. Local agents (Cursor, Claude Code) have access to your local filesystem and credentials. Cloud agents have access to your cloud credentials, your production-adjacent infrastructure, and potentially your CI/CD pipeline and they run without the developer watching.
The MCP server porting during onboarding is the piece I'd think hardest about. MCP servers can have write access to config files, and the STDIO transport has a documented unsanitized parameter passthrough vulnerability (AVE-2026-00060, corroborated by OX Security and Microsoft) that affects Python, TS, Java, and Rust SDKs. When you're running hundreds of agents concurrently in the cloud, a single compromised MCP server has a much larger blast radius than a local one.
The "what the agent writes" security layer is separate from the "how the agent runs" security layer. Hoplite solves the second. Scanning what the agent wrote (SAST, secrets detection, dependency audit) before it gets merged is the complementary first layer. SafeWeave runs as an MCP server inside the agent's environment for exactly this works locally and in cloud agent setups.
Congrats on the launch. What's your current approach to credential scoping for agents that need cloud access?
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#66There are no new ideas
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#67Earlier quoted context omitted.
That setup is pretty much what we're trying to offer with Hoplite! Using us means losing freedom and control with regards to infrastructure, however we think that's a tradeoff people would want to make in exchange for easier onboarding and a more polished experience.
Makes sense. It took me some experimentations with a few open source libraries and docker-compose to arrive at my setup. My setup also requires me to access agents via a terminal app on my phone so it's nice to have a web app like your offering. Are you offering browser access to the agents in your setup?
If browser access is the actual blocker: OpenCode (open-source coding agent, github.com/anomalyco/opencode) ships its own web UI -- `opencode serve` gets you a browser tab into the agent without needing Hoplite's hosted layer at all, so it slots into a self-hosted docker-compose setup like yours instead of replacing it.
I got tired of re-doing that setup on every new box, so I packaged it as a one-click Railway template -- a cloud dev box that runs OpenCode's web UI with state persisting between sessions, so you can drive it from your phone's browser instead of a terminal app. Full disclosure: I maintain it and get a kickback if you deploy through it: https://railway.com/deploy/opencode-webui-workspace?referral...
It doesn't give you Hoplite's per-thread VMs, PR automation, or QA tooling -- it's just the agent plus a browser, self-hosted. But if that's literally the missing 20%, it's a much smaller lift than what you already built.
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#68Earlier quoted context omitted.
Makes sense. It took me some experimentations with a few open source libraries and docker-compose to arrive at my setup. My setup also requires me to access agents via a terminal app on my phone so it's nice to have a web app like your offering. Are you offering browser access to the agents in your setup?
If browser access is the actual blocker: OpenCode (open-source coding agent, github.com/anomalyco/opencode) ships its own web UI -- `opencode serve` gets you a browser tab into the agent without needing Hoplite's hosted layer at all, so it slots into a self-hosted docker-compose setup like yours instead of replacing it. I got tired of re-doing that setup on every new box, so I packaged it as a one-click Railway templ…
And why would I go from my self hosted infra on a dedicated server to a dependency on Railway?
My setup already works and what you are suggesting is weaker than my setup.
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#69Congrats on the launch. I run coding agents daily (solo founder) and QA is honestly worst part. The agent says done, I go check, half the time something's off. How you close the gap between "agent claims it works" and it actually working in prod?
Re: Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents
#70congrats on the launch. curious how you're handling the visually verify the feature looks good part specifically, since that's usually the hardest bit to make reliable compared to the API/CLI checks. are your agents driving a real browser instance for that, or is it screenshot diffing against some baseline been messing around with phi browser lately for a similar problem, it exposes mcp so an agent can drive an actual chromium session with real state/cookies instead of a clean headless instance, made a noticeable difference in catching stuff that only shows up with a logged in session. curious if you rolled your own browser layer for the preview/QA piece or if you're leaning on something existing under the hood also the custom harness decision is interesting, would love to hear more about what specifically off the shelf solutions were missing for the concurrent hundreds of agents case, sounds like a scaling/isolation problem more than a capability one