DevOps Practices in iGaming: Experience and Checklist

DevOps practices in iGaming are the engineering habits that keep real-money platforms available, consistent, and auditable under unpredictable traffic: domains managed as configuration, templated operator integrations, idempotent wallet transactions, releases that roll back on bet and deposit metrics, and autoscaling on request and queue signals.

2 a.m., Tuesday. A registrar experiences a technical failure, and your primary domain stops working in your largest market. There is no match or promotion underway, yet the platform is already unavailable to players. Teams usually prepare for major events, but in our experience, situations like these catch them off guard.

Peaks keep growing. For the 2026 World Cup, Flutter Entertainment expected up to 100,000 bets per minute at peak moments across its platforms, Reuters reported. Every major tournament and seasonal promotion now creates the same kind of spike.

We manage infrastructure for game providers, iGaming platforms, and the B2B services surrounding them. This is not an overview of every DevOps tool, but rather three practices whose absence, in our experience, costs iGaming companies the most. For each, we'll cover the problem, the chosen approach, its limitations, and the results. At the end, we'll provide a checklist for evaluating a DevOps contractor or your in-house team.

Where iGaming Platforms Lose Money: Three Infrastructure Risks

In our experience, the most costly problems come from three areas, each addressed by a separate practice below:[object Object]

Domain unavailable in a key market. If the domain is hardcoded throughout the system, recovery takes hours, putting contracts at risk.
Integration with a new operator takes weeks. The contract is signed, but every week of delay means another week without revenue.
A release or traffic spike on a live platform. The question is not just whether the platform can handle the load, but whether every bet and every payment will be processed correctly.

Practice 1. Domain Outages: How to Reduce Recovery Time from Hours to Minutes

A domain is one of the most fragile points of an iGaming platform. It's easy to leave it out of the recovery plan: it's simply there until one day it stops working.

Why Replacing a Domain Took 12 Hours: A Casino Verification Service Case Study

Our client is a verification service for online casinos. Casinos display its certificate on their websites as proof that they have passed verification. The platform serves around 236,000 users and 70,000 casinos.

One day, the registrar experienced technical issues, and the primary domain became unavailable in one of the key markets. Certificates stopped appearing on casino websites, putting the reputation of both the service and the operators at risk.

A few weeks later, the registrar fixed the issue, and the domain came back online on its own. But the client couldn't afford to wait weeks or rely on the next issue resolving itself.

The main challenge wasn't the registrar. The domain was scattered throughout the system: in the code, database, article content, and static files. Every replacement meant finding all these references and making manual changes: 12–14 hours of downtime, with developers, DevOps engineers, and management on a call, regardless of the time of day.

Domain replacement across system components

Why On-the-Fly Request Rewriting Didn't Work

In the first few hours, we tried the quickest option: setting up an additional domain and configuring on-the-fly request rewriting. It didn't help. The old domain remained in the database, articles, and static files, so parts of the system continued pointing to the unavailable address.

This attempt revealed the core issue: the domain wasn't just an entry point to the system. Any local fix meant searching again for every place where the domain was referenced, and repeating the process with every subsequent incident.

Solution: Domain as Managed Configuration at the CDN and Service Mesh Levels

We stopped treating the domain as a constant and turned it into managed configuration:

Removed hardcoded dependencies. We went through the entire system, identified every place where the domain was hardcoded, and decoupled those dependencies.
Moved domain management to a separate layer. Routing rules at the CDN level (Amazon CloudFront) allow traffic behavior to be changed without rebuilding the application.
Configured response rewriting in the service mesh. Using EnvoyFilter in Istio, we configured the rewriting of the necessary data in responses without modifying the application code.
Handed over domain switching to the business team. Adding, replacing, or switching a domain at the infrastructure level now takes approximately five minutes, without involving developers or DevOps engineers.

Approach	Benefits	Limitations
Remove hardcoded dependencies only	Clean code without hidden dependencies	Without automation, switching may remain a manual process
Management layer only	Fast switching without code changes	Complexity accumulates, and hardcoded dependencies remain
Both	Switching in minutes and an easily maintainable system	More upfront work

