How I Accidentally Became the DevOps Guy | Sarthak GaudToggle themeMenu<br>←All Texts<br>How I Accidentally Became the DevOps Guy<br>July 31, 2026<br>2089 words

I have been deploying full stack products for more than three years now, from simple CRUD apps to real-time systems and long running tasks. But until recently, I had never used AWS, GCP, or any traditional cloud provider directly. I had never even created an account on one. For most personal and work products, the modern SaaS and PaaS (Software as a Service and Platform as a Service) ecosystem was more than enough. My stack for the last two years was mostly Supabase for Postgres, authentication, and object storage, Vercel for frontends and Render for servers.

I loved the Render + Supabase + Vercel combo because it was easy to operate. Deployments, logs, and metrics worked out of the box, and the infrastructure rarely demanded fixes. Vercel even gave every project a free URL, which was perfect for putting something online and showing it to people. Supabase was similarly hard to argue against as It provided authentication, Postgres, object storage, a table viewer, and a SQL editor in one place. The performance was good enough for what I was building, and the free tier was generous. I used this stack for almost every personal project and for roughly the first year and a half of my work at an early stage startup.

But with time costs changed, Render’s legacy Hobby plan included 100 GB of outbound bandwidth, but the new Hobby plan reduced that to just 5 GB. Although Render made additional bandwidth cheaper but losing 95 GB of included bandwidth was still a major turnoff for me. For the instance sizes we compared, Render’s managed compute could also cost close to twice as much as the raw compute on AWS or GCP. It is not a completely fair comparison because Render also gives us deployments, logs, metrics, and a much simpler operating experience, but the difference becomes harder to ignore as the system grows. It becomes especially visible when every product got development, staging, and production environments. AWS would still require those environments, of course, but repeatedly paying the higher per-service price makes the total climb quickly.

Supabase itself was not the problem I actually love Supabase. Once we decided to move the larger system to AWS, keeping the database there through RDS (Relational Database Service) made more sense than leaving a major dependency outside the new infrastructure. That is how I ended up planning an AWS migration without having used a traditional cloud provider even once before.

One of our first decisions was to use Terraform from the start. If the entire infrastructure were one EC2 instance, creating it manually from the AWS console would probably be fine. But once we have several projects, environments, accounts, permissions, and connected services, remembering every console setting and repeating it correctly becomes unrealistic. This migration covered four projects. Some had development and production environments, while others also had staging. A few needed equivalent deployments across different AWS accounts for client companies and our own team. Terraform turned that setup into a repeatable and deterministic step instead of me keeping everything in my head.

I learned Terraform while doing the migration, so I would not claim to understand every corner of it and hence I stayed with the foundations. I kept databases, compute services, and the other parts of the infrastructure organized separately. I reused the same Terraform definitions with environment-specific values, while names, clusters, accounts, and state remained isolated. This let us create variations of the same infrastructure without rewriting it for every environment.

For compute, we chose ECS (Elastic Container Service) with Fargate rather than managing EC2 (Elastic Compute Cloud) instances ourselves. ECS managed the containerized services, Fargate maintained the underlying servers and ECS Service Auto Scaling gave us a path to increase or decrease the number of tasks as demand changed.

The backend migration roughly looked like this:

BeforeAfterPurposeRender deploymentsGitHub Actions + ECRBuild and deploy containersRender runtimeECS on FargateRun backend servicesPlatform-managed routingRoute 53 + ACM + ALBDomains, HTTPS, and routingRender environment variablesSecrets Manager + ECS configurationSecrets and configurationSupabase AuthClerkAuthenticationSupabase PostgresRDSDatabaseSupabase StorageS3Object storageUpstashElastiCacheRedisARQSQS + EventBridgeBackground jobs and schedulingGrafanaGrafanaObservability

Clerk was not an AWS replacement, but it was simple, trusted, and had a generous free tier. Grafana did not need replacing at all. We were already sending it our logs, metrics, and traces before the migration, so moving to CloudWatch would have created work without solving a real problem.

The new setup also introduced pieces I had never needed to manage...