The AWS free tier lets you do a lot, and if you use it well, it lets you avoid up to about $50/month of digitalocean bills.

If you're never planning on scaling past a hobby project, the free tier is a great place to stay. If your hobby project "goes viral," though, it might cost you a few thousand dollars, but hopefully that helps you get a lot more money to turn your hobby into a business.

If you have commercial intent, however, $50/month goes from an expensive hobby (3 streaming services) to a very cheap business. At that point, the fact that you don't have to pay for scale on DO VMs and other platforms actually makes a lot more sense. You can sleep at night knowing that you will still have a business even under a load spike, and $50 of digital Ocean buys you roughly the compute power of $1000+ of AWS managed services.

The beauty of container based serverless is that you have portability. If your hobby project takes off and you want to run it on DO up to a certain ramp, you can still move your container workload into DO.

Google Cloud Run, Azure Container Apps, and AWS AppRunner (less so because it doesn't scale to zero) are really great tools for hobby devs and small shops.

> The beauty of container based serverless is that you have portability.

I think this is the major take away I am having from this hype cycle of the Cloud: that if we just build containers/functions, we can sort everything else out however the credit card allows.

I'm on the fence about if it should be DO or EKS or GKE or whatever. That's for Credit Card Man and me to decide. As an engineer, I just want to build a docker container and call it a day.

Yep, we were easily saving a developer salary per month vs AWS using colo’d hardware even as a very small company. And god help you if you’re trying to run something bandwidth intensive on AWS.

What happens if your server's hardware seriously breaks?

Then there are a few other physical servers with load balanced redundant VMs, and it fails over seamlessly. HAProxy makes this pretty easy to handle. But we almost never had any hardware issues, servers are pretty reliable.

Sounds pretty much like a... cloud? :-D

Actually I think that private cloud-like architecture (a bunch of physical servers with e.g. Dokku running on them) can be a good solution in some circumstances.

Yes, this isn't as much of a gotcha as you make it seem. On prem is literally running your own cloud. The architecture that all the big cloud providers use of racks and racks of servers running hypervisors deploying VMs using a shared storage tier and SDN is the same thing you build when you're on-prem. You are now just the implementor.

You use the spare that's next to it, failing that, in a desperate situation, go to any computer store, buy the biggest gaming PC you can find, load it up with RAM and use that. It'll work, your customers won't know nor care.

In practice, I wouldn't recommend colocation until you are at the scale and budget where you can maintain your own spares. Better outsource it to a dedicated host like OVH/Hetzner/etc that has tons of servers and can immediately replace the hardware.

> it lets you avoid up to about $50/month of digitalocean bills.

Wish I'd know about this AWS free tier, because that sounds a lot like my monthly digital ocean bill :')

What are you running that costs $50/month? Several services with decent amounts of traffic?

If you run an RDS instance, I can see hitting that.

But there are alternatives like using Supabase or any of the Postgres or MySQL aligned serverless DBs like Cockroach, Planetscale, or other services if you want relational semantics and still be serverless.

The pattern that is free on AWS and costs money on digital ocean is: one or two VPS-es (or equivalent serverless/kubernetes compute) plus a managed database instance. If you don't have the managed database, the AWS free tier is a lot less attractive.

Agree, we bootstrapped a business from cents a month to $4 or $5 now, there's no maintenance, and I know if we get mentioned on Oprah - we'll be able to cope with a blip thousands of signups a second. I know how I'd run the system on our own hardware but can put off that decision to when (or if) we need it.

if you're spending less than 2$ per month how much traffic -> how much money can you make?

Sure, I also have plenty of static websites hosted for free by vercel / netlify / heroku / yourpick and even free functions.

As soon as you start hitting traffic, functions start to cost a lot vs your own vps.