Result: Domain Switching in 5–15 Minutes

Domain switching within the company's own infrastructure was reduced from 12–14 hours to 5–15 minutes. What previously required 12 hours of work by five people can now be done with a single click. The company can also prepare for restrictions in new markets in advance rather than reacting after the fact.

What to Check: Domain Outage Readiness

Identify every place where your domain is referenced: code, databases, content, configurations, emails, and partner settings.
Check whether you have a backup domain with a pre-issued certificate.
Determine how external websites, widgets, payment providers, and game providers will learn about the new domain. This is part of the recovery plan, not just an infrastructure concern.
Define who has the authority and technical ability to switch the domain at 3 a.m.

Practice 2. Operator Integration in Days Instead of Weeks

For a B2B provider, every new operator means new revenue. But between a signed contract and the first players lies an integration process, and it's usually not the adapter code that slows it down.

Why Operator Integration Takes Weeks

Our client is a B2B game provider handling around 1,500 requests per second (RPS) in total, with 21 operator integrations across five regulated jurisdictions. The company already had established integration patterns. Even so, a single integration could take three weeks, and that was assuming approvals arrived on time.

Three things consumed those weeks:

Every contract is slightly different. New fields, different error-handling logic, different assumptions about player sessions. Proven patterns help, but they don't cover everything.
Documentation doesn't match reality. In our case, the operator's API had an undocumented required field, a different identifier format, and retry logic that didn't match the documented status codes. These discrepancies could only be discovered in the sandbox, when the operator was already waiting.
A working integration is more than just code. Environment variables, database migrations, topics and access control lists (ACLs) in the message broker, and Argo CD configuration. All of these must be aligned and configured for each environment before the first successful request.

On top of that comes the classic cycle: find a discrepancy, contact the operator, wait for a response. Several days for each round.

Integration as a Pipeline: Configuration Templates and One Responsible Team

The first solution is organizational. One team handles the integration from environment preparation to the production release, without handing work between departments.

The second is templates. Each integration gets a separate set of platform configurations: variables, migrations, topics, ACLs, and deployment through Argo CD. The adapter isn't written from scratch: the specification is compared against proven patterns, followed by targeted tests against the sandbox.

AI Agent in the Operator's Sandbox: How to Shorten the Validation Cycle

We saved the most time by reducing delays wherever discrepancies could be verified independently. Instead of exchanging emails with the operator, we introduced a continuous validation cycle: an AI agent generated test scenarios, ran them against the operator's sandbox, analyzed responses, and prepared proposed fixes.

The agent can't modify a third-party API or make decisions for another team. But everything that could be determined through the sandbox now took hours instead of days.

What You Shouldn't Delegate to an AI Agent in Integrations

The agent doesn't decide what goes into production. Transaction business logic, code reviews, and release decisions remain the responsibility of engineers. Every change went through the client's standard pull request, review, and CI/CD process, without bypassing controls.

During one such review, engineers spotted a risky assumption in the request retry logic before it reached production. In a system that handles money, an error in retry logic poses a direct risk to transactions. Routine checks can be automated, but changes to transaction logic must be reviewed by engineers.

How to Quickly Identify Which Side Is Responsible for an Integration Failure

The hardest part turned out to be diagnostics, not code. From the outside, every sandbox failure looked the same: "something didn't work." But the causes varied each time: an incorrect payload format, expired credentials, or a service behaving differently from its documentation at that particular moment.

Before passing an issue to someone else, you need to know exactly where it originates: in the integration, the platform, the configuration, or the external API. Guesswork costs time, so evidence is essential. If the root cause lies outside the integration, changes must be coordinated with the team that owns the service rather than patched locally.

Result: From API Documentation to Production Release in 4 Working Days

With a two-week deadline, the team went from API documentation to a production release in 4 working days. The approach was also used for other integrations: a team of seven engineers launched 9 integrations in one quarter. This speed did not come at the expense of controls: all changes went through standard review and CI/CD processes. Integration-related incidents after release dropped by 30% across this portfolio.

