How much can you get out of a $4 VPS?

There's a disconnect between founders and everyone else.

Founders believe they're going to >10x every year.

Reality is that they're 90% likely to fail.

90% of the time - you're fine failing on whatever.

Some % of the 10% of the time you succeed you're still fine without the cloud - at least for several years of success, plenty of time to switch if ever necessary.

You're not a software company, fundamentally you make and sell Sprockets.

The opinions here would be hire a big eng/IT staff to "buy and maintain servers" (PaaS is bad) and then likely "write a bunch of code yourself" (SaaS is bad) or whatever is currently popular here (last thread here it was "Pushing PHP over SFTP without Git, and you're silly if you need more" lol)

But I believe businesses should do One Thing Well and avoid trying to compete (doing it manually) for things outside of their core competency. In this case, I would definitely think Sprocket Masters should not attempt to manage their own hardware and should rely on a provider to handle scaling, security, uptime, compliance, and all the little details. I also think their software should be bog-standard with as little in-house as possible. They're not a software shop and should be writing as little code as possible.

Realistically Widget Masters could run these sites with a rather small staff unless they decided to do it all manually, in which case they'd probably need a lot larger staff.

A solid dedicated server is 99% of the time far more useful than a crippled VPS on shared hardware but it obviously comes at an increased cost if you dont need all the resources they provide.

Sure, you can get something working on Hetzner but be prepared to answer a lot more questions.

Plus who doesn't want to play with the newest, coolest toy on another's dime?

Because the industry is full of people who are chasing trends and keywords and to which the most important thing is to add those keywords to the CVs.

The incremental cost of being on a cloud is totally worth it to me to have managed databases, automatic snapshots, hosted load balancers, plug and play block storage etc.

I want to worry about whether our product is good, not about middle of the night hardware failures, spinning up a new server and having it not work right because there was no incentive to use configuration management with a single box, having a single runaway task cause OOM or full disk and break everything instead of just that task’s VM, fear of restarting a machine that has been up 1000 days etc.

getting the equivalent reliability with irons is a lot more expensive than renting "two dedicated servers" - now you might be fine with one server and a backup solution, and that's fair. but a sysad to create all that, even on a short contract for the initial setup and no maintenance, is going to go well beyond the cloud price difference, especially if there's a database in the mix and you care about that data.

For many even lot less than that. I run a small side project[1] that went viral a few times (30K views in 24 hours or so) and it is running on a single core CPU web server and a managed Postgres likewise on a single CPU core. It hasn't even been close to full utilization.

1: https://aihelperbot.com/

Could I switch some of them to lambda functions? Or switch to ECS? Or switch to some other cloud service du jour? Maybe. But the amount of time I spent writing this comment is already about six month's worth of savings for such a switch. If it's any more difficult than "push button, receive 100% reliably-translated service", it's hard to justify.

Some of this is also because the cloud does provide some other services now that enable this sort of thing. I don't need to run a Kafka cluster for basic messaging, they all come with a message bus. I use that. I use the hosted DB options. I use S3 or equivalent, etc. I find what's left over is almost hardly worth the hassle of trying to jam myself into some other paradigm when I'm paying single-digit dollars a month to just run on an EC2 instance.

It is absolutely the case that not everyone or every project can do this. I'm not stuck to this as an end-goal. When it doesn't work I immediately take appropriate scaling action. I'm not suggesting that you go rearchitect anything based on this. I'm just saying, it's not an option to be despised. It has a lot of flexibility in it, and the billing is quite consistent (or, to put it another way, the fact that if I suddenly have 50x the traffic, my system starts choking and sputtering noticeably rather than simply charging me hundreds of dollars more is a feature to me rather than a bug), and you are generally not stretching yourself to contort into some paradigm that is convenient for some cloud service but may not be convenient for you.

There is a method to the madness, here it is called "job-security-driven development".

I suspect that VendorOps and complex tools like kubernetes are favored by complexity merchants which have arisen in the past decade. It looks great on resume and gives tech leaders a false sense of achievement.

Meanwhile Stackoverflow, which is arguably more important than most startups, is chugging along on dedicated machines.

