The race to build the next WordPress

Post by runako » Mon, Apr 20, 2026, 2:58 PM UTC

Glemllksdf wrote: post #16

runako wrote: post #13

Do people really prefer to see vCPU pricing in per-second increments? Is this useful for any person? Presumably no information is conveyed by the first 4 significant digits. And can anybody compare this pricing to e.g. AWS or Google Cloud? I have never known my compute cost to second resolution, so I'd need to do calculations to even ballpark this. Suggestion: Don't obfuscate the price, just remove it. Clearly you do…

For CI/CD Jobs? Yes. For a VM running for a month? No. For highly scalable batch tasks? Yes. For small experiments? Yes. For Full e2e tests creating a full env and killing it a minute later? yes.

One of the info blocks is headed "Persistent VMs" and suggests "Always-on VMs..."

They are not pitching this for any of the "yes" tasks you identified.

Post by runako » Mon, Apr 20, 2026, 3:00 PM UTC

rcxdude wrote: post #19

runako wrote: post #13

Do people really prefer to see vCPU pricing in per-second increments? Is this useful for any person? Presumably no information is conveyed by the first 4 significant digits. And can anybody compare this pricing to e.g. AWS or Google Cloud? I have never known my compute cost to second resolution, so I'd need to do calculations to even ballpark this. Suggestion: Don't obfuscate the price, just remove it. Clearly you do…

There is a useful signal in such a way of indicating pricing: it signals that the billing is done at such a resolution, which, for some workloads, can make a difference compared to say, a minimum increment of an hour or a day. Though I would prefer that you can see the conversion to longer timescales on the page itself.

I thought about that, which is indeed what AWS Lambda does, but one of the pitches here is "Always-on VMs," which is not what Lambda is selling.

Re: The race to build the next WordPress

Re: The race to build the next WordPress