Skip to content
Omar Adan Hassan
  • Projects
  • Work
  • Writing
  • About
  • Now
  • Contact

Projects and case studies

Each case study follows the same shape: the problem, the constraints, the decisions and why, the architecture, and what changed. Architectures are sanitized; no internal hostnames, addresses or confidential details are shown.

  • 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
  • Secrets management with Vault

    Taking credentials out of repositories, CI variables and config files, and issuing them from one audited place with short lifetimes where possible.

    Problem
    Credentials were spread across CI variables, configuration files and individual laptops. Rotating a secret was risky because nobody was sure everywhere it was used.
    Outcome
    Secrets have a single source and a clear owner. Access is scoped and auditable, and rotation no longer requires a search through repositories and servers.
    • Security
    • Secrets
    • Delivery platform
  • An observability baseline for platforms and services

    A shared metrics, logs and alerting stack with defaults every service inherits, so problems are found by alerts rather than by users.

    Problem
    Monitoring was inconsistent. Some services had dashboards, few had useful alerts, and logs lived on the machines that produced them.
    Outcome
    Platform and service health is visible in one place, logs are searchable without logging into servers, and alerts go to the people who own the system.
    • Observability
    • Reliability

Omar Adan Hassan

DevOps, Platform & Systems Engineer

  • Projects
  • Work
  • Writing
  • About
  • Now
  • Contact
  • LinkedIn
  • GitHub

© 2026 Omar Adan Hassan