Omar Adan Hassan

DevOps, Platform & Systems Engineer

I build reliable, secure, automated infrastructure and the delivery platforms teams ship on.

Portrait of Omar Adan Hassan
  1. SystemsLinux, networks, the machines themselves
  2. AutomationScripts and configuration management replace runbooks
  3. DevOpsPipelines, containers, repeatable delivery
  4. Platform engineeringKubernetes, GitOps, paved roads for teams
Career progression: Systems, then Automation, then DevOps, then Platform engineering, then Infrastructure & digital platforms. Currently: Platform engineering. Next: Infrastructure & digital platforms.

What I do

I work on the layer between hardware and the applications people use: the Linux systems, delivery pipelines, Kubernetes platforms and access controls that let teams ship changes safely and keep them running.

My work started with operating servers, moved into automating that operation, and now centres on designing platforms other engineers build on. The common thread is replacing manual, person-dependent procedures with systems that are reviewed, repeatable and observable.

More about how I work

Selected work

Case studies: the problem, the decisions, the architecture and the outcome.

  • One deployment control plane for Docker Compose services

    At NIRA, replaced logging into each server to rebuild and restart services with a single Dokploy instance that deploys every Compose stack from GitHub to its server over SSH.

    Problem
    Backends, frontends and supporting services ran as Docker Compose stacks spread across several servers and projects. Every update meant logging into the right server, pulling changes, rebuilding images and restarting the stack by hand, with each service's configuration living on its own machine.
    Outcome
    Deployments moved from a manual, per-server routine to one control plane. Every system is deployed the same way from its GitHub repository, and each service's configuration is visible and editable in one place instead of being scattered across servers.
    • Delivery platform
    • Docker
    • Deployment automation
  • Standardizing application delivery with GitLab CI

    Shared pipeline templates that gave every service the same build, scan and deploy path, so delivery stopped depending on who wrote the pipeline.

    Problem
    Each repository carried its own hand-written pipeline. Builds, image tags, scanning and deployments behaved differently per project, and fixing one pipeline fixed only that one.
    Outcome
    Pipelines became predictable and reviewable in one place. New services start from a working pipeline, and security checks run everywhere by default rather than by request.
    • CI/CD
    • Delivery platform
    • Security scanning
  • A Kubernetes platform operated through GitOps

    An RKE2-based Kubernetes platform where cluster state lives in Git and Argo CD reconciles it, replacing hand-applied manifests with reviewed changes.

    Problem
    Workloads were deployed by running commands against servers or clusters directly. The real state of production was whatever had last been applied, and nobody could easily answer what changed, when, or why.
    Outcome
    Changes to the platform now go through merge requests with a reviewable diff and an audit trail. Rolling back means reverting a commit, and rebuilding a cluster is a documented, repeatable procedure rather than tribal knowledge.
    • Kubernetes
    • GitOps
    • Platform engineering
  • Centralized Linux identity and privileged access

    Moving server access from local accounts and shared keys to centrally managed identities, host-based access rules and controlled privilege escalation.

    Problem
    Access to Linux servers was managed per host with local users and SSH keys. Revoking someone's access meant finding every server they could reach, and there was no single view of who could do what.
    Outcome
    Onboarding and offboarding became a group change rather than a server-by-server task. Who can access which systems is now answerable from one place, and privileged actions leave a trail.
    • Identity & access
    • Linux
    • Security

All case studies (6)

What I build

  • CI/CD platforms

    Shared pipelines that build, test, scan and deploy every service the same way.

  • Kubernetes platforms

    On-premises clusters with hardened defaults, operated through GitOps.

  • Infrastructure automation

    Servers, clusters and access described as code and applied through review.

  • Identity and access

    One identity per person, access by role, and privileged actions that leave a trail.

  • Secure delivery

    Secrets kept out of repositories, scanning built in, production changes approved and audited.

  • Observability

    Metrics, logs and alerts with clear ownership, so problems surface before users report them.

Engineering approach

The principles behind the decisions in the case studies.

Automate the second time
A task done by hand once is learning. Done twice, it becomes a script; done by others, a tool.
Git is the source of truth
Infrastructure, cluster state and access rules live in version control, so every change has a diff, a reviewer and a way back.
Secure by default
The easy path should be the safe one. Security that depends on people remembering is not security.
Observable before it is critical
If you cannot see a system working, you will not see it failing. Monitoring ships with the service, not after the first incident.
Repeatable over clever
A boring procedure anyone on the team can run beats an elegant one only its author understands.
Clear ownership
Every system, alert and exception has a named owner. Shared responsibility without an owner is nobody’s responsibility.
Building
Internal developer platform patterns on top of Kubernetes and GitOps
Learning
Platform engineering practices for self-service infrastructure
Exploring
Data exchange and digital identity infrastructure architecture

Public work

Community work, profiles, certifications and writing.

Community

Profiles

  • LinkedIn

    Professional history, roles and recommendations.

  • GitHub

    Public repositories, infrastructure experiments and tooling.

Certifications

  • DCADocker Certified AssociateDocker / Mirantis
  • KCNAKubernetes and Cloud Native AssociateThe Linux Foundation / CNCF
  • LPIC-1LPIC-1 Linux AdministratorLinux Professional Institute

Writing

Contact

Working on infrastructure, platform or identity problems? I’m glad to talk.

Get in touch