CI/CD pipeline
Build, test and deploy on every merge, with code-quality and security gates (SonarQube, OWASP checks).
Service · AWS deployment & DevOps
AWS deployment and DevOps, so releases stop being risky.
I set up the path from a merged pull request to production: Docker images, AWS environments, a CI/CD pipeline with quality and security gates, monitoring and a way back when a release goes wrong. I've run production infrastructure on AWS, and I built Theliv, a product that watches AWS bills.
- AWS
- Docker
- Kubernetes
- Jenkins
- Terraform
- SonarQube
- Grafana
01 — The problem
Deploying by hand doesn't scale.
Many early products are deployed from someone's laptop. It works until that person is on leave, a release breaks at night with no way to roll back, or the AWS bill doubles and nobody can say why.
A small, boring pipeline fixes most of it: every change built and tested the same way, deployed to staging first, promoted to production with one action and reversible with another. Monitoring tells you about problems before your users do, and a cost review stops paying for what you don't use.
02 — What you get
What you get.
Docker & AWS environments
Containerised services on EC2 or Lambda, with S3, networking and staging and production kept separate.
Monitoring & alerts
Dashboards, logs and alerts on the numbers that matter, routed to Slack or email.
Rollback & runbooks
A tested way back from a bad release, and written steps for the incidents you can predict.
Cloud cost review
Idle instances, unattached volumes and oversized resources found, priced and cleaned up.
03 — Process
How a project runs.
One point of contact, from planning to a deployed product your team owns.
01
Discovery call
A short call about the problem, your constraints and what done looks like. You leave knowing whether I'm the right fit.
02
Plan & proposal
A written plan covering scope, architecture, milestones and a timeline. Nothing starts until we both agree on it.
03
Weekly increments
Working software every week, with a demo and a short written update. No long silences.
04
Deploy & handover
Deployed to production, with the code in your repository, tests and CI/CD, a runbook, and a walkthrough with your team.
04 — Proof
Work that shows it.
Products I've designed, built and run myself. Each has a full case study.
Theliv — AWS cost-monitoring SaaS
Cross-account read-only IAM roles via one CloudFormation template and STS AssumeRole, Cost Explorer ingestion, and a scanner for idle EC2, unattached EBS and gp2 volumes.
Read the case studyDryDock Kit — multi-tenant SaaS starter
A Docker and CI deploy path with a readiness checker; the integration and security suites run in CI on every push.
Read the case study05 — Who it's for
A good fit if you are…
Teams deploying by hand, or without a pipeline, monitoring or rollback.
Startups moving from a single server or a PaaS to their own AWS account.
Products whose AWS bill has grown faster than their usage.
06 — FAQ
Before you get in touch.
Do you only work with AWS?
AWS is where I have the most production experience. Vercel and Docker-based hosts are fine for many products, and I'll say so in the plan if AWS is more than you need.
Can you take over an existing setup?
Yes. I start by documenting what exists, then fix the riskiest gaps first, usually rollback and monitoring, before anything else changes.
Will you need full access to our AWS account?
Only what the work needs. A review can start read-only; changes are made through the pipeline and infrastructure code, so every change is visible and reversible.
08 — Contact
Let's Build Something.
I take on a small number of projects at a time, from full product builds to deployment, performance and automation work: scoped, shipped, and handed over clean.
Bengaluru, India → Open to RelocationReplies under 24h