Every product company has a “we’ll consider it” list. Most are graveyards. Ours has a public twin: the list of things we will not build, and why. These refusals are as much a part of Vloud’s identity as the features we ship.
A native macOS / Windows version
Asked for by: developers running multi-OS dev environments, agencies managing Windows servers. Why we say no: Linux is the production platform we serve. Windows / macOS support adds porting work that fragments the codebase, doubles the test surface, and serves a real but small audience. Better to be the best Linux product than a mediocre cross-platform one.
A managed / SaaS-hosted Vloud
Asked for by: small teams who don’t want to manage a Linux box. Why we say no: It’s the opposite of what Vloud is for. The whole product premise is “your data, your server, your perimeter.” A managed Vloud breaks all three. We’d rather lose the customer to a competitor than ship a managed version that contradicts the brand.
A built-in CASB / cloud asset inventory
Asked for by: enterprises with sprawling AWS / GCP / Azure footprints. Why we say no: We protect the box we run on. Cloud asset inventory is a different product (Wiz, Lacework, Orca all do it well). Bolting it onto Vloud would dilute the product and compete with vendors who do it better.
eBPF-based kernel-level EDR
Asked for by: security-focused customers. Why we say no: EDR is a real category with real specialists (CrowdStrike, SentinelOne). A “control panel that also does EDR” is worse at both jobs than a focused EDR + a focused control panel. We don’t want to ship a half-EDR.
Multi-tenancy / hosting reseller
Asked for by: agencies wanting to resell Vloud as their own hosting product. Why we say no: Vloud is one engine per host. Multi-tenancy means tenants share one engine, which means we’d need to add tenant-isolation primitives that don’t exist. The Vloud Pro plan already supports per-project / per-team isolation within an org. True reseller multi-tenancy is a different product.
Custom user-defined self-healing rules
Asked for by: advanced ops teams. Why we say no: Yet. Self-healing is too high-blast-radius for us to ship a “user-defined trigger + user-defined action” surface without a strong sandbox. The sandbox is real engineering work and not at the top of the roadmap. Eventually, yes; today, no.
A WAF rule editor at L7
Asked for by: customers wanting deep protection on app traffic. Why we say no: WAF is a category. Cloudflare, Fastly, AWS WAF all do it well. Our existing firewall handles L3-L4; the L7 layer is better delegated to a specialist.
A “free forever” tier with all features
Asked for by: developers in early-stage projects. Why we say no: We tried it. It produced a long tail of users who never converted, never gave feedback, and consumed support bandwidth disproportionately. The current Free tier (1 host, limited features) is the right shape — people who like it become paying customers, and the ones who don’t lose nothing.
Why we publish this list
Every “yes” is a constraint on the product. Every “no” is also a constraint, and shapes the product just as much. Customers deciding whether to buy Vloud should know what we’re choosing not to build, in advance, so they can decide whether the boundaries we draw match the problem they’re trying to solve.
That’s the deal. The list is short, the list is real, and the list is part of what we’re selling — a product with deliberate edges.