1: https://stackoverflow.blog/2016/02/17/stack-overflow-the-arc...

Have you ever had to manage one of those environments?

The thing is, if you want to get some basic more-than-one-person scalability and proper devops then you have to overprovision by a significant factor (possibly voiding your savings).

You're inevitably going to end up with a bespoke solution, which means new joiners will have a harder time getting mastery of the system and significant people leaving the company will bring their intimate knowledge of your infrastructure with them. You're back to pets instead of cattles. Some servers are special, after a while automation means "a lot of glue shell scripts here and there" and an OS upgrade means either half infra is KO for a while or you don't do OS upgrades at all.

And in the fortunate case you need to scale up... You might find unpleasant surprises.

And don't ever get me started on the networking side. Unless you're renting your whole rack and placing your own networking hardware, you get what you get. Which could be very poor in either functionalities or performances... Assuming you're not doing anything fancy.

I personally have run Dedicated Servers for our business in the earlier days but as we expanded and scaled, it became a lot easier to go with the Cloud providers to provision various services quickly even though the costs went up. Not to mention it is a lot easier to tell a prospective customer that you use "cloud like AWS" than "Oh we rent these machines in a data center run by some company" (which can actually be better but customers mostly wont get that). Audit, Compliance and others.

Because it's a threat to their jobs.

We went through a growth boom, and like all of them before, it meant there were lots of inexperienced people being handed lots of money and urgent expectations. It’s a recipe for cargo culting and exploitative marketing.

But growth is slowing and money is getting more expensive, so we’ll slow down and start to re-learn the old lessons with exciting new variations. (Like Here: managing bare metal scaling and with containers and orchestration)

And the whole cycle will repeat in the next boom. That’s our industry for now.

Today, cloud is similar - the time to market is quicker as there are less moving parts. When the economy tanks and growth slows, the beancounters come in and do their thing.

It happens every time.

This only makes AWS richer at the expense of companies and cloud teams

IME aiming for scalability is exceedingly wrong for most services/applications/whatever. And usually you pay so much overhead for the "scalable" solutions, that you then need to scale to make up for it.

I only have one ansible setup, and it can work both for virtualized servers and physical ones. No difference. The only difference is that virtualized servers need to be set up with terraform first, and physical ones need to be ordered first and their IPs entered into a configuration file (inventory).

