NM Company
A portfolio and enquiry site for events firm NM Company
A visual portfolio and enquiry website for an event management and supplies firm — presenting a full...
Read itInfrastructure, CI/CD and reliability
Cloud & DevOps
Terraform-managed infrastructure, deploys that ship in minutes and roll back in seconds, observability that catches the outage first, and cloud bills cut by 30–50% without touching reliability.
- Zero-downtime deploys — blue/green or rolling, with a rollback measured in seconds
- Every environment reproducible from Terraform, not hand-carved in a console
- 30–50% off the monthly cloud bill without cutting capacity or reliability
- Alerts that fire on symptoms your customers feel, not on CPU percentage
What this is
Lift and shift just moves the bill.
The bill arrives, it says ₹4.2 lakh, and nobody in the company can explain which line item is doing what. That is usually the call we get. Somebody moved the servers to AWS two years ago — a lift and shift, they called it — and all it did was move the same over-provisioned boxes onto a meter that runs every second.
Lift and shift does not modernise anything. It relocates your problems and adds a bill. The idle server that ran at 6% CPU in the datacentre now runs at 6% CPU on an m5.2xlarge, and now you are paying for it by the hour, in dollars, forever.
We do the other work: infrastructure as code so your environments are reproducible instead of hand-carved, a deploy pipeline that ships in minutes with a rollback that takes seconds, observability so you learn about an outage from a graph rather than from a customer, and cost engineering that routinely takes 30–50% off the bill without touching reliability. Then we hand you the runbooks and the Terraform, because infrastructure only one agency understands is a liability, not a service.
Sound familiar
The state of most infrastructure we inherit.
Every one of these is normal. Every one of these is also fixable in weeks, not quarters.
-
Nobody can explain the bill
Untagged resources, an unclassed 6TB S3 bucket full of debug logs from 2022, and a NAT gateway quietly costing more than two application servers.
-
The production server was configured by hand
Someone SSH'd in, installed things, and left. It cannot be reproduced, it cannot be tested, and if the instance dies the recovery plan is a memory.
-
Deploys are a ritual, not a command
Twenty minutes of manual steps, at night, with the site down, performed by the one person who knows the sequence. Rollback means restoring a backup.
-
Customers tell you about outages
No alerting on symptoms, no dashboard anyone opens. The first signal that checkout is broken is a WhatsApp message from the founder.
-
The database is on a public IP
Security groups open to 0.0.0.0/0, credentials in a .env committed three years ago, no rotation, no secrets manager. A DPDP Act notice would be unanswerable.
-
The backups have never been restored
Snapshots are running, so everyone assumes they work. Nobody has ever tested a restore. An untested backup is not a backup, it is a hope.
What changes
The numbers after we are done.
Medians across cloud and platform engagements over the last three years. The cost figure is the one clients are most sceptical about beforehand and most surprised by afterwards — and it is achieved by architecture, not by cutting capacity.
Get a cloud audit
0%
Cut in monthly cloud spend
Same capacity, better p99 latency
0min
Commit to production
Fully automated, zero downtime
0sec
Rollback time
One command, no heroics
0%
Uptime
Rolling 12 months across managed estates
What you get
The platform, and the discipline around it.
All of it in your cloud account, in your repository, documented well enough that you could fire us on a Friday and ship on the Monday.
Infrastructure as code
Terraform for everything — VPC, compute, database, DNS, secrets, IAM. Environments are reproducible from a repository, reviewed in pull requests, and never hand-carved in a console again.
CI/CD that ships in minutes
Tests, static analysis and a security scan on every pull request. Merge to main deploys to staging automatically; production goes out behind an approval, blue/green, with a one-command rollback.
Observability worth paying for
Prometheus and Grafana, structured logs in Loki, distributed tracing, Sentry with source maps. Alerts on latency, errors and saturation — the symptoms your customers actually feel.
Cost engineering
Right-sizing, storage lifecycle policies, VPC endpoints instead of NAT charges, off-hours schedules for non-production, Savings Plans on the steady baseline. Then per-service attribution so it stays fixed.
Security you can evidence
Private subnets, least-privilege IAM, secrets in a manager and rotated, encryption at rest and in transit, WAF at the edge, and an audit trail. DPDP-aware data residency where it applies.
Disaster recovery that was tested
Defined RPO and RTO, automated backups, and — the part everyone skips — a restore rehearsed on a schedule. An untested backup is not a backup.
Where the ₹4.1 lakh actually went.
Cloud cost is an engineering problem that finance gets blamed for.
The savings are almost never in a discount negotiation. They are in the architecture. A recent engagement: ₹4.1 lakh a month, down to ₹2.3 lakh, no reduction in capacity and better p99 latency at the end of it. The line items were unglamorous.
Right-sizing came first: eleven instances provisioned for a load projection from 2022 that never arrived, running at 4–9% CPU. Then storage — 6TB of unclassed S3 including four years of debug logs nobody had ever read, moved to Intelligent-Tiering and Glacier with a lifecycle policy. Then NAT gateway data processing charges, which were costing more than two of the application servers combined because every internal service call was routing through it instead of a VPC endpoint. Then a staging environment that ran twenty-four hours a day for a team that works eight, now scheduled off at 9pm. Then Savings Plans on the genuinely steady baseline, on-demand for the spiky remainder.
None of this is clever. It is just work that nobody had done, because nobody owned the bill. So the last thing we install is the thing that keeps it from creeping back: per-service cost attribution by tag, an anomaly alert into your Slack when a service moves more than 20% week on week, and a monthly review where a name is next to every number.
How we engage
Nothing gets migrated before it gets understood.
We do not touch production in week one. We find out what is actually running first, because half of it will not be in any document you have.
-
01
Audit: cost, risk and reality
1–2 weeksWe inventory every running resource, tag it, and attribute every rupee to a service. We map the security exposure, the single points of failure and the things nobody has documented. You get a written report with a prioritised list, honest costs, and the three things we would fix this month even if you hired nobody.
-
02
Import reality into Terraform
2–3 weeksWhatever is running gets codified — imported into state, expressed in modules, reviewed in a pull request. From this point the console is read-only. Environments become reproducible, staging becomes an honest copy of production, and "it works on the server" stops being a sentence anyone says.
-
03
Pipeline and zero-downtime deploys
2–3 weeksBuild, test, scan, deploy. Backward-compatible migrations so old and new code can both run during rollover. Health checks that mean readiness, not liveness. Blue/green or rolling releases, and a rollback that is one command and does not require the author to be awake.
-
04
Observability and alerting
1–2 weeksMetrics, logs and traces wired up, dashboards for the four golden signals, and alerts tuned to what customers feel. We deliberately delete the noisy alerts — an alert that fires on 80% CPU every Tuesday is training your team to ignore the pager.
-
05
Cost engineering
2–3 weeksRight-size, tier the storage, kill the NAT charges, schedule non-production off out of hours, and commit to Savings Plans only on the baseline we can prove is steady. Then per-service cost attribution and an anomaly alert into Slack, so the bill cannot quietly creep back.
-
06
Handover, or hold the pager
OngoingRunbooks per failure mode, an architecture diagram that matches what is running, an on-call rota and a blameless post-incident process. Your team can own it, or we run it on a retainer with a defined response SLA. Either way you are never dependent on us to recover.
The honest call
How much platform do you actually need?
| Managed PaaS | ECS / Fargate | Kubernetes | |
|---|---|---|---|
| Time to production | Days | 2–4 weeks | 6–10 weeks |
| Ops burden on your team | Minimal | Low | Real, ongoing |
| Cost at small scale | Highest | Low | High — control plane and people |
| Many services, many teams | No | Workable | Excellent |
| Hiring pool in India | Large | Large | Smaller, pricier |
| Debuggable at 2am by a mid-level engineer | Yes | Yes | No |
| Sensible when | Early stage, one app | Most companies, honestly | Genuinely elastic, many teams |
When it breaks
Incident response, before you need it.
The pager should not be a surprise
Severity levels with defined response times. An escalation rota with real names and real phone numbers. A runbook for every failure mode we know about — database failover, queue backlog, third-party gateway down, disk full — written before the incident, not during it. And a blameless review afterwards that produces a code fix and a new monitor, never a scapegoat.
Load-tested before the peak
We test at three times expected peak before your sale day or admission season. Connection limits, queue depth and cache behaviour all fail in interesting ways under real load — better here than at 12:01am.
Backups you have restored
A defined RPO and RTO, automated snapshots, and a restore rehearsed on a schedule. Most teams discover their backup is unusable at exactly the moment it matters.
Cost anomaly alerts
Per-service attribution by tag, and a Slack alert when any service moves more than 20% week on week. You find out about a runaway job in a day, not in a month-end invoice.
Secrets, access and the DPDP Act
Credentials in a secrets manager and rotated, not in a .env committed in 2022. Least-privilege IAM with a named human behind every role. Private subnets, encryption at rest and in transit, and data residency handled where the DPDP Act or a regulated buyer requires it. When the compliance questionnaire arrives, you can answer it truthfully.
The stack
Standard tools, so you can hire for them.
Nothing bespoke, nothing proprietary, nothing that requires us specifically.
AWS
Google Cloud
Cloudflare
DigitalOcean
Terraform
Docker
Kubernetes / EKS
ECS Fargate
ArgoCD
GitHub Actions
Prometheus
Grafana
Loki
OpenTelemetry
Sentry
PagerDuty
Proof
All case studies
Estates we run, and estates we handed back.
01
FealDeal — E-commerce — Ethnic Fashion
A high-catalogue ethnic-wear storefront for FealDeal
A Shopify storefront for a Surat ethnic-wear label — 200+ SKUs of lehengas, sarees and suits organised by type, colour,...
Shopify
Platform
0+ SKUs
Catalogue
Mobile-first
Storefront
02
Turant Logistics — Logistics & Supply Chain
Cutting order-to-dispatch by 62% for a 400-truck 3PL
A fleet, ePOD and route-optimisation platform built offline-first for drivers in low-connectivity corridors — because th...
0% faster
Faster order-to-dispatch on the ops floor
0% shorter
Shorter POD-to-invoice cycle (8.4 days to 19 hours)
0% lower
Fewer empty-run kilometres in the first full quarter
03
Collection by Rehan — E-commerce — Watches & Accessories
A brand-led watch and eyewear store for Collection by Rehan
A Shopify storefront for a Surat watch and eyewear retailer — browsable by gender, brand, style and combo, with predicti...
Shopify
Platform
Brand & style
Browse by
COD-ready
Checkout
Usually four places, in this order: instances provisioned for a load projection that never arrived and now idle at under 10% CPU; storage nobody classed, including years of debug logs; NAT gateway data processing charges that can exceed the cost of the servers behind them; and non-production environments running twenty-four hours a day for a team that works eight. We audit, tag and attribute every rupee to a service, then fix the architecture. A 30–50% reduction with no capacity loss is a normal outcome.
Probably not, and we will happily talk you out of it. Kubernetes earns its complexity when you have many services, many teams and genuinely elastic load. For a single Laravel application with a queue worker, ECS Fargate or even a well-managed set of EC2 instances behind a load balancer is cheaper to run, far cheaper to hire for, and much harder to break at 2am. We have migrated more clients off Kubernetes than onto it, and none of them missed it.
Three things people usually skip. Backward-compatible database migrations, so the old and new code can both run against the schema during the rollover — that means adding a column before you use it and dropping it a release later, never both at once. Health checks that reflect real readiness, not just a process that has started. And a rollback path that is one command and does not depend on the person who wrote the deploy script being awake.
Structured logs shipped to Loki or CloudWatch and actually searchable. Metrics in Prometheus with Grafana dashboards for the four signals that matter — latency, traffic, errors, saturation. Distributed tracing so a slow request can be attributed to the query or the third-party call that caused it. Error tracking in Sentry with source maps. Uptime checks from outside your network. And alerts tuned to symptoms your customers feel, because an alert that fires on 80% CPU trains people to ignore alerts.
Yes, and it is a large part of what we do. We start by importing the reality into Terraform — most of it will have been clicked into a console with nothing written down. We document what exists, find the security exposure, find the cost, and give you a written plan. You get the state files, the runbooks and an architecture diagram that matches what is actually running. Any agency that cannot hand those over is selling you dependency.
We can hold the pager, and we would rather teach you to. Either way we set up the same discipline: severity levels with defined response times, an escalation rota, a runbook per known failure mode, and a blameless post-incident review that produces a fix and a monitor, not a scapegoat. Retainers include a defined response SLA. What we will not do is be the only people who know how to bring your system back up.
Send us last month's cloud bill.
We will tell you which three line items are wasted and roughly what they are costing you — before you have paid us anything.
Proof
Shipped, measured, still running.
Swasthya Sarathi
A healthcare-companion platform for Swasthya Sarathi
A multi-service healthcare platform that helps people find hospitals, doctors, labs, medical stores,...
Read itMV Tech Education
A course and admissions platform for MV Tech Education
A course-catalogue and admissions website for a Bihar vocational institute — leading with industrial...
Read itRelated services
Web Development
Production web applications built on Laravel, Next.js and Postgres — typed, tested, observ...
ExploreMobile App Development
Flutter, React Native and native apps that hold up offline, on old hardware and on a metro...
ExploreEcommerce Development
Commerce platforms where the checkout converts and the back office reconciles — multi-ware...
ExploreLet's talk cloud & devops
Bring us the hard version of the problem.
A senior engineer reads every enquiry. You'll get a real answer — scope, risk and a number — within one business day.