I am building a cloud

Original Article ↗ Hacker News Discussion ↗

What exe.dev offers

  • Pooled-compute model: you buy a fixed bundle (e.g., 2 vCPU, 8 GB RAM, 25 GB disk, 100 GB transfer) and can split it into many small VMs that share those limits.
  • Strong SSH-first UX: ssh exe.dev to sign up and manage; built-in HTTPS proxy gives each VM a URL; geared toward root-on-a-Linux-box workflows and agent-style workloads.
  • Scope is intentionally narrow: more “developer cloud / agent farm” than full-featured cloud (no managed DBs, limited networking features, unclear data-center details).

Pricing and cloud economics

  • Many see $20/mo for pooled resources as attractive compared to hyperscalers’ fragmented, surprise-heavy bills.
  • Others note transfer at $0.07/GB is still high vs raw bandwidth; some call this inconsistent with the blog’s criticism of egress pricing. The team says this is a legacy number they plan to lower.
  • Debate over whether this is cost-competitive with cheap VPS or bare metal; some say it must add higher-level value (tooling, UX) to justify price.

Storage, IOPS, and bandwidth

  • Long subthread measuring IOPS/latency across Hetzner, DigitalOcean, netcup, and Hetzner dedicated; consensus: local NVMe is massively faster and cheaper than network block storage.
  • Others defend SAN-style block storage with redundancy and point-in-time snapshots as inherently expensive and often a poor abstraction for higher-level systems.
  • Bandwidth pricing across clouds widely criticized as disconnected from actual costs and designed to lock in customers.

Comparisons to VPS / bare metal providers

  • Hetzner, OVH, netcup, and others are repeatedly cited as dramatically cheaper and faster for many workloads; some wonder what exe.dev offers beyond “a nicer wrapper around hcloud/CLI.”
  • Counterpoint: many companies pay more for cloud to avoid owning hardware and staffing ops; with LLMs, some think running DIY infra is getting easier again.

Kubernetes, DevOps, and complexity

  • Huge split: some say most small/medium apps should just run on one or a few VMs (Kamal, Docker Compose, simple Ansible/Terraform), and K8s is overkill that bloats cost and incident count.
  • Others argue K8s is a powerful, standardized “OS for services” that solves real problems at scale (immutable deploys, rolling updates, multi-env parity, service discovery).
  • Many complaints aim at social dynamics: resume-driven decisions, vendor marketing, management fear, operator sprawl (operators, meshes, GitOps, etc.) rather than K8s’ core design.
  • Several note that teams often “rebuild a worse Kubernetes” with ad‑hoc scripts and tools; others prefer lighter alternatives (Nomad, Swarm, k3s, systemd + containers, Uncloud, Dokploy).

AI agents and “vibe coding”

  • exe.dev is positioned as friendly for LLM-based agents and ephemeral dev boxes.
  • Some are excited by the ability to spin up lots of cheap, isolated environments for agents, previews, and personal tools.
  • Others worry about an explosion of mediocre, insecure “vibe-coded” backends by non-experts; argue platforms should constrain what such users can do server-side.

Security, sovereignty, and compliance

  • exe.dev’s control plane and some early VMs still run on AWS; most customer VMs now on other bare metal or self-racked hosts. They plan to move fully once compliance is sorted.
  • European commenters stress need for truly EU-sovereign clouds (EU companies, not just EU regions) due to the CLOUD Act; US-based providers in EU data centers don’t fully solve this.

Startup and meta reactions

  • Mixed response to the blog’s tone: some find the ambition and transparency inspiring; others read it as self-important.
  • Many praise the minimal, playful landing page and SSH-based onboarding experience.
  • Skeptics question differentiation vs existing VPS/bare-metal offerings and worry the service will inevitably drift toward the same pricing and complexity patterns as major clouds.