Plexo: a fintech platform where everything is in code and every change is reviewed
Plexo (plexo.global) is a stablecoin settlement network for licensed financial institutions. Since November 2025 our managed DevOps team has run their platform on AWS. We use the same practices for every client.
Client: PlexoIndustry: FintechCloud: AWSSince: November 2025Our role: managed DevOps team
- In codeevery account, network, identity and pipeline is defined in Git
- Reviewedevery change reaches production through a pull request
- Drilleda production restore tested for real and written into a runbook
- No keyspipelines sign in with short-lived identities, no stored cloud keys
The starting point
What a platform for licensed institutions has to do
Plexo works with licensed financial institutions, and any of them can ask for due diligence. The platform had to answer those questions calmly while the engineering team kept shipping fast with AI coding tools.
Ready for due diligence
A bank's security team asks how access is controlled, where changes are recorded and how recovery is tested. Each answer should point to something that exists: code, a log or a runbook.
Fast delivery that stays safe
Developers ship often and try ideas in isolated environments. Production changes only through review.
AI tools under control
AI speeds the team up. Its work goes through the same review and approval as a person's, and a human makes the risky calls.
What we build
The platform, layer by layer
Everything is defined as code and reviewed in pull requests. Nothing was clicked together in the console.
How we work
Seven practices behind the platform
Companies that serve regulated institutions get asked hard questions by their partners. These practices keep the answers short, because every change is written down, reviewed and tested.
Landing zone
Workloads live in separate cloud accounts by purpose. People sign in through one central identity with short-lived access, and data is encrypted by default.
- Production is isolated from development and testing.
- Access comes through roles and sessions that expire, not personal keys.
- Encryption keys belong to the client and rotate automatically.
Infrastructure as code, through pull requests
Nothing is clicked together in the console. Every change is code, reviewed in a pull request with its plan visible, and applied by the pipeline after approval.
- The reviewer sees exactly what will change before approving it.
- Pipelines sign in to the cloud with short-lived identities, so there are no stored cloud keys to leak.
- Secrets live in a secrets manager, never in Git.
GitOps with preview environments
What runs is what Git describes, so a deployment is visible and a rollback is a revert. A pull request can get its own temporary environment, removed when the pull request closes.
- An image is built once and the same image is promoted to production.
- Testing a risky idea costs nothing to clean up.
- Anyone can see which version runs where.
Observability
Metrics, logs, traces and alerts in one place, plus alerting that still reaches a human if the platform itself goes down.
- Alerts land in the team chat with enough context to act on.
- Cloud-level alarms and an external health check cover the case where the platform cannot report.
- Delivery metrics show how often changes ship and how often they fail.
Disaster recovery drills
We restore from backup for real and time every step. The result becomes a runbook that anyone on call can follow.
- The drill is planned and announced, then run on production.
- Every step and its duration goes into the runbook.
- Whatever the drill turns up is fixed in code and in the runbook.
Rules and risk classes for AI agents
Each repository carries written rules for AI agents. Every change is classed as contained, breaking or unclear. A breaking change needs a human OK, and an unclear one means stop and ask. Only the pipeline applies changes.
- The rules say what to check before a change, which commands exist and what is off limits.
- Agents can plan an infrastructure change. Applying it waits for a human approval in the pipeline.
- Where an agent only needs to look, it gets read-only access.
Decision records and post-mortems
Architecture decisions are recorded next to the code with their reasoning. Every incident gets a blameless post-mortem, and its lessons go into the code and the rules.
- Each piece of work gets a short record: the requirement, the decision and why, the plan and what actually happened.
- Cost decisions are written down too, so they can be revisited as the platform grows.
- The next engineer, or the next agent, starts with full context.
Timing a live restore of production
A backup helps only if the restore works when it is needed. We planned a drill, announced it, then restored the production database from backup for real and timed every step.
Delivery
One path from idea to production
- WriteAn engineer works on a branch, with AI tools that follow the repository's rules.
- CheckAutomated security and quality checks run on the pull request.
- PreviewA label gives the pull request its own full environment.
- MergeThe image is built once and development updates automatically.
- PromoteThe same image goes to production after approval.
- ObserveMetrics, logs and traces show the effect of the change.
Every change takes this path, whether a person or an agent wrote it. Because the path is always the same, a partner's question about how a change reached production has one answer.
In the client's words
"We build with AI agents every day, and the hard part was giving them room to move without losing control of infrastructure that has to pass a bank's due diligence. Gleb's team set that up as a system: everything in code, every change through a pull request, written rules the agents actually follow. Then they kept proving it works, down to timing a live restore of production. They've behaved like our own engineers, not an outsourced team."
Roman Shprenger, co-founder & CTO, Plexo
Questions
About this approach
What does a managed DevOps team do for a fintech?
It runs the cloud platform as a service: infrastructure as code, delivery pipelines, monitoring, incident response, updates and documentation. One lead is accountable for the result, and the work follows an agreed scope with response times instead of hours billed per person.
How can AI agents work on infrastructure without losing control?
Give them written rules in every repository, class each change by risk and let only the pipeline apply changes after a human approves. Agents get read-only access where they only need to look, and every decision is recorded next to the code.
How do you prove that disaster recovery works?
Restore from backup in a real drill, time every step and write the result into a runbook. Partners reviewing a platform ask for evidence, and a timed restore with a runbook gives them some.
What does a bank's due diligence ask about the platform?
Usually how access is controlled, how changes are reviewed and recorded, how data is encrypted and how recovery is tested. When everything is in code and every change goes through a pull request, most answers point to a file or a log.
