← Back to context

Comment by ryanSrich

6 hours ago

Question: for a smaller SaaS tool, or even internal product. If a team doesn't want to manage AWS or another IaaS provider, what are the best alternatives for the following

1.) Vercel - having a bad month

2.) Supabase - having a bad month

3.) Railway - now having a bad month

DigitalOcean. Seriously. They have been around a long long time and built a lot of the core infrastructure you rely on every day (e.g. Ceph).

  • I have read plenty of snark about them on HN, but I found their product incredibly useful, well-designed, and easy to work with. If I was building a new startup from scratch, I'd definitely be giving them a look.

    I'm sure there are plenty of the like 1,000 AWS products that DO has no viable competitor for, but for what they do offer, they're great.

  • I've had nothing but good experiences with them and their docs and tutorials are excellent.

  • Yes, I use DO with Hatchbox. It is a perfect combo. Been using for more and more projects.

If you are unable to use IaaS directly. You need to accept that your service might be down.

Even if you use AWS and the like, if you aren't building your app with redundancy across multiple AZs, then you'll have some downtime occasionally.

And even if you do build redundancy with multiple AZ, some services might fail anyway as AWS is not entirely isolated. So you might have downtimes.

So just accept downtimes and use the best tool for you (unless they are really bad, like GitHub level bad). If you cannot accept any downtime, you'll have to spend millions of dollars and months of work to have the confidence to expect no downtime. Something like Netflix's chaos monkey and infrastructure would be enough.

  • The advantage of going with AWS is that when us-east-1 goes down, half the internet goes down so you don't have to defend why you had a service outage.

I think the message here is that you can't trust any single cloud provider. You at least need two with full operational capability.

  • Yup. I don't know enough people at giant companies to know how many actually do this though. Not just talking having 2 AZs, I'm talking about ability in a DR scenario to fail over, within 5-10 minutes, to a different cloud provider, e.g. AWS → Hetzner, or GCP → Azure.

    My gut feeling is that the number of significant applications that have this capability can probably be counted on two hands. Especially since a lot of the largest footprints of software stacks running in the cloud belong to Google and Microsoft, who I'm pretty sure do not replicate their services into someone else's cloud.

    • Before the cloud it was commonplace to have redundant data centres from two or more colocation provider companies. Similarly, Internet uplink diversity was commonplace.

An intermediary can provide value but there’s also a risk so I’d consider why you don’t want to use AWS, GCP, etc. directly. All of the major cloud providers have services which are only slightly harder than what Railway does but allow you to grow into more advanced things as your needs expand without adding a third-party who controls your features, security, and availability.

As an example, I note that GCP responded within 7 minutes according to their timeline. If you’d been using Cloud Run, that would have reduced downtime by over 7 hours — and there’s a good chance that you never would have gone down in the first place if the unknown trigger event was related to other customer activity or something odd Railway did.

There’s also a complexity factor: note how much complex infrastructure they mentioned having to fix that you wouldn’t need for your own account. That code does useful things, I’m sure, but it’s also a lot of moving parts which a hosting provider needs and you don’t – this outage took everyone down, whereas individual AWS or bare metal users would’ve otherwise been unaffected. There isn’t a global optimum which is the same for everyone but I think developers are prone to wildly over-estimating how much time they save by removing a couple of deployment steps relative to the direct costs and the less obvious costs of working within someone else’s environment.

  • This entire thread illustrates why you don’t want Google in any critical part of your business. AWS, sure. Azure? Maybe. I’m not familiar with Azure, but if I have to pick one, it’s AWS.

Fly, Render, and even Heroku still are all better choices then working with Railway I think

  • I love Fly, but their docs are.. tough. They've had multiple iterations of the control plane API, and it's very hard to do things the "correct" way with conflicting official docs.

Why does nobody consider that you can buy a baremetal box or even a VPS and that will get you very far without paying a metered fee

Hatchbox + Digital Ocean is an unbeatable combo and provides Railway-like automation with self-owned infra.

Depending on exactly what you're building, all of these things sounds like one VPS. A bit of maintenance/security burden managing the machine if you're not used to it but as the others have said: Next.js can be selfhosted, unless you need the serverless/edge stuff; then I would go to Cloudflare Workers.

Maybe a VPS? Simple to manage and way cheaper.

But really any service (or even on-site hosting) can have downtime, if that's not acceptable then I suppose building/using a tool that can be distributed between multiple hosts located in different geographical areas is the best option.

Haven't used railway but my understanding is they are something similar to Heroku. Fly.io has been pretty great for tiny projects in that niche.

For Vercel if your nextjs site can be compiled statically you could probably throw it up on almost anything. We've self hosted before which is pretty straightforward but you lose a lot of the image optimization stuff unless you go deep into setting up open next.

I love how everyone in Silicon Valley acts like Microsoft doesn’t exist.

Azure!

It’s the enterprise cloud with enterprise support. They won’t randomly pull the plug on your account, unlike companies that have a wildly different cultural background:

Google - ad tech (you’re the product)

Amazon - shop front (you’re a comptetitor)

Oracle - lawyers (you’re a future lawsuit for license extortion)

Etc…