Indonesia Remote DevOps Platform Engineer AI first  

The role
You will own the platform that Signal and Connect run on. Today that means a Kubernetes cluster onDigitalOcean with managed Postgres and Redis, an edge layer on Cloudflare, deploys through GitHubActions and Helm, and observability on Grafana and Loki. Tomorrow it means three data-residencyzones: the existing DigitalOcean UK zone plus two greenfield Azure zones (EU and US), all managedfrom one Terraform codebase so a single config change fans out to every zone.
The platform handles millions of requests across dozens of ecommerce brands, and the eventsflowing through it feed the advertising and analytics platforms our clients spend against. When itdegrades, someone's marketing data degrades with it.
This is a hands-on role. You will write Terraform, debug a failing deploy, tune a Cloudflare Workerroute, and review the pipeline that ships the app, sometimes all in the same week. You will also writecode beyond infrastructure: internal tooling, automation, the occasional fix in the Flask/Celery appwhen the problem sits between app and platform.
What is hard about this job
Honesty helps both of us here. This is a breadth role: edge, clusters, databases, pipelines, and the appwhen the problem lands between layers. Some days you will context-switch more than you wouldlike. Incidents are not abstract, when tracking breaks, a client's ad spend is flying blind, so pressurecomes with a commercial clock on it. Parts of the platform are better documented than others, andone of your jobs is to close that gap. And a small company means fewer specialists to lean on: moreautonomy, less cover. If you have only ever run infrastructure inside a large team, think about whetherthat trade excites you.
How we work
People create the advantage. We think critically and try to falsify our own conclusions beforeshipping them. We bias for action: a good change today beats a perfect one next month, and weimprove iteratively from there. We own outcomes end to end. If something is broken, the person whofound it fixes it or drives the fix, regardless of whose problem it officially is.
We are a small team and attitude carries more weight than skill. Skills can be learned; how you treatpeople when things go wrong cannot be taught as easily. We want someone who stays constructivewhen production is on fire, hears "this design has a problem" as useful information rather than anattack, and lets the best idea win no matter whose it was. Being wrong here is cheap and admitting itearly is respected. If you need to be the smartest person in the room, or you keep score on credit, wewill not work well together.
You would work directly with the CTO and the engineering team, with a lot of autonomy and theexpectation that you use it.

This is not a first DevOps role. We need someone who has already owned production infrastructureas their job, has been on the hook for uptime, and has scars from a migration or an incident to showfor it. You will be the owner of this platform from early on, with the CTO as your partner rather thanyour safety net.
Production Terraform experience: modules, state management, importing live infrastructure. Youhave done an import before and know why zero-destroy plans matter.
Kubernetes in production: Helm, ingress, upgrades, debugging workloads. DOKS or AKSexperience helps but the concepts transfer.
Solid Postgres and Redis operations: backups, connection handling, migrations under load.
CI/CD ownership: you have built and maintained GitHub Actions (or equivalent) pipelines thatother engineers depend on.
Cloudflare beyond DNS: Workers, WAF, routing. You do not need to be an expert, but our edgelayer is load-bearing. It includes traffic filtering at the edge, and you would operate and deploythose rules (the analysis behind them is a team effort you would grow into).
Enough software engineering to be dangerous: Python and TypeScript/JavaScript are what youwill meet most.
You communicate in writing. Decisions go in the repo, incidents get clear write-ups, and what isconfirmed stays separate from what is inferred.
Working AI-first
We build with AI as a default, and we expect you to work that way too. Concretely:
You use coding agents (Claude Code or similar) as your daily working mode, not as an occasionalautocomplete. You know when to hand work to an agent and when to do it yourself.
You write infrastructure and runbooks that agents can execute: explicit steps, checkableoutcomes, guardrails in the repo rather than in someone's head. Our current runbooks are writtenthis way and we want to go further.
You review AI-written code and plans critically. You can spot when an agent is confidently wrongabout a Terraform plan or a Kubernetes manifest.
You look at every recurring manual task and ask whether an agent, a workflow, or a monitor shouldbe doing it instead. Much of our ops automation already runs this way.
If your instinct is that AI tools are a threat to craft rather than a multiplier of it, this is not the right role.
We pay for the tooling we expect you to use: frontier-model coding agents and whatever else earnsits keep. You will not be asked to work AI-first on a personal ChatGPT subscription.