My ideal setup right now is free static hosting from the marketing budget of friendly saas, free cloudflare on top and then APIs hosted on small vps (I have plenty of stuff on digitalocean but if I were to start from scratch I'd go fully with hetzner).

I avoid the big 3 as much as I can and I laugh for hours when I see the bills of clients using them.

Google Cloud Run pricing is:

- 2 million requests/mo free

- First 180,000 vCPU seconds free

- First 360,000 GiB seconds free

Then:

- $0.000024 /vCPU seconds

- $0.0000025 /GiB seconds

- $0.40 per million requests

This will get you pretty far for $2/mo. Within the free tier itself, assuming you can process each request in 250ms on a 1 vCPU container, you get 720,000 requests before you start paying for compute usage. Each $1.00 is another ~38,000 vCPU seconds (@1 GiB second) or ~152,000 requests @ 250ms per request.

Roughly speaking, $2/mo. is 1 million requests @ 250ms each request consuming 1 GiB seconds on a 1 vCPU container.

(There's some nominal cost for egress and storage of container images).

The thing that holds me back from Google cloud run Is that it is difficult to replicate that exact environment locally for testing and dev. If you’re working with stateless apps then that’s fine, But what is the typical local workflow of developing against a database, task Queue, etc.?

Which database?

If you're going all-in on Google Cloud and using Firestore, then use the emulators [0]. The emulators includes Pub/Sub. For Cloud Task Queues, use an unofficial emulator [1]

If you're not going all-in on Google Cloud and say you want to use Postgres, then use a `docker-compose.yaml` file and pull in a Postgres container instance or run a local Postgres if you want. Then pick a free Postgres compatible cloud service for the actual runtime (e.g. Supabase free tier). Same goes for MySQL.

For AWS, I'd use LocalStack [2]

[0] https://github.com/CharlieDigital/dn6-firebase

[1] https://github.com/aertje/cloud-tasks-emulator

[2] https://localstack.cloud/

Thank you for the reply. That makes sense… I guess something about me just likes the purity of running the exact same container on my local machine as would be in prod, but yeah I agree that at some scale that doesn't work.

If you're using an IaC tool like Terraform or Pulumi, you can just setup/tear down test resources on demand (for integration/acceptance tests). Under normal usage, hopefully you can get away with mocks/stubs/fakes. Some development frameworks make this a lot easier than others

Using real resources is usually fine for smaller applications but can be very problematic as your application grows. With that in mind, it's good to create boundaries so you limit the amount of "real infrastructure" you need to test/deploy. Reference https://martinfowler.com/bliki/IntegrationTest.html

Thanks for taking the time to reply. Yeah ideally we always use real resources to mirror prod closely, but I see your point that that won’t always be possible as the app grows.

Another balance is to just use real resources in CI with some concurrency control to make sure a single build runs at once. Locally, you continue to use mocks/stubs/fakes

You still get assurance from testing but reduce the amount of places you run the "expensive" (time, resource, $) tests

“ there is almost nothing better for the indie hacker, bootstrapper, or startup than cloud services.”

heroku, a vps or a dedicated server are all in the cloud, not sure what you mean by this.

Yeah I can’t agree with you at all. Without setting up your own NAT Gateway on EC2 on a t2.micro instance (or something cheap like that), it runs you about $30. This isn’t even accounting for database costs, usage costs, development costs, etc.

So right away that “I can’t believe they even charge my CC for $0.02” is real suspect. Do you have a completely empty AWS account?

We haven’t even spoken about dev experience yet.

> Without setting up your own NAT Gateway on EC2 on a t2.micro instance...

The problem is that you're using EC2 instead of AWS App Runner, Google Cloud Run, or Azure Container Apps.

> We haven’t even spoken about dev experience yet.

I'd strongly recommend that you give Google Cloud Run a try. You can go from empty codebase to running, on demand serverlesss runtime via GitHub with only a Dockerfile. I can build an app from scratch and have it running in Google Cloud in probably under 3 minutes with no special CLI knowledge or build.

Here's a sample Dockerfile I'd need to get a dotnet app into Google Cloud Run:

  # The build environment
  FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine as build
  WORKDIR /app
  COPY . .
  RUN dotnet restore
  RUN dotnet publish -o /app/published-app --configuration Release

  # The runtime
  FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine as runtime
  WORKDIR /app
  COPY --from=build /app/published-app /app

  # The value production is used in Program.cs to set the URL for Google Cloud Run
  ENV ASPNETCORE_ENVIRONMENT=production
  ENV IS_GOOGLE_CLOUD=true

  ENTRYPOINT [ "dotnet", "/app/my-app.dll" ]

Every other aspect of the code remains unchanged. GCR will pull the code from GitHub, build the container, and operationalize it.

https://github.com/CharlieDigital/dn6-mongo-react-valtio

Where do you store your secrets? Persistent data? How do you handle authentication and authorization when using cloud run only?

Authentication and authorization: I hand it off to Firebase identity management. But you can also just issue your own JWTs. You can run full applications in GCR like KeyCloak or IdentityServer. But the Firebase identity solution is really good.

Example here: https://github.com/CharlieDigital/dn6-firebase

Persistent data: Firestore (or Supabase, Planetscale, or CockroachDB if you want relational). On other platforms, I've used Azure CosmosDB which has a pay-as-you-go model which is practically free for hobby/POC use cases.

Secrets: depends on how secret it is; actual keys go into secrets manager in GCP which integrates with Cloud Run. Otherwise, you can configure it as an environment variable.

Your monthly spend is less than two dollars across GCP, AWS and Azure? If that's true, then of course it makes sense at your scale to stick with them.