R-team: from hand-started Windows servers to a GitOps trading platform on Kubernetes, at 40 % lower cost
R-team, a proprietary crypto trading firm, ran its bots, market-data feeds and execution engine as processes started by hand on three Windows servers. Trading never stops, so we could not stop it either. We built a Kubernetes platform alongside the old servers, ran both in parallel until the results matched, switched production over in one scripted evening and then put every service under GitOps.
Client: R-teamIndustry: Fintech / crypto tradingCloud: DigitalOceanEngagement: Feb 2025, ongoingTeam on our side: managed DevOps team
- 3 → 1Windows servers replaced by one Kubernetes cluster
- −40 %Infrastructure costs
- 32Applications deployed through GitOps
- 1 dayTo move four live core services to GitOps
The starting point
A 24/7 business running on processes nobody had written down
R-team trades around the clock across several exchanges. Its stack had grown the way trading stacks often do: about eighteen Python processes (bots, websocket market-data receivers, the execution engine, risk checks and reporting jobs) spread across three Windows servers and started by hand from batch files. There was no infrastructure as code, no central monitoring, and the list of what ran where lived mostly in people's heads.
That worked while the team was small. It stopped working as strategies multiplied: every new bot meant another manual start, a fix on one server could be forgotten on another, and nobody could say with certainty what was running in production. The question was how to move a business that never closes onto a modern platform without betting the trading book on the migration.
One platform, described in code
Every server, cluster, database and service defined in Git, so the state of production is something you read, not something you remember.
A migration that cannot lose money
The new platform had to prove itself against the old one with real trading data before it took over a single position.
Self-service for the trading team
Developers who write strategies should be able to ship a new bot without waiting for an infrastructure engineer.
What we built
The platform, layer by layer
Everything is defined as code and reviewed in pull requests. Infrastructure changes are planned on the pull request and applied only by a deliberate pipeline run.
How we migrated
Build alongside, prove it, then switch
Untangle the monolith first
Services lived in one repository and were started as scripts. We split them into their own repositories with their own pipelines and images.
- Shared trading code became versioned libraries in a private registry.
- Renovate opens the upgrade pull requests in every consumer.
Run both platforms in parallel
The Kubernetes platform ran next to the Windows servers on a separate trading account, fed by the same market data.
- R-team's own plan-versus-actual reports compared the two.
- Production moved only once the results matched closely (about 95 %).
Switch over in one scripted evening
The cutover followed a written thirteen-step plan in a quiet trading window.
- Stop the bots, close positions by script, switch production credentials, redeploy, watch.
- The Windows servers stayed as a test environment and were retired weeks later.
Putting live trading services under GitOps without touching them
After the cutover, services were still deployed by CI pipelines that pushed straight into the cluster and recreated secrets on every run. Git and the cluster had drifted apart. We moved the four core services (risk checks, market-data receivers, bot services and the execution engine) to Argo CD in one day, in waves ordered by risk, with the smallest service going first as a canary.
Two days later the platform components followed: telemetry, logging, metrics and DNS. Infrastructure deploy pipelines went from eight to five, and what runs in the cluster is now the same as what is in Git.
Delivery
From strategy to production, the same path every time
- WriteA developer works on a strategy or service in its own repository.
- BuildReusable pipeline templates build and test the image.
- PublishThe image and shared libraries go to the private registry.
- TagThe pipeline updates the image version in Git. It never touches the cluster.
- SyncArgo CD rolls the change out and keeps the cluster equal to Git.
- ObserveDashboards and alerts in the team chat show the effect.
A new bot is one values file in one chart. After the handover R-team's developers onboarded new bots themselves, without an infrastructure ticket. A rollback is a Git revert.
Operations
Running it day to day
Alerts that come with instructions
Alert rules live in Git next to the infrastructure and go to the team chat. Each one has a runbook entry, including a ready prompt for investigating it with an AI assistant.
Kubernetes kept current
The cluster was upgraded across three minor Kubernetes versions during the engagement, so R-team never ran on an unsupported release.
Smaller attack surface
Publicly reachable log and database endpoints were closed, and every application reads only its own secrets through a read-only policy.
Cost
Cheaper to run than the servers it replaced
The Windows servers were sized for the busiest hour and paid for around the clock. On Kubernetes, workloads share nodes and each workload class gets a pool sized for what it actually uses. That brought infrastructure costs down by 40 %.
Results
Where R-team is today
| Area | Before | Today |
|---|---|---|
| Where services run | About 18 processes on 3 Windows servers | One Kubernetes cluster, defined in Terraform |
| How they start | By hand, from batch files | Argo CD, from Git |
| What runs where | Partly undocumented | 32 applications, all visible in Git |
| Secrets | Recreated by pipelines on every run | Vault, read-only per application |
| New trading bot | Manual setup on a server | One values file, added by R-team's developers |
| Monitoring | None central | Metrics, logs, traces and alerts as code |
| Rollback | Manual | A Git revert |
| Infrastructure costs | Three servers sized for peak load | −40 % |
What's next
Where the platform can go from here
The obvious next steps are a separate test environment inside the cluster so the Windows test contour is no longer needed, moving the ingress controller and Grafana onto Argo CD as well, and an AI assistant that investigates plan-versus-actual alerts and posts its findings next to the alert.
