Skip to content
PRS India

Infrastructure, CI/CD and reliability

Cloud & DevOps

Infrastructure managed with Terraform, updates that go live in minutes and roll back in seconds, monitoring that catches an outage first, and cloud bills cut by 30–50% without hurting reliability.

Last updated

Start a project See related work
  • Zero-downtime updates: blue/green or rolling, with a rollback that takes seconds
  • Every setup can be rebuilt from Terraform, not made by hand in a console
  • 30–50% off the monthly cloud bill without cutting capacity or reliability
  • Alerts for problems your customers feel, not for 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 say what each line is for. That is usually the call we get. Somebody moved the servers to AWS two years ago. They called it a lift and shift. All it did was move the same oversized servers onto a meter that runs every second.

Lift and shift does not make anything newer. It moves 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. Now you pay for it by the hour, in dollars, forever.

We do the other work. We write your infrastructure as code, so your setups can be rebuilt and are not made by hand. We build an update pipeline that goes live in minutes, with a rollback that takes seconds. We add monitoring, so you learn about an outage from a graph and not from a customer. And we cut costs, often by 30–50%, without hurting reliability. Then we give you the runbooks and the Terraform, because infrastructure that only one agency understands is a risk, not a service.

Audit our cloud
Sound familiar

The state of most infrastructure we inherit.

Every one of these is common. Every one of these can also be fixed in weeks, not months.

  • Nobody can explain the bill

    Resources with no tags, a 6TB S3 bucket with no storage class full of debug logs from 2022, and a NAT gateway quietly costing more than two app servers.

  • The production server was configured by hand

    Someone logged in by SSH, installed things, and left. It cannot be rebuilt, it cannot be tested, and if the server dies the recovery plan is someone's memory.

  • Deploys are a ritual, not a command

    Twenty minutes of steps done by hand, at night, with the site down, by the one person who knows the order. Rollback means restoring a backup.

  • Customers tell you about outages

    No alerts on real problems, and no dashboard anyone opens. The first sign 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, passwords in a .env saved three years ago, never changed, and no secrets manager. A DPDP Act notice would be impossible to answer.

  • The backups have never been restored

    Snapshots are running, so everyone thinks they work. Nobody has ever tested a restore. A backup you have not tested is not a backup. It is a hope.

What changes

The numbers after we are done.

These are middle results across cloud and platform jobs over the last three years. Clients doubt the cost figure most at the start and are most surprised by it at the end. We get it by better design, not by cutting capacity.

Get a cloud audit
38%
Cut in monthly cloud spend

Same capacity, better p99 latency

6min
Commit to production

Fully automatic, zero downtime

45sec
Rollback time

One command, no drama

99.98%
Uptime

Rolling 12 months across managed estates

What you get

The platform, and the discipline around it.

All of it is in your cloud account and your repository, and written down so well that you could let us go on a Friday and ship on the Monday.

Infrastructure as code

Terraform for everything: VPC, servers, database, DNS, secrets, IAM. Your setups can be rebuilt from a repository, checked in pull requests, and never built by hand in a console again.

CI/CD that ships in minutes

Tests, code checks and a security scan on every pull request. Merge to main goes to staging by itself. Production goes live after 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 slow replies, errors and overload, the problems your customers really feel.

Cost engineering

Right-sized servers, storage rules that move old data to cheaper tiers, VPC endpoints instead of NAT charges, test servers switched off at night, and Savings Plans for steady use. Then we track cost for each service so it stays fixed.

Security you can evidence

Private subnets, IAM with only the access people need, secrets in a manager and changed often, encryption when stored and when sent, WAF at the edge, and an audit trail. Data kept in the right place for the DPDP Act where it applies.

Disaster recovery that was tested

Set RPO and RTO, automatic backups, and a restore practised on a schedule, which is the part everyone skips. A backup you have not tested is not a backup.

Where the ₹4.1 lakh actually went.

Cloud cost is a tech problem that the finance team gets blamed for.

The savings are almost never in a talk about discounts. They are in the design. A recent job: ₹4.1 lakh a month, down to ₹2.3 lakh, with no cut in capacity and faster p99 replies at the end. The fixes were plain.

Right-sizing came first. Eleven servers were set up for a load guess from 2022 that never came, and ran at 4–9% CPU. Then storage. 6TB of S3 with no storage class, including four years of debug logs nobody had ever read, was moved to Intelligent-Tiering and Glacier with a lifecycle rule. Then NAT gateway data charges, which cost more than two of the app servers together because every internal call went through it instead of a VPC endpoint. Then a staging setup that ran twenty-four hours a day for a team that works eight. It is now switched off at 9pm. Then Savings Plans for the truly steady use, and pay-as-you-go for the spikes.

None of this is clever. It is just work that nobody had done, because nobody owned the bill. So the last thing we set up is what stops it creeping back. That is cost tracking for each service by tag, an alert in 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 first find out what is really running, because half of it will not be in any document you have.

  1. 01

    Audit: cost, risk and reality

    1–2 weeks

    We list every running resource, tag it, and link every rupee to a service. We map the security risks, the single points of failure and the things nobody has written down. You get a written report with a ranked list, honest costs, and the three things we would fix this month even if you hired nobody.

  2. 02

    Import reality into Terraform

    2–3 weeks

    Whatever is running is turned into code: brought into state, written as modules, and checked in a pull request. From this point the console is read-only. Setups can be rebuilt, staging becomes a true copy of production, and "it works on the server" stops being something anyone says.

  3. 03

    Pipeline and zero-downtime deploys

    2–3 weeks

    Build, test, scan, put live. Database changes that work with both old and new code during the switch. Health checks that show the app is ready, not just running. Blue/green or rolling releases, and a rollback that is one command and does not need the author to be awake.

  4. 04

    Observability and alerting

    1–2 weeks

    Metrics, logs and traces connected, dashboards for the four golden signals, and alerts set to what customers feel. We delete the noisy alerts on purpose. An alert that fires on 80% CPU every Tuesday teaches your team to ignore the pager.

  5. 05

    Cost engineering

    2–3 weeks

    Right-size the servers, move storage to cheaper tiers, remove the NAT charges, switch test setups off out of hours, and commit to Savings Plans only for use we can prove is steady. Then track cost for each service and send an alert to Slack when it jumps, so the bill cannot quietly creep back.

  6. 06

    Handover, or hold the pager

    Ongoing

    A runbook for each kind of failure, a diagram that matches what is running, an on-call roster and a blame-free review after each incident. Your team can own it, or we run it on a retainer with a set response SLA. Either way you never depend 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 Load that really grows and shrinks, many teams
