When One Engineer Holds the Keys.

Every company has that one person. The one who knows which server needs to be restarted after a power outage. The one who remembers why a firewall rule exists. The one everyone calls when production behaves strangely — even on weekends. At Atlas Fleet Solutions, that person was their DevOps engineer.

It wasn't intentional. Nobody had planned for the company's infrastructure to revolve around a single individual. It simply happened over time. One script became two. One emergency fix became permanent. A server was configured during a late-night incident and never properly documented. Years passed, and what started as practical shortcuts quietly became operational dependency.

Meanwhile, the business kept growing. From its headquarters in Casablanca, Atlas Fleet Solutions managed deliveries across Morocco, Algeria and Tunisia. More than 200 vehicles relied on its internal tracking platform every day. Dispatchers monitored routes in real time, warehouse teams coordinated deliveries, and customers expected accurate tracking from pickup to arrival.

The application itself wasn't difficult to understand. Node.js powered the APIs. Redis handled real-time updates. MySQL stored operational data. Docker packaged everything consistently. The infrastructure, however, had become something very different. It lived on physical servers tucked away in the company's office. Deployment procedures existed partly in shell scripts, partly in internal chats, and mostly inside one engineer's memory. Nobody noticed — until that engineer handed in his resignation.

The company suddenly had fourteen days to answer questions nobody had asked before. How do we recover production if something breaks? Who has access to every server? Can anyone else deploy? What happens if an update fails? The issue wasn't replacing an employee. It was replacing knowledge that had never been written down.

"We didn't move to Qeda because our servers were old. We moved because our way of operating had become fragile."

Instead of recruiting another person to inherit the same fragile setup, the engineering team decided to rethink how the platform was operated. They migrated their workloads to Qeda, focusing on continuity rather than rebuilding everything from scratch. Their existing Docker containers moved without modification, avoiding months of redevelopment. Production databases were migrated into managed MySQL instances, removing the need to maintain database servers internally.

Deployment permissions became shared across the engineering team through centralized team accounts, while rollback capabilities meant production releases no longer felt irreversible. With Qeda's migration assistance, the transition happened without interrupting fleet operations. The entire platform was running on its new infrastructure in less than 72 hours.

Perhaps the biggest change wasn't technical. For the first time, deployment became a documented process instead of an unwritten ritual. Today, if one engineer is on vacation, another can deploy. If someone joins the company, onboarding takes hours instead of weeks. If production needs to roll back, nobody searches old Slack messages looking for forgotten commands. The infrastructure no longer belongs to a person — it belongs to the team.