What to Check: Operator Integration Speed

How many days does it take from receiving API documentation to production? If no one knows exactly, that's already an answer.
Do you have a configuration template for new integrations, or is each one set up manually?
How many days of the integration timeline are spent waiting for a response from the operator?
How quickly can you demonstrate which side is responsible for a failure?

Practice 3. Releases and Scaling Under Live Traffic: How to Maintain the Integrity of Bets and Payments

During a release or traffic spike, there are two questions, not one. First: will the platform stay operational? Second: will every bet and every payment be processed correctly? Availability monitoring doesn't always answer the second question.

Transaction Idempotency: Why Uptime Doesn't Guarantee Correctness

A platform can show all green on monitoring dashboards while still charging a player twice or losing a bet during a rollback. For the player, this is worse than a few minutes of downtime.

In most integrations, the provider calls the operator's wallet to debit a bet, credit winnings, or issue a refund. Networks are unreliable, so requests get retried.

That's why these operations must be idempotent. Repeating the same operation with the same identifier and parameters must not result in a duplicate charge. How duplicates and conflicts are handled, such as the same identifier with a different amount, is defined by the API contract.

A few rules we consider essential:

Retry only idempotent operations, using the same identifier and parameters.
Perform transaction reconciliation after any failure or rollback: compare what the service considers processed with what the operator records.
Establish a clear rule for handling bets that were in flight at the moment of rollback.

This is why the risky retry logic described in the previous practice matters. Uptime monitoring won't reveal these errors. You need code reviews, tests, transaction reconciliation, and business metric monitoring.

Automatic Release Rollback Based on Business Metrics

Gradual (canary) releases with automatic rollback typically rely on 5xx errors and latency. For iGaming, that's not enough: a release may produce no errors while reducing the bet acceptance rate or deposit success rate.

That's why release analysis should include business metrics: bet acceptance rate, deposit success rate, and number of game launches. The same approach applies to LiveOps changes such as bonus mechanics, odds updates, and game catalog changes: they roll out gradually without stopping the platform. Note that Argo CD only synchronizes configuration with Git, while automatic rollback based on metrics requires separate tools, such as Argo Rollouts.

In GitOps, reverting to the previous configuration can be initiated through git revert. Recovery speed depends on deployment, while database changes and incomplete transactions require a separate plan.

Before major events, it's better to freeze risky releases and provision additional capacity in advance.

Autoscaling for Unpredictable Traffic Spikes

A game's viral success or an unexpectedly strong response to a promotion can generate traffic beyond forecasts. Scaling based solely on CPU utilization may react too slowly if the load first becomes visible in queues or request volumes.

Supplement CPU metrics with signals more closely related to workload, such as request rates and queue depth.
Combine Spot and On-Demand instances, but configure and test where workloads will move if Spot capacity disappears in the middle of a traffic spike.
Provision additional capacity ahead of promotions and game launches.
Keep DDoS protection and rate limiting enabled at all times, not just before major matches.

Audit Trail and Multi-Jurisdiction Configuration

Regulators and auditors ask the same question in different words: who changed production, when, and who approved it. The answer should come from the system, not from someone's memory.

Every production change goes through Git and the pipeline, with an author and an approval attached.
Each market's configuration lives as a separate set of values, not a separate branch of code, so the same code runs everywhere and market differences stay visible and reviewable.
Production access is role-based, and access changes are logged like any other change.

In the case study below, this kind of security hardening was part of the preparation for ISO/IEC 27001 certification.

Case Study: Zero-Downtime Migration from ECS to Amazon EKS

One of our clients, a B2B service for online casinos, came to us with unstable infrastructure running on Amazon ECS. Pipelines kept failing and blocking developers, while the product launch was being delayed. Downtime longer than a few minutes was unacceptable for this business, and releases were deployed daily.

The quickest option would have been to patch the old architecture to launch sooner. We proposed a different approach: set up new Amazon EKS clusters alongside the existing system and switch over without downtime. The client agreed, and after the migration, we focused on security and cost optimization.