When it breaks

Incident response, before you need it.

The pager should not be a surprise

Levels of seriousness with set response times. An escalation roster with real names and real phone numbers. A runbook for every failure we know about, such as database failover, queue backlog, payment gateway down and disk full, written before the incident and not during it. Then a blame-free review afterwards that gives a code fix and a new monitor, never someone to blame.

Load-tested before the peak

We test at three times the expected peak before your sale day or admission season. Connection limits, queues and caches all break in surprising ways under real load. It is better to find that here than at 12:01am.

Backups you have restored

A set RPO and RTO, automatic snapshots, and a restore practised on a schedule. Most teams find out their backup does not work at the exact moment they need it.

Cost anomaly alerts

Per-service attribution by tag, and a Slack alert when any service moves more than 20% week on week. You learn about a job gone wrong in a day, not in a month-end bill.

Secrets, access and the DPDP Act

Passwords in a secrets manager and changed often, not in a .env saved in 2022. IAM with only the access people need, and a named person behind every role. Private subnets, encryption when stored and when sent, and data kept in the right place where the DPDP Act or a strict buyer needs it. When the compliance questionnaire arrives, you can answer it truthfully.

The stack

Standard tools, so you can hire for them.

Nothing custom, nothing owned by us, nothing that needs us in particular.

AWS
Google Cloud
Cloudflare
DigitalOcean
Proof

Estates we run, and estates we handed back.

All case studies
01
Turant Logistics — Logistics & Supply Chain

Cutting order-to-dispatch by 62% for a 400-truck 3PL

A fleet, ePOD and route-planning platform that works offline first, for drivers on roads with poor signal. The two ready...

62% faster
Faster order-to-dispatch on the ops floor
91% shorter
Shorter POD-to-invoice cycle (8.4 days to 19 hours)
18% lower
Fewer empty-run kilometres in the first full quarter
02
FealDeal — E-commerce — Ethnic Fashion

A high-catalogue ethnic-wear storefront for FealDeal

A Shopify store for a Surat ethnic-wear label. It has 200+ SKUs of lehengas, sarees and suits, sorted by type, colour, f...

Shopify
Platform
200+ SKUs
Catalogue
Mobile-first
Storefront
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 — where shoppers can browse by gender, brand, style and comb...

Shopify
Platform
Brand & style
Browse by
COD-ready
Checkout
FAQ

What CTOs ask us first.

Still have a question?

Usually four places, in this order. First, servers set up for a load guess that never came, now idle at under 10% CPU. Second, storage with no storage class, including years of debug logs. Third, NAT gateway data charges that can cost more than the servers behind them. Fourth, test setups running twenty-four hours a day for a team that works eight. We check, tag and link every rupee to a service, then fix the design. A 30–50% reduction with no capacity loss is a normal outcome.

Probably not, and we will happily talk you out of it. Kubernetes is worth its extra work when you have many services, many teams and load that really grows and shrinks. For a single Laravel app with a queue worker, ECS Fargate or a well-run set of EC2 servers behind a load balancer costs less to run, is far cheaper to hire for, and is 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. First, database changes that work with both old and new code during the switch. That means adding a column before you use it and removing it a release later, never both at once. Second, health checks that show the app is really ready, not just started. Third, a rollback that is one command and does not depend on the person who wrote the deploy script being awake.

Neat logs sent to Loki or CloudWatch that you can really search. Metrics in Prometheus with Grafana dashboards for the four signals that matter: speed, traffic, errors and overload. Tracing, so a slow request can be linked to the query or the outside call that caused it. Error tracking in Sentry with source maps. Uptime checks from outside your network. And alerts set to problems your customers feel, because an alert that fires on 80% CPU teaches people to ignore alerts.

Yes, and it is a big part of what we do. We start by bringing what exists into Terraform. Most of it will have been clicked together in a console with nothing written down. We write down what exists, find the security risks, find the costs, and give you a written plan. You get the state files, the runbooks and a diagram that matches what is really running. An agency that cannot hand those over is selling you dependence.

We can hold the pager, and we would rather teach you to. Either way we set up the same habits: levels of seriousness with set response times, an escalation roster, a runbook for each known failure, and a blame-free review after each incident that gives a fix and a monitor, not someone to blame. Retainers include a set response SLA. We will not 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 lines are wasted and about what they cost you, before you pay us anything.

Start a project Call +91 93102 49840
+91 93102 49840 aditi@prsindia.in

Proof

Shipped, measured, still running.

All case studies

Related services

Web Development

Live web applications built on Laravel, Next.js and Postgres. They are typed, tested, easy...

Explore

Mobile App Development

Flutter, React Native and native apps that keep working offline, on old phones and on a me...

Explore

Ecommerce Development

Commerce platforms where the checkout turns visits into sales and the back office numbers...

Explore

Let'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.

Start a project