The Challenge: Live Exchanges on Hard-to-Reach Infrastructure
All three exchanges were hosted outside Iran. As internet disruptions increased, domestic users faced slower and less predictable access, while service-to-service connectivity was also affected. For businesses whose trading APIs, WebSockets, pricing, KYC, deposit, withdrawal, and notification services must remain available, this created a direct operational risk.
None of the projects had a dedicated DevOps team. Services were not containerized, production was the only environment, releases were manual, files lived on local server disks, and monitoring, redundancy, backup, disaster recovery, and security controls needed significant improvement.
The requirement was not simply to move servers. Each exchange needed an operating model in which one team remained accountable for platform health, security, deployments, and incident response after migration.
Audit First: A Migration Plan Before the First Change
Before execution, Dropp Tempo audited the overseas infrastructure of each project. We reviewed service architecture, databases, deployment paths, external dependencies, monitoring, backups, access controls, hardening, and failure scenarios.
The audits established a shared set of priorities: move hosting to Iran, containerize the services, create staging environments, introduce redundancy in critical layers, standardize deployments, migrate files to object storage, and build reliable backup and recovery paths.
A separate migration, cutover, and rollback runbook was prepared for each exchange. The Build phase therefore began with an operational plan—not a rushed selection of tools.
Three Migrations in About 20 Days Each, with Zero Data Loss
Each migration was completed in approximately 20 days. Services were first containerized and a staging environment was created. We then ran a trial migration to validate deployments, service connectivity, data recovery, and application behavior in the target environment before the production cutover.
During the final window, services were placed in read-only mode and the MongoDB and SQL Server databases were moved through a controlled dump-and-restore process. Dropp Tempo verified data integrity after restoration, followed by application testing from the development team.
All three cutovers finished in two hours or less with zero data loss. The previous infrastructure remained online for one month, keeping a rollback path available throughout the stabilization period.
Architecture for Availability, Performance, and Recovery
Across the three engagements, the target environments use a combination of Kubernetes and Docker Swarm. Services run on multi-node clusters, with NGINX or CDN services distributing traffic. This standardized deployment and capacity management while making isolated node failures manageable.
At the data layer, MongoDB runs as a replica set and SQL Server uses a standby node. Product files were moved from application-server disks to object storage. Failovers are controlled: the Incident Commander evaluates the situation and authorizes the switch.
Dropp Tempo deploys and operates the infrastructure supporting trading APIs, WebSockets, pricing, deposit and withdrawal, KYC, and notification services. Financial logic, user assets, wallets, and private keys remain outside our scope.
From Manual Releases to Ten-Minute Deployments
Dropp Tempo implemented GitLab CI pipelines backed by GitLab Container Registry for all three projects. The standard release path covers dependency installation, linting, build, release, and deployment, with a complete pipeline taking approximately 10 minutes.
In Kubernetes environments, Argo CD applies the desired state from Git. In Docker Swarm, deployments are triggered through Portainer webhooks. Rollbacks through Argo CD or Portainer also take around 10 minutes.
The development team initiates releases, while Dropp Tempo remains responsible for maintaining, troubleshooting, and improving the pipelines, registry, and deployment infrastructure.
Stable Access in Iran, Controlled Connectivity Abroad
Moving the infrastructure to Iran improved speed and stability for domestic users, but the exchanges still depended on international APIs. The target architecture therefore had to solve two requirements at once: reliable domestic service delivery and controlled access to external platforms.
Using pfSense or MikroTik with OpenVPN- and WireGuard-based tunnels, Dropp Tempo designed the required outbound paths and brought them under monitoring. One project also received a backup tunnel so a failure on the primary path would not fully interrupt external connectivity.
This layer is a defining requirement for exchange infrastructure in this market. Healthy servers alone are not enough; connectivity to external services must also be designed, monitored, and included in incident response.
Layered, Auditable Security
Administrative access across all three projects passes through VPN, while server access is handled through Teleport with MFA. VPN and Teleport access logs are retained for audit, and secrets are managed according to each environment through GitLab environment variables, Portainer, or HashiCorp Vault.
All servers are hardened through Dropp Tempo’s dedicated Ansible playbook. Built container images are scanned with Trivy, while WAF, rate limiting, and DDoS protection are active at the CDN layer. Backups are encrypted before being transferred to object storage.
In one of the three projects, the infrastructure received a high score in a security assessment by the relevant authority—an independent validation of the controls and operational maturity put in place.
Observability for More Than Five Million Daily Requests
Prometheus, Grafana, and Alertmanager monitor servers, clusters, databases, endpoints, and business metrics exposed by the services. ELK provides centralized logging and APM, Sentry captures application errors, and Uptime Kuma measures the external availability of critical endpoints.
Operational alerts are delivered to the client support channel in Mattermost and Dropp Tempo’s internal Rocket.Chat. The on-call team is activated by a critical alert or client call, and the Incident Commander coordinates diagnosis, failover, rollback, and recovery.
Together, the three environments register more than five million requests per day at the NGINX ingress layer. Each recorded more than 99.95% uptime over the 30-day period leading up to publication. In one project, the platform also served a high-traffic World Cup campaign without material disruption.
Backup and Disaster Recovery Built for Real Operations
Every database receives a full backup every 24 hours and an incremental backup every 30 minutes. Encrypted backups are stored in object storage outside the primary infrastructure and retained for 30 days. Database replication adds another layer of protection for critical services.
Restore tests were completed after implementation, with an RPO of 15 minutes and an RTO of one hour defined for critical data and services. A passive environment is prepared in a second data center operated by the same cloud provider, where critical data remains synchronized and services are already deployed.
During a disaster scenario, traffic is switched in a controlled process authorized by the Incident Commander. This gives the team a prepared recovery environment instead of forcing it to rebuild from scratch.
Technical and Business Outcomes
- Three migration and re-engineering projects, each delivered in approximately 20 days
- Cutovers completed in two hours or less with zero data loss
- Improved speed and stability for users accessing the platforms from Iran
- More than five million daily requests processed at the infrastructure ingress layer
- More than 99.95% uptime recorded across all three platforms
- Manual releases replaced by standardized pipelines taking approximately 10 minutes
- Rollbacks through Argo CD or Portainer available in around 10 minutes
- Staging environments, database replication, and object storage introduced
- Monitoring, centralized logging, APM, alerting, and external uptime monitoring implemented
- Security controls spanning VPN, MFA, hardening, image scanning, WAF, and DDoS protection
- Encrypted backups, restore testing, and a passive recovery environment established
- 24/7 support with an initial response SLA of under 30 minutes
The result was more than a successful migration. Each exchange now has clear operational ownership, a standardized release path, real-time visibility into platform health, and an accountable team available during incidents.
Retain: Infrastructure Ownership Does Not End at Go-Live
All three projects moved into the Retain phase after migration. Dropp Tempo’s six-person delivery team—comprising the CTO, a DevOps Team Lead, two Senior DevOps Engineers, and two Junior DevOps Engineers—continues to cover monitoring, incident response, pipeline maintenance, patch management, capacity planning, backups, restore testing, performance, and infrastructure for new services.
With 24/7 support and an initial response SLA of under 30 minutes, clients are not left alone after handover. The team that understands the architecture and migration path remains responsible for the platform’s daily health and continued evolution.
If you are migrating, redesigning, or stabilizing the infrastructure of a crypto exchange or financial platform, Dropp Tempo can begin with an Architecture & Reliability Review and stay accountable through Audit, Build, and Retain.
Book an Architecture & Reliability Review for your exchange infrastructure.