SaaS · 2026

Cloud migration, CI/CD and test automation for a SaaS

An engagement for a SaaS product whose releases had become risky: deployments by hand over SSH, no staging, and bugs found by customers. The product moves to containers in the cloud, gets a pipeline from pull request to production, and gains the tests that make releasing routine.

Built by

Tech leadDevOpsBackendQA

Client: Withheld at the client’s request
Scope: Cloud · CI/CD · Monitoring · Tests
Environments: Dev · Staging · Production
Typical timeline: 8–12 weeks
Squad: 4 people · 3 disciplines

Technologies

Docker
Kubernetes
Terraform
GitHub Actions
AWS
Prometheus
Grafana
Sentry
Playwright
k6

The product

10 images

One way to production, with rollback ready
Problems seen before customers see them
Tests on every change, load tests before big releases
Infrastructure changes are reviewed like code, with the plan and its cost
Every service, its replicas and its version in each environment
An 18-minute incident, written up without blame, with follow-ups tracked
Cloud spend by service and environment, against a monthly budget
Only customer-facing problems page the on-call engineer
A live preview for every pull request, with flags per environment
The page on the on-call phone: what broke, what changed, what to do

Brief

Every release was a late night.

Context

The product had grown to many paying companies on a single server, set up by hand years ago.

Problem

Releases happened at night over SSH, there was no staging, a rollback meant restoring a backup, and outages were reported by customers.

Goals

Infrastructure written as code
A staging copy of production
Tested, one-click releases
Problems seen before customers see them

Team

The squad behind it.

Tech leadMigration plan and release process	×1	Migration plan and release process	Senior
DevOps engineerInfrastructure as code, pipelines and monitoring	×1	Infrastructure as code, pipelines and monitoring	Senior
Backend engineerApp changes for containers and health checks	×1	App changes for containers and health checks	Senior
QA engineerEnd-to-end and load tests in the pipeline	×1	End-to-end and load tests in the pipeline	Senior

Meet the team

Backend & architecture

Small changes so the app fits the cloud.

Who worked on it

Tech leadBackend

The application is adjusted to run in containers: configuration from the environment, files in object storage, sessions in Redis, and health endpoints the platform can check.

Production workloads with replicas, autoscaling targets, CPU and memory use, restarts and image versions, plus one service restarting at its memory limit. — Every service, its replicas and its version in each environment

Decision 1
Stateless app servers
Any instance can be replaced or added at any time.
Trade-off · Uploads and sessions move to shared services.
Decision 2
Database migrations run before traffic shifts
Old and new versions must both work during a deploy.
Trade-off · Breaking schema changes are split across two releases.

DevOps

From pull request to production, the same way every time.

Who worked on it

BackendDevOps

All infrastructure is defined in Terraform and reviewed like code. Every pull request is built and tested, merging deploys to staging, and production is a one-click promotion with an automatic rollback if health checks fail.

Release pipeline from build to tests, staging and a manual production promote, with environment health and deploy history. — One way to production, with rollback ready

Infrastructure pull request with the Terraform plan for production: resources to add, change and destroy, reviewers, policy checks and the monthly cost change. — Infrastructure changes are reviewed like code, with the plan and its cost

Blameless postmortem of a SEV-2 incident: timeline from alert to recovery, error and connection-pool chart, impact, causes and follow-up actions. — An 18-minute incident, written up without blame, with follow-ups tracked

Infrastructure as codeEvery change reviewed and repeatable.
Automatic rollbackFailed health checks undo the release.
Alerts that matterErrors and latency, routed to on-call.

Tests that run on every change.

Who worked on it

DevOpsQA

We start with the flows customers use most — sign-in, billing, the main dashboard — and cover them with end-to-end tests in the pipeline. A load test runs on staging before each major release.