Cloud infrastructure and DevOps in Bengaluru
A Bengaluru startup's cloud bill is invoiced in dollars and its revenue usually arrives in rupees, so the bill can grow even when usage does not. Add the environments a departed engineer left running, instances sized for a launch that never came, and a deploy process only one person understands, and infrastructure becomes the line item the founders dread reviewing each month.
We find where the money goes and cut the obvious waste where you already are, whether that is AWS's Mumbai or Hyderabad region, Google Cloud or Azure. We put the infrastructure in Terraform so it can be read and rebuilt, make deploys something anyone on the team can run, and set up alerts that page a human only when a human is needed. We also run our own K3s cluster, so we can tell you honestly when self-hosting pays.
Bengaluru is where we live and work, so this page is less a pitch than a description of the market we see every week. The defining fact about it is that startups and global capability centres, the in-house engineering offices of foreign companies, are competing for the same engineers. A GCC can offer a larger salary, a guaranteed bonus and a stable employer. A Series A startup offers equity and a harder job. The engineer you want usually has more than one offer, a notice period to serve, and a counter-offer waiting. So the roadmap slips while the hiring plan catches up.
The companies that call us here come in a few recognisable shapes. Startups whose first backend was written by an engineer who has since left, often for one of those GCCs. SaaS companies built in Bengaluru and sold to customers in the US and Europe from the first year, now closing their first enterprise account and the feature list that comes with it. Deep tech teams in space, robotics, semiconductors and applied AI, where the core work is research or hardware and the software around it, the dashboards, device APIs and data pipelines, is nobody's job. And GCC leaders who need a working proof of concept before headquarters will approve the headcount to build the real thing.
What they need built is usually a defined piece rather than a whole product. A backend mapped, documented and made safe to change. Single sign-on, custom roles and tenant isolation for the enterprise deal. A device API and a dashboard for a robotics team whose engineers would rather be working on the robot. A proof of concept a GCC can demo to its parent company. We build those in your repository, in increments that ship, and write the architecture notes and runbooks as we go, so whoever you hire next can read them in their first week.
We share your time zone, so the working day is the same on both sides and a question asked in the morning is answered in the morning. Because we are in the same city, a kickoff or an architecture session can happen at your office rather than on a call. Most of the work still happens in writing, in your repository and your chat, because a decision written down survives the people who made it.
We are the right fit when you have a defined piece of work and want a senior engineer on it this month rather than after a hiring round. Start with a fixed-price two-week piece and judge us on what ships. We also cover the months before your next hire joins, and work white-label for Bengaluru agencies under your name.
Four ways this arrives.
Resources were created in the console over several years and nobody can say which ones matter. We inventory the account, bring what is live into Terraform, remove what is not, and hand you a repository that describes the whole estate.
It is usually idle capacity, oversized instances, forgotten environments and data transfer nobody priced. We find where the money goes, cut the obvious waste where you already are, and only then ask whether a cheaper provider such as Hetzner suits your steady workloads.
One person knows the steps and every release waits for them. We build a pipeline that tests, builds and deploys on merge, with rollback to the previous image, so shipping on a Friday afternoon is a decision rather than a gamble.
The channel fires all day, so everyone has muted it, so real outages are reported by customers. We alert on what users actually feel, route each alert to a named owner, and delete every alert nobody would act on at 3am.
A K3s cluster on Hetzner that we provisioned and are on call for, deployed through Flux, where only a push to master can produce an image production will run.
Read the write-up →Asked by Bengaluru teams.
Can we meet in person?+
Yes. We are in Bengaluru, so a kickoff, a design review or a whiteboard session at your office is easy to arrange. We share your time zone, so calls happen inside your normal working day. Day to day we work in your tools, Slack, GitHub and Linear or whatever you already use, and you talk directly to the engineer writing the code. In-person time is best spent on the first architecture discussion and the handover.
Do you build for Bengaluru SaaS companies selling abroad?+
Yes, and it is one of the most common pieces of work we see here. We build what the first overseas enterprise customer asks for: single sign-on, custom roles, tenant isolation that holds under a missing filter, a log of who changed what, and billing through Stripe that copes with several currencies. The work happens inside your product, in increments that ship, so the deal keeps moving while the list gets shorter.
How does your rate compare to hiring in Bengaluru?+
PayScale puts a mid-career software engineer in Bengaluru at about ₹18 lakh a year. Our published rate is $35 an hour, with a $5,000 minimum. For that you get a senior engineer who writes the code, works in your Slack, GitHub and Linear, and starts within days, with no recruiting round, notice period or employment overhead. Begin with a fixed-price two-week piece at $2,800 and judge us on what ships.
We keep losing engineers to GCCs. How can you help?+
We add senior capacity while you rebuild the team. An engagement starts within days, so the roadmap keeps moving through the notice periods and counter-offers. We take a defined piece of work, ship it in your repository, and write the architecture notes and runbooks your next hire reads in their first week. The code belongs to you from the first commit, so picking it up later is a conversation, not a project.
Should we run our own Kubernetes cluster?+
Usually not. Self-hosting starts to pay when your managed bill is mostly things you do not use, your workloads are steady rather than spiky, and someone is willing to own the control plane. We run our own on Hetzner, so we know what that job involves. If nobody on your side wants it, managed is cheaper in total even when the invoice is larger.
Do we need Kubernetes at all?+
Often not. Plenty of products are better served by a managed container service, a platform like Railway, or two virtual machines and a good deploy script. Kubernetes earns its place when you run several services, have steady traffic and have people to look after it. We will recommend the least infrastructure that does the job, and say so when that is less than you expected.
Which clouds do you work with?+
AWS most often, then Google Cloud, Azure and Hetzner. We work in whichever one you are already on, because moving clouds is rarely the cheapest fix for a cost or reliability problem. If we think a move is worth it, we will show you the case using your own bill before anyone migrates anything.
Can you cut our cloud bill without a migration?+
Usually, yes. Most of a bill that has grown unchecked is idle capacity, oversized instances, environments left running and data transfer nobody priced, and all of that is fixed where you already are. We will not promise a percentage before we have read the bill. After the first week we can tell you what is realistic and what it takes to get there.
Who is on call?+
Whoever the engagement says, in writing. While we run your infrastructure it can be us, with hours and response times agreed up front. If you are taking it in-house, the handover includes the runbooks, the alert routing and a rota your team can actually staff. We do not leave behind a pager that only we know how to answer.