The results:

Deployments became four times more frequent.
Mean time to recovery (MTTR) decreased by 82%.
Spot instances with automatic interruption handling through Karpenter delivered up to 80% savings on compute costs for workloads running on them.
Consolidation reduced the number of nodes by 30–35%.

What to Check: Releases and Scaling

Are bet acceptance rate or deposit success rate included among the conditions for automatic rollback?
Do you have a tested rollback procedure, and how long does it take?
What happens if the same debit request arrives twice?
What signals does your platform use for autoscaling?

Role	What it covers in iGaming	Tools
DevOps / Platform Engineer	Market environments, operator integration templates, infrastructure as code with Terraform and GitOps	Terraform, Argo CD, Amazon EKS, Karpenter
SRE (Site Reliability Engineering)	Reliability targets (SLOs) for bet placement, wallets and payments, 24/7 on-call, capacity ahead of major events	Datadog, Prometheus, Grafana
Release Engineer	Canary releases, rollback on bet and deposit metrics, release freeze before tournaments	Argo Rollouts, Argo CD
Security & Compliance Engineer	Audit trail of production changes, role-based access, vulnerability scanning	AWS WAF, AWS Security Hub, Amazon Inspector, Istio mTLS

In-House Team or DevOps Outsourcing: Which Model to Choose for iGaming

When infrastructure repeatedly fails, the easiest thing to do is blame people. In our experience, the problem is rarely the people. More often, it's the operating model and how responsibilities are assigned.

Signs Your Team Needs External DevOps Support

New integrations are stuck in a queue because the infrastructure for them is prepared manually.
Certain incidents can only be resolved by one specific person.
A launch in a new market is two months away, but the infrastructure requirements for it still haven't been defined.
An audit is approaching, but you can't answer the question "who changed what in production and when" without asking the team.

Model	When It's Suitable	Main Risk
In-house team	Infrastructure is a core competency, and you have the time and budget to hire and retain engineers	Long hiring process, knowledge concentrated among a few people
Staff augmentation	You need additional engineers for specific tasks, while architectural decisions remain your responsibility	You manage the process and are responsible for the results yourself
Managed services	You need results: stability, on-call support, and infrastructure development aligned with business needs	Dependency on the contractor if infrastructure is not defined as code

No model is inherently better than the others. What matters is that responsibility for results is clearly defined and infrastructure is documented as code rather than stored in one engineer's head. This makes it easier to change teams or contractors.

Case Study: Eight DevOps Teams in Six Months and What Turned Things Around

The B2B service for online casinos whose migration we described earlier had changed eight DevOps teams in six months before coming to us. Pipelines kept failing, the product launch was delayed, and management and developers were running out of patience.

Two part-time engineers stabilized the project. What helped wasn't more people, but a different approach: building a new architecture alongside the old one, managing all infrastructure with Terraform, implementing GitOps, and conducting thorough code reviews because the company had neither a CTO nor an architect. Strengthening infrastructure security became part of the preparation for ISO/IEC 27001 certification, which the company later obtained.

This is how DevOps managed services work: instead of selling engineering hours, the contractor takes on agreed responsibility for the platform's stability and development. If you're currently choosing a service model, take a look at our approach to DevOps outsourcing for iGaming.

