Kubernetes on-prem, SES off the table, same reliable email. Here is how we made that real in 3 months.
An on-prem email migration that actually shipped. Not a think piece, not a theory thread.
Just a real Kubernetes-based PHP SaaS that needed to get off AWS SES and move to Kubernetes on-prem without lighting up the support inbox.
We came in as the team that likes to live where app, infra, and email protocols all collide.
When “managed” stops being optional
The client’s SaaS lives or dies by outbound email.
Account signups, billing alerts, product notifications, and compliance messages. If the email pipeline coughs, tickets pile up, and churn follows.
Over time, the architecture leaned hard on managed cloud services:
- AWS SES for outbound mail
- SFTP on AWS for file-based flows
- Kubernetes across the board for the PHP microservices and platform
- PostgreSQL for data
Then the rules of the game changed. New regulatory and internal IT constraints meant they needed a Kubernetes on-prem footprint and could not depend on SES and managed SFTP in the long run.
The mandate was simple and very non-negotiable:
“Replicate what SES and SFTP give us, on our own Kubernetes on-prem environment, without breaking email deliverability.”
So now the challenge was clear:
Turn a cloud native mail backbone into a Kubernetes on-prem email platform in 3 months, while customers keep using the product.
The constraints that made this project fun
This was not a slow, best-effort migration. It came with some sharp edges.
- Hard deadline: 3 months to get Kubernetes on-prem live with full SMTP and SFTP capability
- Skill demand: real full stack, from PHP microservices down to Docker, Kubernetes, PostgreSQL
- Non-negotiable expertise: proper SMTP on-prem setup, DNS hygiene, and deliverability discipline
- Zero tolerance for rookie mistakes: no open relays, no SPF typos that tank reputation, no “fix DMARC later” attitude
They were not shopping for a generic cloud migration partner. They needed people fluent in AWS SES migration, on-premises SMTP stack design, and day-to-day Kubernetes operations.
That is exactly where we like to operate.
Why they picked us
The client brought us in because our comfort zone looks like their risk list:
- We treat email as a protocol ecosystem, not just a “send mail” API
- We have already built and run Kubernetes on-prem and cloud Kubernetes email workloads
- We work across the whole path: PHP code, microservices, SMTP servers, SFTP, DNS, and monitoring
In short, they wanted one accountable team for this AWS SES migration, not four vendors arguing over whose layer broke.
Architecture: from SES comfort to owned SMTP on Kubernetes on-prem
We resisted the temptation to clone SES feature by feature. Instead, we focused on what the SaaS actually relied on.
The new design introduced:
- A hardened SMTP relay layer running on Kubernetes on-prem, built on a battle-tested MTA
- A compact set of email microservices that mimic SES behavior where needed
- A new on-prem SFTP platform for file flows, wired into the existing PHP services
- Configuration-driven integration so the app code needed minimal surgery
To keep it readable, here is how we compressed the client’s 9 capability clusters into a short, practical checklist. No hidden magic, no hero servers. Just a clean Kubernetes on-prem email substrate the client could actually own.
How we executed the on prem email migration in 3 months
We ran this like a controlled refactor of critical plumbing, not a big bang reset.
Results
Within the 3-month window, the client achieved:
- A production-ready Kubernetes on-prem email platform and SFTP stack, fully integrated with their PHP SaaS
- Stable or better deliverability compared to their previous AWS SES setup
- Clear visibility into mail flow, queue health, bounces, and spam issues
- Reduced platform risk, with critical email and file transfers now living on infrastructure they control
Cost benefits showed up, but the headline win was control and predictability.
Technologies we used
Infrastructure & Orchestration
Email & Backend Services
Operations
What this says about our team
This case study is not just ''we moved some pods''.
It shows that we can:
- Design and operate Kubernetes on-prem platforms for mail-heavy SaaS products
- Handle on-prem email migration from AWS SES and SFTP without wrecking deliverability
- Work across app, infra, and ops so there is one accountable story from PHP function call to recipient inbox
If you are staring at a Kubernetes-based SaaS and wondering how to bring it on-prem without breaking critical email flows, this is the pattern we like to reuse: measure reality, design around real usage, build on proven components, migrate under observation, then hand off something your team can actually run.
