A team of four people building at night can't afford a release that needs someone awake to babysit it. My job at Trama is to make sure the pipeline is the one teammate that never sleeps.
I'm the DevOps side of Trama, and what I own is everything between "the code is written" and "the client is using it." Three services — the API, the web app and the WhatsApp agent — running on Google Cloud Run across three environments, each with its own PostgreSQL instance on Cloud SQL. Docker images built and pushed to Artifact Registry on every release. Database migrations that run as their own job and have to finish before a single request reaches the new version. And a pipeline that authenticates to Google Cloud through Workload Identity, so there is not one static credential sitting in a secret anywhere. Deploys are driven by tags: a release candidate goes to QA, a clean semantic version goes to Production behind an approval gate. Nobody deploys by hand. Not once.
What I learned this cycle is that infrastructure is a people problem wearing a technical costume. We're four co-founders with day jobs, meeting on Saturdays from 9pm to 5am. Every manual step in a release is a step that eventually happens at 3am by whoever is still conscious, and that's where outages come from. So the rule became: if it has to be remembered, it has to be automated. Trunk-based development, one main branch, no long-lived branches, protection rules that make it impossible to push straight to production. Not because I love process, but because process is what keeps a tired team from making an irreversible mistake on someone else's live inventory.
The hardest moment was a deploy that succeeded at nothing. Trying to make the pipeline faster, I removed a redundant validation step — and the change quietly left the deploy job in a "skipped" state. Every check was green. Every commit merged. And nothing had actually shipped to Dev for longer than I want to admit, because a pipeline that does nothing looks exactly like a pipeline that works. I've never forgotten the lesson: a pipeline that fails loudly is a gift, and a pipeline that fails silently is a liability. We put the redundant step back on purpose, with a comment explaining why, so the next person doesn't repeat my optimization.
The infrastructure our client depends on today is running real containers, real rolls and real orders. That's the part I'm proud of — not that it's clever, but that it's boring, repeatable, and it comes back up. If you see something in it that would break at scale, tell us. I'd much rather hear it here than at 3am.
Johan Sebastian Burgos Guerrero Co-founder & DevOps, TRAMA AI, Corp.
Log in or sign up for Devpost to join the conversation.