Area	Question	Strong Answer	Red Flag
Domains	How long does it take to switch to a new domain?	Minutes, without a release, with a tested procedure	"We'll change the config and redeploy"
Domains	Where does the domain "live" in your system?	Domain dependencies are known, and switching is centralized and tested	"We'll need to search through the code"
Domains	Is a backup domain with a valid certificate ready?	Yes, tested, and partners know the backup addresses	"We'll buy one if needed"
Integrations	How long does operator integration take from API documentation to production?	A timeline estimate with assumptions, dependencies, and data from previous integrations	"It depends on the circumstances," without explanation
Integrations	What do you do when the operator's API doesn't match its documentation?	A rapid sandbox testing cycle with evidence for the operator	"We send questions and wait"
Integrations	How do you distinguish your own error from a partner's error?	Logs and traces show which side is responsible for the failure; an escalation procedure is in place	"We check everything until we find the problem"
Releases & Transactions	What triggers an automatic rollback?	Errors plus bet acceptance rate and deposit success rate	"We roll back manually if someone notices"
Releases & Transactions	What happens if the same debit request arrives twice?	It is processed only once; duplicate handling rules are defined in the API contract	Silence or "That never happens"
Releases & Transactions	How do you roll back a release?	A tested rollback procedure with a known execution time and a separate plan for database changes	"We'll rebuild the previous version"
Scaling	What signals does the platform use for autoscaling?	Request rates and queue depth alongside CPU, plus additional capacity ahead of promotions and launches	"CPU only, that's the default configuration"
Scaling	What happens if Spot capacity disappears during a traffic spike?	Configured and tested recovery using available capacity, including On-Demand instances	"We'll notice and figure it out"
Audit	Can you show who changed production last Friday and who approved it?	Yes, from Git and the pipeline, within minutes	"Let me ask the team"
Audit	Is all infrastructure defined as code?	Yes, across all environments	"Mostly, except for a few manual changes"
Metrics	What metrics do you report monthly?	DORA metrics, including deployment frequency, change failure rate, and recovery time, plus bet acceptance rate and deposit success rate	Uptime only
Metrics	What was your MTTR last quarter?	A specific figure and trend	No figure available
Cost	How much did the last traffic spike cost in cloud expenses?	Cost per event, with an owner assigned to each expense category	"We'll see it on the monthly bill"
Partnership	Who is on call on Saturday evening during peak traffic?	A defined on-call schedule, incident response procedures, and response times	"Our DevOps engineer, he's always available"
Partnership	What will we receive if we decide to leave?	All infrastructure code, documentation, procedures, and access credentials	"We'll hand over what we can"

If some of your answers sound like those in the right-hand column, it's not a verdict but a plan for improvement. How we address these gaps is described on our DevOps services for iGaming page.

Frequently Asked Questions About DevOps in iGaming

How Does DevOps in iGaming Differ from DevOps in Fintech?

What they have in common is real-time money transactions and zero tolerance for duplicate transactions. What makes iGaming different is game integrations with operator wallets, processing bets, winnings, and cancellations, gambling regulatory requirements, and traffic spikes during matches and promotions.

Does an iGaming Platform Need Kubernetes?

Not always. Kubernetes makes sense when you have many services, frequent releases, multiple environments for different markets, and uneven workloads. For a small platform with just a few services, managed container services like Amazon ECS can be simpler and cheaper.

What's more important is having infrastructure defined as code. This makes future migrations easier, although deployment configurations and some processes will still need to be adapted.

Which Tools Do iGaming DevOps Teams Use?

The stack depends on the platform, but in our iGaming projects it typically includes Terraform for infrastructure as code, Argo CD and Argo Rollouts for GitOps and gradual releases, Amazon EKS with Karpenter for containers and autoscaling, Istio as a service mesh, Amazon CloudFront as a CDN, and Datadog for monitoring. The tools matter less than the practices built around them.

What Determines the Cost of DevOps for iGaming?

Four factors have the biggest impact:

How many environments and markets need to be supported.
Whether 24/7 on-call support is required.
How many new integrations are launched each month.
How much of the infrastructure is already defined as code.

The last point is often underestimated: the more manual configurations there are, the longer and more expensive the initial phase becomes.

Strong DevOps practices in iGaming don't make a platform invulnerable. They make the unexpected manageable: domains can be switched in minutes, new operators can be launched in days, and risks to bets and payments during releases remain under control. Start with the checklist above: it will quickly show you where your biggest risks lie.

Want to know where the risks are in your platform? Tell us what's causing the most trouble right now: domains, operator integrations, or releases under heavy load. Contact us, and our engineer will go through the checklist with you and suggest where to start before you make any commitments.

DevOps Practices in iGaming: What Really Keeps Casinos and Betting Platforms Running