Of course, I am also careful to avoid becoming dependent on many other cloud services. For example, I use VpnCloud (https://github.com/dswd/vpncloud) for communication between the servers. As a side benefit, this also gives me the flexibility to switch to any infrastructure provider at any time.

My main point was that while virtualized offerings do have their uses, there is a (huge) gap between a $10/month hobby VPS and a company with exploding-growth B2C business. Most new businesses actually fall into that gap: you do not expect hockey-stick exponential growth in a profitable B2B SaaS. That's where you should question the usual default choice of "use AWS". I care about my COGS and my margins, so I look at this choice very carefully.

I used to have a root server for my pet projects, but honestly, that doesn't make sense. I'm not running a high traffic, compute intense SaaS on my machines. It's just a static website and some projects. I'm down to monthly costs of 24€, which includes a storage box of 1 TB to store all my data.

Hetzner cloud now has two US locations... Still no US dedicated servers though - those would kick real ass. Even if their current cloud offerings themselves are already ~30% of the price of the major cloud equivalents...

If you want ECC RAM, that appears to be €60/month, and it also steps up to a more powerful 8-core CPU.

Regardless, if we're talking about a "full production environment and a duplicate staging/standby environment" (to quote the person you replied to), then €60/month * (2 or 3) is still dirt cheap compared to any startup's AWS bill that I've seen.

Use cases vary, but I tend to agree that AWS/GCP/Azure is not the answer to every problem.

For someone who can fit their application onto a $4 VPS, that's obviously going to be cheaper than anything bare metal, but the cloud scales up very expensively in many cases. Bare metal isn't the answer to every problem either, but a lot of people in the industry don't seem to appreciate when it can be the right answer.

For this I even use a little Raspberry Pi 400 in my bedroom.

https://joeldare.com/private-analtyics-and-my-raspberry-pi-4...

atom 2c/4t, 4gb ram, 1tb drive, 100mbit

A few years of uptime at this point

Exactly. These sub-$10 VPS instances are great for small projects where you don't want to enter into long contracts or deal with managing your own servers.

If you're running an actual business where margins are razor-thin and you've got all the free time in the world to handle server issues if (when) they come up, those ~$50 dedicated servers could be interesting to explore.

But if you're running an actual business, even a $10,000/month AWS bill is cheaper than hiring another skilled developer to help manage your dedicated servers.

This is what's generally missed in discussions about cloud costs on places like HN: Yes, cloud is expensive, but hiring even a single additional sysadmin/developer to help you manage custom infrastructure is incredibly expensive and much less flexible. That's why spending a hypothetical $5000/month on a cloud hosted solution that could, in theory, be custom-built on a $50/month server with enough time investment can still be a great deal. Engineers are expensive and time is limited.

There is an implicit cost there. If its only one or two of those things, just take the managed services.

If you start to scale, get an administrator type of employee to save on this

Company I used to work for happily paid company A four times what company B charged for the exact same service, just because company A was willing to send quarterly invoices in way that played nicely with our invoicing system. For companies, saving a few hundred bucks here and there often isn't worth the hassles of introducing any extra friction.

Otherwise, I'd have to hire/contract someone very experienced, or dedicate a solid month or more of my time (which was not available), just to be 100% sure we could always restore journaled PITR backups quickly.

I can save orders of magnitude on cloud costs other places, but credible managed PostgreSQL was a pretty easy call (even if the entry-level price tag was more than you'd expect).

I think even for larger teams it may make sense to manage databases yourself, assuming you have the competence to do it well. There are so many things that can go wrong with managed services and they don’t hide the underlying implementation the way that things like block storage or object storage do.

The argument could be made you can develop a means to to rent physical servers pre-income, then, when it makes sense, you can either use standard depreciation -or- Section 179 on outright purchases and/or Section 179 leases.

As an example, you can deploy an incredibly capable group of let's say four absolutely ridiculous completely over-provisioned $100k physical 1U machines in different colo facilities for redundancy. There are all kinds of tricks here for load balancing and failover with XYZ cloud service, DNS, anycast, whatever you want. You can go with various colo facilities that operate datacenters around the world, ship the hardware from the vendor to them, then provision them with Ansible or whatever you're into without ever seeing the facility or touching hardware.

So now you have redundant physical hardware that will absolutely run circles around most cloud providers (especially for I/O), fixed costs like all you can eat bandwidth (that doesn't have the 800% markup of cloud services, etc) - no more waiting for the inevitable $50k cloud bill or trying to track down (in a panic) what caused you to exceed your configured cloud budget in a day instead of a month. Oh btw, you're not locking yourself into the goofy proprietary APIs to provision and even utilize services other than virtual machines offered by $BIGCLOUD.

If you're doing any ML you can train on your own hardware or (or the occasional cloud) and run inference 24/7 with things like the NVIDIA A10. Continuous cloud rental for GPU instances is unbelievably expensive and the ROI on purchasing the hardware is typically in the range of a few months (or way ahead almost immediately with Section 179). As an example, I recently did a benchmark with the Nvidia A10 for a model we're serving and it can do over 700 inference requests/s in FP32 with under 10ms latency. With a single A10 per chassis across four healthy instances that's 2800 req/s (and could probably be tuned further).

Then, if you get REALLY big, you can start getting cabinets and beyond. In terms of hardware failures as mentioned, all I can say is dual PS RAID-ed out, etc hardware is (in my experience) extremely reliable. Frankly having had multiple full cabinets of hardware in the past hardware failures were few and far between and hardware vendors will include incredibles SLAs for replacement. You notify them of the failure, they send a tech in < eight hours directly to the colo facility and replace the disk, PS, etc with the flashing light.

My experience is one (good) FTE resource can easily manage this up to multiple cabinet scale. To your point, the current issue is many of these people have been snatched up by the big cloud providers and replaced (in the market) with resources that can navigate the borderline ridiculousness that is using dozens (if not more) products/services from $BIGCLOUD.

I've also found this configuration is actually MUCH more reliable than most $BIGCLOUD. No more wondering what's going on with a $BIGCLOUD outage that they won't even acknowledge (and that you have absolutely no control over). Coming from a background in telecom and healthcare it's completely wild to me how uptime has actually gotten much worse with cloud providers. Usually you can just tell customers "oh the internet is having problems today" because they'll probably be seeing headlines about it but for many applications that's just totally unacceptable - and we should expect better.

[0] - https://www.section179.org/section_179_deduction/

[1] = https://www.section179.org/section_179_leases/

Keep backups in any case. Preferably on another provider or at least in a different physical location. And, of course, test them.

And if you are managing a good backup regime, and monitoring your data/app anyway, is monitoring drives a significant extra hardship?

-- [1] in fact if you automate the restore process to another location, which I do for a couple of my bits, then you can just hit that button and update DNS when complete, and maybe allocate a bit more RAM+cores (my test mirrors are smaller than the live VMs as they don't need to serve real use patterns).

Even if I did want to update, it's just a case of pulling the latest version into the docker-compose template and re-running the ansible playbook. Obviously if the upgrade requires more then so be it, but it's no different to any other setup work wise.

Probably the only thing I _need_ to do which I do manually is test my backups. But I have a script for each project which does it so I just SSH on, run the one-liner, check the result and it's done. I do that roughly once a month or so, but I also get emails if a backup fails.

So it can be no time at all. Usually it's probably 1-2 hours a month if I'm taking updates on a semi-regular basis. But that will scale with the more things you host and manage.

In other words, the only difference is where the ansible inventory file comes from. Either it's a static list of IPs, or it comes from terraform.

Main app is Clojure, so I run a native JVM. Database is fully distributed, RethinkDB, now working on moving to FoundationDB.

The important thing is not to manage anything manually, e.g. treat physical servers just like any other cloud server. It shouldn't matter whether it's physical or virtualized.

I had to wait a few days to fetch my last one but I got it. Always do : )

On OVH's website: OVH cloud / Bare metal & VPS / ECO Dedicated Servers.

P.S: back in the days the "Kimsufi" (french for "qui me suffit", literally "which is enough (for me)") used to be part of OVH, then OVH spun Kimsufi out of OVH and then now... Kimsufi are back into OVH (the older Kimsufi servers are still accessed using the old Kimsufi credentials but the newer ones are using the OVH credentials again).

I just meant that I wouldn't recommend the 5 EUR / month dedicated servers for production: these do not have a big bandwidth and they don't have ECC RAM.

I edited my other post accordingly.

Seeing their single greatest cost line-item being "site moderation" (more than developer salary!) is such a stark reminder of where the real problems running an internet service are.

This is a new thing as of last week, I think.

Also, Oracle Cloud's management interface is best described as "let's make this as complicated as AWS, but with more 'Enterprise-y' features, but somehow worse in every possible way."

That said, I can't fault Oracle for being Oracle. I knew what I was getting myself into. And their "Always Free" tier is still free. And it does work well enough for my purposes.

Was a customer for years, and one day they said my server had died and gave some excuse that there was no way to physically access the hard drive as it was in a rack of other servers or something along those lines.

So what happens to my data? It can't be recovered but when is it going to be securely destroyed?

Like GP, I'm also using D1 (https://developers.cloudflare.com/d1) which is based on SQLite and still in early Alpha. In combination with KV (https://developers.cloudflare.com/workers/learning/how-kv-wo...) it's trivial to have a great database layer with caching using kysely (https://github.com/aidenwallis/kysely-d1) and trpc (https://trpc.io) you can have typing from DB to front end.

    ./sql/0001_create_users.sql
    ./sql/0002_create_sessions.sql
    ....

Then I do:

   ls ./sql | xargs -I{} wrangler d1 execute <db> --file {}

I'm nervous about them changing their pricing too, but just the fact that they're so much more transparent than AWS or GCE is a net plus for me, even with an increase in price.

[0]https://simplywall.st/stocks/us/software/nyse-net/cloudflare...

(ignore the contents and forecast of the article and just look at the graph)

A) Customers actually chase the credit, which (again IME) many companies make very difficult

B) The downtime is very clearly complete downtime. I've seen instances where a mobile app is completely down (but the web product works) or a key API is down (but the core product works) or there are delays in processing data (but eventually things are coming through). All of these can cause downstream downtime to customers but may not be covered by a "downtime" SLA.

Vultr’s, as an example I’m familiar with, being a customer, but which I believe is pretty typical:

• 100% uptime, except for up to ten minutes’ downtime (per event) with 24 hours’ notice or if they decide there was a time-critical patch or update. (I have one VPS with Vultr, and got notice of possible outages—identified purely by searching “vultr service alert” in my email—8× in 2022, 3× in 2021, 14× in 2020, 9× in 2019. No idea how many of them led to actual outage.)

• They’ll give you credits according to a particular schedule, 24–144× as much as the outage time (capped at a month’s worth after a 7h outage, which is actually considerably better than most SLAs I’ve ever read). Never mind the fact that if you’re running business on this and actually depending on the SLA, you’re probably losing a lot more than what you’re going to get credited for.

• Onus of reporting outages and requesting credits is on you, by submitting a support ticket manually and explicitly requesting credit. So the vast majority of SLA breaches (>99.9%, I expect; I don’t care to speculate how many more nines could be added) will never actually be compensated. And determination of whether an eligible outage occurred is at their sole discretion, so that they could frankly get away with denying everything all the time if they wanted to.

Such SLAs basically just completely lack fangs. I suppose you’d want something along the lines of insurance instead of an SLA, if it all mattered to you.

Like OVH - if you need support for anything beyond provisioning/troubleshooting things outside of the VM, it's not the best choice.

If you compare it with ec2 support costs + vm costs... it's difficult to have it all.

Digital Ocean does a good job of support too, but I'd rather not need support (with most tooling self-serve) than have support but have issues. I've had VMs at vultr running for 3+ years with very few issues (one host migration which they did "live" for me and notified me a few days in advance). I've had more issues with degraded instances in ec2 that require a ticket sent to ec2 support and 3-days wait for them to assign it to a new host.

http://www.johncompanies.com/

I'll counter that. I found that their customer service was acceptable as far as I could tell. I ran an OpenBSD bare metal server on them for quite a while.

Were they great? No. But I have also found that the big guys aren't that great either. Sure, the big buys hit a lot more problems so it's likely your issue is resolved because somebody big paying lots of money also just had that problem.

However, if your problem is semi-unique and some large customer isn't also having it, you are completely SOL with the big providers. They will never fix your issue.

   How much is the service of cron-job.org?
   Our service is entirely free of charge.

https://my.frantech.ca/aff.php?aff=3460

This is the parent company of BuyVM. They have a very good reputation, but their stock goes up and down throughout the month. If you want a specific data-center location, wait until the first of the month when stock replenishes.

I think you'll still find deals like this on lowendbox occasionally.

Original deal: https://lowendbox.com/blog/cyber-monday-virmach-vps-deals-as...

And reboot your servers regularly.

I do agree that there are some core services that I don't want changing out from under me without my notice/prior testing. But then there's also a lot of stuff installed that I don't use directly (eg OpenSSH) in my application and I'm not sure if those are attack vectors.

A bit cheeky, but to highlight the point: you just locked yourself out of SSH.

I think OpenVZ has kernel patches for RHEL7's 3.10.x kernel, which is supported by Red Hat till 2024. So in theory it's possible to have a secure OpenVZ VM but in reality bad practices (like heavy overselling the hardware) flock together.

Enabling swap during the update sounds like an elegant solution.

But unless it's a simple static site it's usually not, and it's usually a source of a lot of complexity and pain. Which unless you really are doing something twitter scale, is not worth it.

By the time you've bought a handful of tiny VPSs and put in the work to horizontally scale your service, you could have put the same money with zero effort into a very reliable dedicated server. Spend the effort elsewhere and save your sanity (and probably improve your reliability).

Yes I'm biased against horizontal scaling.

The cheapest Ryzen with a RAM upgrade does get pretty close too, and at least that's a modern CPU.