AKAhad KhalidDevOps · Cloud · DevSecOps
Mode · Overview Showing 9 of 19 sheets — the recruiter read.
DevOps · Cloud · DevSecOps

Nothing unscanned or unsigned reaches production.

DevOps & System Support Engineer with 3.5+ years running high-availability production systems across AWS, Azure and on-premises estates — with a DevSecOps focus: secure SDLC gating, SBOM and supply-chain security, container image scanning and signing, CIS server hardening and SIEM-backed monitoring.

DevOps EngineeringCloudOpsDevSecOps Site ReliabilityCloud Infrastructure
Pipeline gates Results Contact
release-gate · pre-deploy verification
❯ gitleaks detect --redact no secrets found gate 1 · pass ❯ semgrep ci && sonar-scanner quality gate gate 2 · pass ❯ dependency-check --scan . no blocking CVEs gate 3 · pass ❯ syft . -o cyclonedx-json > sbom.json sbom versioned → dependency-track ❯ trivy image $IMG --exit-code 1 image clean gate 4 · pass ❯ cosign verify $IMG signature verified — promote to prod ❯
Illustrative — the gate sequence, not a live run
Sheet 02ProfileStage · Commit

An engineer who understands what happens after code leaves Git.

I started as a developer building business platforms, then moved to the side of the wall where those platforms have to actually run, stay up, survive an audit and come back after a failure. That path is the whole point of how I work now.

01 — Application

I've shipped the software

CRM, HRMS, e-commerce and SaaS platforms in Java, Node.js, React/Next.js and PHP. I know what a release contains before I'm asked to deploy it.

02 — Infrastructure

I run what it runs on

Linux estates, AWS and Azure, private Docker networks, Nginx, TLS, DNS, load balancing, databases and site-to-site tunnels — cloud and bare metal.

03 — Security

I gate the path between them

Blocking pipeline gates, not advisory checks. Secret scanning, SAST, SCA, SBOM, image scanning and signature verification before deploy — plus CIS hardening and SIEM on the other side.

04 — Operations

I'm there when it breaks

Disks filling, registries refusing pushes, sockets dropping behind Nginx, tunnels flapping, voice containers restarting — and the disaster recovery when something is genuinely gone.

I don't just deploy applications.
I understand the infrastructure behind them.

Code
Build
Gates
Registry
Network
Load Balancer
Server
Database
Observability
Incident Response
The path I work across, end to end
Competency

Infrastructure automation

Role-based Ansible playbooks and shell/Python tooling standardising server build-out across AWS, Azure and bare-metal estates — removing manual steps rather than documenting them.

Competency

High-concurrency tuning

Linux kernel, file-descriptor and ulimit tuning plus Nginx parameters for real-time VoIP workloads — reverse proxy, rate limiting, SSL termination and load balancing under peak call load.

Competency

Audit-ready operations

A maintained security evidence pack — gate results, SBOMs, scan and signature-verification reports, patch compliance and restore-test records — used to answer client and audit questionnaires.

Sheet 03Applications DeliveredStage · Build

I've built the applications, which is why I understand the infrastructure under them.

Before and alongside the infrastructure work I delivered production business software — CRM, HRMS, e-commerce, business websites and multi-tenant SaaS. Today I own the platforms that run them: 9+ concurrent production platforms, plus a contact-centre system where my work is deployment, security and server optimisation rather than application development.

CRM PlatformCustomer and lead management with role-based access, activity tracking and telephony wired into the call workflow.Node.js · MySQL · REST · SIP connector
HRMS PlatformEnterprise human-resource management — employee lifecycle, payroll and internal operations modules, with deployment and environment stability owned end to end.Java · MySQL · Docker · Nginx
E-Commerce StorefrontsB2C and global e-commerce platforms including furniture retail — catalogue, cart, checkout, order lifecycle and admin back-office.PHP (Laravel) · MySQL · Payment gateways
Contact-Centre & Cloud PBXNot my application — my work here is the infrastructure under it: deployment, security hardening and server optimisation so calls stay smooth under load.FreeSWITCH · Asterisk · Docker · Linux tuning
Angel-Investment PlatformInvestor and startup funding workflow with document handling, staged approvals and role-separated dashboards.Node.js · MongoDB
Export-Trade PortalInternational trade and export operations — listings, enquiries and documentation flow between parties.PHP (CodeIgniter) · MySQL
Hospitality SystemsGuest feedback and stay-experience SaaS for hotel operators, with reporting for property managers.Node.js · React · MySQL
Event & Voting SystemEvent registration with live voting — traffic arrives all at once, so capacity planning and traffic-peak readiness are the engineering problem.Node.js · MySQL · Caching
Healthcare WellnessWellness platform with user programmes, scheduling and content delivery, deployed and maintained in production.Java · MySQL
Ops & Admin DashboardsInternal Node.js dashboards over Asterisk — extension and trunk visibility, service state and administrative actions.Node.js · Asterisk AMI · React
Business WebsitesCorporate and marketing sites — build, DNS, TLS, Nginx hosting and ongoing maintenance rather than one-off handoffs.Next.js / PHP · Nginx · Let's Encrypt
Backend Services & APIsREST services, queue-backed background jobs and cross-platform integrations, running as containers behind a reverse proxy and an Nginx API gateway.Node.js · Java · Python · RabbitMQ

Writing the application taught me what to instrument. Operating it taught me what to fix.

JavaNode.jsTypeScript ReactNext.jsPython PHPLaravelCodeIgniter MySQLMongoDBRabbitMQ REST APIsShell

Client and product brand names are deliberately omitted; the platform category describes the work.

Sheet 04Delivery & ContainersStage · Build → Release

Pipeline-as-code, artefacts promoted — never rebuilt per environment.

Jenkins declarative pipelines and AWS Code services covering build, artefact publishing, approval gates and controlled release across Testing, UAT and Production.

Developer
GitHub
Jenkins pipeline-as-code
Set Environments
Application Build
Security Audit blocking
Docker Build & Push
Registry ECR · scan-on-push
Deploy Test → UAT → Prod
Stage sequence I run in Jenkins — the security audit is a gate, not a report
Containers

Docker, Compose, Swarm

Dockerfiles and multi-stage builds, Compose stacks, Swarm services across manager and worker nodes, overlay networks, persistent volumes, CPU and memory limits and restart policies. Images published to Amazon ECR and a private OVH registry, with the image lifecycle and versioning managed rather than improvised.

Multi-stage buildsPrivate Docker networksNon-root containersMinimal pinned base imagesOverlay networksResource limits
Automation

Ansible, Kubernetes, GitOps

Role-based Ansible playbooks for server configuration, patching and repeatable deployments, removing manual build-out. Kubernetes and EKS at a deploy-and-debug level — pods, deployments, services, requests and limits — with ArgoCD for GitOps-style reconciliation.

Stated honestly: I deploy to and troubleshoot Kubernetes. I have not architected a large-scale multi-tenant Kubernetes platform.

Ansible rolesJenkinsAWS CodePipelineCodeBuildCodeDeployEKSArgoCDGitOps
// Jenkinsfile — stage shape across services
pipeline {
  agent any
  environment { CREDS = credentials('runtime-bound') }
  stages {
    stage('Set Environments')     { /* per-env config    */ }
    stage('Application Build')   { /* deps · compile     */ }
    stage('Security Audit')      { /* BLOCKING — sheet 5 */ }
    stage('SBOM')                { /* syft → cyclonedx   */ }
    stage('Docker Build & Push') { /* build · sign · push*/ }
    stage('Deploy Application')  { /* verify · roll out  */ }
  }
}
Swarm Manager
Workerreplicas
Workerreplicas
Workerreplicas
Swarm — multi-host orchestration with overlay networking and persistent volumes, without a Kubernetes platform underneath
Sheet 05Secure SDLC · Pipeline GatesStage · Scan ◇ Sign ◇

Blocking gates, not advisory checks.

Most pipelines run security tools and email the findings. Mine stop the build. Select a gate to see what it checks and what specifically fails the pipeline.

Gate 1 · Commit

Secret scanning

Gitleaks runs on every commit, so a credential that reaches the repository is caught at the point it enters rather than during a later audit. Findings are redacted in pipeline output so the scan itself doesn't leak the secret it just found.

FAILS THE BUILD IF → any committed credential, token or key is detected
GitleaksPre-mergeRedacted output
Commit
G1 Secrets
G2 SAST
G3 SCA
G4 SBOM
G5 Image
G6 Sign
Registry
Verify → Deploy
Six checks between a commit and production — an unsigned or unscanned build cannot get through

Security belongs in the pipeline, not in a review at the end.

Sheet 06Software Supply ChainStage · Sign ◇

Every release knows exactly what it is made of.

An automated CycloneDX/SPDX SBOM per build, stored as a versioned artefact tied to the release number, scanned for known vulnerabilities and tracked in a central inventory portal — with a defined process for sharing SBOMs with clients under NDA.

Build
Syft / cdxgen generate
CycloneDX / SPDX sbom.json
Versioned artefact tied to release no.
Grype vulnerability scan
Dependency-Track inventory
Client / audit under NDA
SBOM lifecycle — generation through to the evidence a client security review actually asks for
Why it matters

A CVE lands on a Tuesday

With a per-release SBOM inventory, "are we affected?" is a query, not an archaeology project. Dependency-Track already knows which releases carry the component and which platforms are running them.

Toolchain

Generation & scanning

Syft and cdxgen for generation, trivy image --format cyclonedx for container inventories, Grype for vulnerability matching against the SBOM.

SyftcdxgenTrivyGrypeCycloneDXSPDX
Governance

Inventory & disclosure

OWASP Dependency-Track as the inventory and tracking portal, SBOM artefacts versioned against build and release numbers, and a defined NDA-bound process for sharing them with clients.

Dependency-TrackVersioned artefactsNDA disclosure
Sheet 07Cloud InfrastructureStage · Deploy

Four clouds and bare metal, one set of fundamentals.

Compute, networking, storage, identity and cost look different in each console and behave the same underneath. What I operate, what I work with, and what I know at an architecture level — separated honestly.

Amazon Web Services

Compute
EC2 · AMIs · instance sizing · EBS · ENIs · user-data bootstrapping · Auto Scaling Groups
Networking
VPC · public & private subnets · route tables · Internet Gateway · NAT Gateway · Security Groups · NACLs · CIDR planning · VPC peering · VPC endpoints · Route 53
Load balancing
ALB and NLB · target groups · listeners · health checks · host- and path-based routing · ALB in front of Auto Scaling Groups
Delivery services
CodePipeline · CodeBuild · CodeDeploy · Elastic Container Registry with scan-on-push
Storage & edge
S3 · presigned URLs · CloudFront · AWS WAF
Identity & security
IAM users, roles and least-privilege policies · AWS Secrets Manager · GuardDuty · Security Hub · CloudWatch metrics, logs and alarms
Data
RDS · EKS for containerised workloads
Internet
DNS Route 53
CloudFront edge cache
WAF / ModSecurity request filtering
ALB / NLB listeners · rules · target groups
App node EC2 / EKS
App node EC2 / EKS
MySQL / RDS replicated
MongoDB replica set
RabbitMQ
Encrypted off-server backups scheduled restore tests
Reference production architecture — a composite pattern, not a diagram of one specific environment
07.1Interactive · ALB routing
Client
Listener :443 HTTPS
Rule path /api/*
Target Group tg-api
Targets 2 healthy EC2

The listener terminates TLS on :443. Rules are evaluated in priority order and the first match wins — a path condition on /api/* forwards to tg-api, whose health check (GET /healthz, 200 expected) decides which registered instances are eligible. Only healthy targets receive traffic; the Auto Scaling Group registers and deregisters them as it scales.

Microsoft Azure

VMs, networking & AI services

Virtual Machines, Load Balancer, Virtual Networks, subnets and NSGs, public/private IPs, Azure Storage and Blob Storage, Key Vault. Subscription and resource management, monitoring, billing and cost analysis — plus Azure OpenAI deployments and token-usage analysis as production AI infrastructure.

Azure VMsVNet / NSGLoad BalancerBlob StorageKey VaultAzure OpenAI
DigitalOcean & OVHcloud

Lean VM infrastructure

Droplets with public and private networking and Spaces object storage; OVH virtual machines running production workloads behind a private container registry, including registry authentication and image-publishing troubleshooting.

DropletsSpacesOVH VMsPrivate registry
On-premises

Where there is no managed service

Bare-metal and on-prem estates where there is no cloud load balancer, no managed database and no console — so high availability, load distribution and backup have to be built rather than enabled. FortiGate firewalls handle point-to-point links and IPsec tunnels out to client networks and Azure.

Bare metalFortiGateIPsecPoint-to-point
Sheet 08Networking & EdgeStage · Deploy

Most "application bugs" in production are network problems.

Routing, name resolution, certificates, proxy headers and firewall rules account for a large share of what actually breaks.

Fundamentals

Addressing & transport

IPv4 addressing, CIDR and subnetting, network and broadcast addresses, TCP/IP, ports and sockets, routing tables, DNS resolution and firewall rule design across cloud security groups and host firewalls.

# VPC address plan — a worked example
VPC          10.20.0.0/16    65,536 addresses
public-a     10.20.1.0/24    .0 network · .255 broadcast
                             251 usable (AWS reserves 5)
private-a    10.20.10.0/24   no IGW route → NAT egress
private-db   10.20.20.0/24   reachable only from app SG
Diagnostics

The tools I reach for first

Before reading application logs I establish whether the packet arrived at all — resolution, reachability, listening socket, TLS handshake, then payload.

dignslookuppingtraceroutecurl -vss -tulpnnetstatopenssl s_clienttcpdump

Edge stack: Nginx reverse proxy with SSL/TLS termination, routing, caching, rate limiting and an API gateway layer; Let's Encrypt certificates; WebSocket and WSS upgrade handling; DNS and Route 53; StrongSwan IPsec and FortiGate site-to-site tunnels.

# Nginx — the WebSocket upgrade that quietly breaks WSS
location /ws/ {
    proxy_pass          http://127.0.0.1:8088;
    proxy_http_version  1.1;
    proxy_set_header    Upgrade    $http_upgrade;
    proxy_set_header    Connection "upgrade";
    proxy_set_header    Host       $host;
    proxy_read_timeout  3600s;   # long-lived sockets
}

# API gateway — rate limiting on auth and OTP endpoints
limit_req_zone $binary_remote_addr zone=auth:10m rate=5r/m;
location /api/auth/ { limit_req zone=auth burst=3 nodelay; }
Browser
DNS
TLS SAN must match
Nginx gateway · rate limit
101 Switching Upgrade header
Application
Every hop a WSS connection has to survive
StrongSwanFortiGate IPsecPoint-to-pointLet's EncryptSAN / SNIHTTP/2Rate limitingAPI gateway
Sheet 09Hardening & Security OperationsStage · Harden

The server is a control surface, not just a host.

Production servers hardened to CIS benchmarks and kept that way — with a SIEM watching for drift rather than an annual review discovering it.

Server hardening

CIS benchmarks, enforced

Dedicated non-root users, key-only SSH through a bastion/jump server, UFW default-deny mirrored at cloud security-group level, MFA on privileged access, ulimit and file-descriptor tuning, and patch SLAs rather than ad-hoc updates. Assessed with Lynis and OpenSCAP.

CIS benchmarksLynisOpenSCAPBastion SSHUFWMFAPatch SLAs
Security operations

SIEM, FIM & drift detection

Wazuh across the server estate for SIEM, file-integrity monitoring and CIS configuration assessment, with alerts correlated to MITRE ATT&CK and Falcon runtime protection alongside. Fail2Ban and Nginx rate limiting for brute-force, plus OpenVAS and scheduled OWASP ZAP baseline scans.

WazuhMITRE ATT&CKFalconFail2BanOpenVASModSecurity
Secrets

Nothing lives in the repo

HashiCorp Vault, AWS Secrets Manager and Azure Key Vault for credential storage, with runtime-bound Jenkins credentials so secrets are injected at execution rather than baked into images or pipeline definitions.

HashiCorp VaultAWS Secrets ManagerAzure Key VaultRuntime-bound creds
Server estate
Wazuh agent SIEM · FIM · CIS
Correlation MITRE ATT&CK
Alert drift · integrity · intrusion
Evidence pack
Detection path — and the audit evidence that falls out of it
Container security posture

The Docker estate, minimised

Minimal pinned base images, non-root containers, private Docker networks, databases kept off public interfaces entirely, and registry scan-on-push enabled in Amazon ECR. The attack surface is reduced at build time, not patched at runtime.

Pinned base imagesNon-rootPrivate networksNo public DB interfacesECR scan-on-push
Sheet 10ObservabilityStage · Observe

Know it broke before someone tells you.

Fleet-wide metrics, alerting, and custom checks for the things off-the-shelf exporters don't cover.

Servers
Node Exporter
Prometheus
Alertmanager
Grafana
Fleet-wide monitoring with metrics, logs and alarms — analysed to trace call failures, latency and resource exhaustion
Website health check
Custom script cron
Textfile collector
Prometheus
Grafana
Custom checks — where the textfile collector earns its place
# cron → textfile collector: turn any check into a metric
code=$(curl -s -o /dev/null -w '%{http_code}' "$URL")
up=$([ "$code" = "200" ] && echo 1 || echo 0)

cat > "$DIR/site_health.prom.$$" <<EOF
# HELP site_up 1 if the endpoint returned 200
# TYPE site_up gauge
site_up{site="$NAME"} $up
EOF
mv "$DIR/site_health.prom.$$" "$DIR/site_health.prom"  # atomic
What I monitor

Hosts, containers, services, calls

CPU, memory and disk across the fleet; container state and resource use; website and endpoint health; FreeSWITCH and Asterisk service health; log analysis to trace call failures, latency and resource exhaustion; and cron-driven automation for checks that must run on a schedule.

PrometheusNode ExporterGrafanaAlertmanagerCloudWatchTextfile collectorcron
Sheet 11Availability & RecoveryStage · Observe → Respond

A backup you have never restored is a hypothesis.

High availability, database replication, encrypted off-server backups and scheduled restore testing — recorded as audit evidence, and proven once in a real recovery.

High availability

Removing single points of failure

Load balancing built on on-premises infrastructure, distributing traffic across multiple backend nodes where no managed cloud load balancer was available — plus ALB/NLB and Auto Scaling in the cloud estate.

Replication

MySQL and MongoDB

Database replication across MySQL and MongoDB with encrypted, off-server backups and scheduled restore testing, so recovery capability is verified rather than assumed.

Disaster recovery

Executed, not just planned

A real disaster-recovery operation — production services and data restored from replicas and backups, 90% faster than a manual rebuild, with no permanent data loss.

Failure
Assess scope what is actually gone
Promote replica
Restore from encrypted backup
Reconcile & verify
Service restored
Restore-test record audit evidence
Recovery path — the reason scheduled restore testing exists
Storage engineering

I/O layout under load

Server file-system and disk I/O layout optimised to separate call-recording, logging and application workloads so they stop contending — clearing slowdowns that previously appeared only at peak call volume.

Abuse resistance

Rate limiting & API gateway

An Nginx-based API gateway with stricter limits on authentication and OTP endpoints, burst handling and per-IP controls — protecting upstream services from brute-force and API abuse.

Sheet 12Production IncidentsStage · Respond

Real incidents, traced to root cause.

A tool list says what I've touched. These say how I think — problem, investigation, root cause, solution, outcome.

01Production disk usage climbing until it threatened the serviceLinux · Storage · Log management+

Problem

Storage on a production server was growing steadily with no matching growth in application data. Left alone, the filesystem would fill and take services down with it.

Investigation

Walked the filesystem from the top rather than guessing — df -h to find the pressured mount, then du depth by depth through /var. Examined application logs, Docker container and JSON log files, Nginx access and error logs, Asterisk call recordings and container data directories, and identified which services were writing most.

Root cause

Unbounded log and recording growth — data written correctly but never rotated, capped or expired.

Solution

Separated what had to be retained from what did not, cleaned the safe-to-remove data, and put automated log management and cleanup in place so growth is bounded rather than merely monitored. Added disk monitoring so the trend surfaces before it is urgent. This fed into the wider file-system and I/O layout work that separated recording, logging and application workloads.

Outcome

Disk growth bounded and observable instead of a recurring emergency, and peak-volume slowdowns cleared.
Engineering lessonDisk monitoring tells you the disk is full. Investigation tells you why — and only the second one stops it happening again.
02Container registry rejecting image push and pullDocker · Private registry · CI/CD+

Problem

Push and pull against a private registry started failing, breaking the deployment path — builds succeeded, but nothing could be published or retrieved.

Investigation

  • Registry authentication and credential state
  • Image naming and tags against the registry namespace
  • Docker daemon behaviour and configuration
  • Network reachability to the registry endpoint
  • Layer upload behaviour — where transfers stalled
  • Registry availability and storage state

Root cause

A break in the authentication and publishing path between build host and registry, not a fault in the image itself.

Solution

Re-established authenticated access, corrected tagging and publishing so images are named for the registry they target, and verified the full round trip — build, tag, sign, push, pull on a clean host — before declaring it fixed.

Outcome

Deployment path restored, with the failure mode understood well enough to recognise it instantly next time.
Engineering lessonA registry failure looks like a Docker problem and is almost always an auth, naming or network problem.
03MongoDB reachable from Compass, refusing the applicationDatabases · Docker networking · Auth+

Problem

MongoDB accepted connections from Compass but failed the application — the same database behaving differently depending on who was asking.

Investigation

  • Authentication mode and auth database
  • Users, roles and per-database grants
  • Connection string construction including authSource
  • Docker network topology — service name vs host vs published port
  • Process state and persistent volume mounts

Root cause

The two clients were not taking the same path or presenting the same identity — a mismatch between how the application resolved and authenticated inside the container network and how Compass reached it from outside.

Solution

Aligned user, role and auth source with the connection string the application actually used, and made the container-network path explicit rather than incidental.

Outcome

Consistent, predictable connectivity from both the application and administrative tooling.
Engineering lesson"It works in Compass" isn't a passing test — it's evidence that two clients are taking two different paths.
04WebSocket connections failing behind Nginx over TLSNginx · TLS · WSS · DNS+

Problem

WebSocket connections would not establish through the reverse proxy over HTTPS — the page loaded, the socket did not.

Investigation

  • DNS resolution for the hostname the client actually used
  • Certificate validity and SAN coverage for that exact hostname
  • TLS handshake with openssl s_client
  • Nginx location matching and proxy configuration
  • Upgrade and Connection headers on the proxied request
  • Upstream reachability and read timeouts

Root cause

The upgrade handshake was not surviving the proxy hop — proxy configuration combined with a certificate/hostname mismatch, not application code. Related work in the same area: SAN mismatches, Let's Encrypt validation failures and stale DNS records.

Solution

Preserved HTTP/1.1 and the upgrade headers to the upstream, extended read timeouts for long-lived sockets, and fixed the certificate so the SAN matched the hostname clients connect to.

Outcome

Stable WSS connectivity and a repeatable checklist for the next socket that "just doesn't connect".
Engineering lessonA WebSocket failure is rarely one fault. It's DNS, TLS, proxy headers and timeouts — checked in that order.
05Built incident capture around containerised FreeSWITCHVoice infrastructure · Automation · Observability+

Problem

When a FreeSWITCH container restarted, stopped or died, the logs explaining why were rotating away or disappearing with the container before anyone looked.

Investigation

Established what state existed at the moment of failure versus what survived it, and where the useful signal lived — container lifecycle events, FreeSWITCH's own logs, and host-level service state.

Root cause

Not a fault to fix but a gap to close: nothing captured evidence at the moment of the event.

Solution

Built a monitor watching the container lifecycle that, on restart, stop or death, captures the recent log window and writes it to a durable incident log outside the container.

Outcome

Voice incidents are investigated from evidence captured at the time rather than reconstructed afterwards.
Engineering lessonYou can't investigate what wasn't recorded. Capture at the moment of failure, not when someone gets around to looking.
06IPsec tunnels dropping on a periodic cycleVPN · StrongSwan · FortiGate+

Problem

Site-to-site IPsec tunnels were disconnecting periodically. Restarting the service restored them — which made it tempting to stop there.

Investigation

  • Tunnel and security-association state over time
  • IPsec configuration on both peers, including proposal agreement
  • IKE and child SA lifetime and rekey behaviour
  • Whether disconnects correlated with a fixed interval
  • Service state and what recovery actually restored

Root cause

Disconnections tracked the negotiated lifetime and rekey cycle rather than occurring randomly — a configuration and renegotiation issue, not a transient network fault.

Solution

Aligned configuration and lifetime settings across both peers so rekeying completes cleanly, and monitored tunnel state so a drop is detected rather than reported by users.

Outcome

Predictable tunnel behaviour, and an explanation instead of a workaround.
Engineering lessonA restart that fixes it is a clue, not a resolution. If a failure has a period, the period is the evidence.
07Client website had to clear a major platform's security auditApplication security · Remediation · Release approval+

Problem

A client site was blocked from release until it passed a major platform's security audit — a pass/fail gate with someone else holding the checklist.

Investigation

Worked the audit findings as a list rather than a narrative: reproduced each reported issue, established whether it sat in application code, server configuration or the network edge, and traced which layer actually owned the fix.

Root cause

Findings spread across all three layers — no single fix would have cleared it.

Solution

Remediated every reported finding across application, server hardening and edge configuration, then re-verified against the audit criteria before resubmission.

Outcome

The site was approved for release.
Engineering lessonAn external audit is the cheapest version of the test production runs on you anyway.
Sheet 13Voice & AI InfrastructureSpecialisation

Real-time infrastructure, where latency is not negotiable.

Voice shapes how I think about everything else: media has to arrive in tens of milliseconds, signalling and media take different paths, and there is no retry. This is infrastructure engineering for contact-centre and voice systems — not telecom application development.

Voice infrastructure

Asterisk · FreeSWITCH · SIP

Deploying and operating voice servers including containerised FreeSWITCH and Asterisk/FreePBX estates. SIP trunking and inter-server routing, dialer and contact-centre workloads, recording storage, audio streaming, and the networking voice depends on — NAT behaviour, RTP port ranges, ACLs and VPN routing between sites. Includes deploying and commissioning an outbound dialer on client premises, from on-site install to live production.

On the contact-centre platform the scope is explicitly infrastructure, not the product: release deployment, server security hardening, and the kernel, file-descriptor, I/O and Nginx optimisation that keeps the call experience smooth at peak volume.

AsteriskFreePBXchan_sipFreeSWITCHmod_callcenterSIP / RTPMulti-tenant PBXOutbound dialer
CallerSIP signallingAsterisk / FreeSWITCH
INVITE — SDP offer
100 Trying
180 Ringing
200 OK — SDP answer
ACK
RTP media — G.711 / Opus · UDP 16384–32768
BYE
200 OK
Signalling on :5060/:5061, media on a separate UDP range — the reason voice breaks differently to HTTP
Caller
SIP trunk
FreeSWITCH / Asterisk
Audio stream
STT Whisper
LLM Azure OpenAI · Ollama
TTS
FreeSWITCH / Asterisk
Caller
Real-time voice-AI loop — every hop is latency the caller can hear
What I do here

Deployment, integration, operation

Provisioning and wiring the services this loop depends on — Azure OpenAI deployments, speech-to-text and text-to-speech, self-hosted models via Ollama, TTS voices for IVR prompts, and the Node.js services stitching telephony to those APIs. Then keeping the path observable and within budget.

Azure OpenAIWhisperOllamaTTSNode.jsAudio streaming
What I am not

Not an AI researcher

I don't train models or do ML research. I deploy them, integrate them into real-time telephony, size the infrastructure they run on, track token consumption against cost, and debug the path when a call goes silent.

That distinction matters — the value I add is that the AI actually works on a live call.

Sheet 14ResultsOutcomes

What changed because the work was done.

Two figures I can stand behind, and the rest stated as outcomes rather than invented percentages.

75%Deployment & build-out timeCut across 9+ production platforms by consolidating onto a single Docker + Ansible workflow.
90%Faster disaster recoveryA real recovery operation restoring production services and data from replicas and backups, versus a manual rebuild — with no permanent data loss.
9+Production platforms ownedConcurrent business-critical platforms plus a contact-centre system, across AWS, Azure and on-premises servers.
→Established a secure SDLC with blocking pipeline gates — secret scanning, SAST, dependency scanning, image scanning and signature verification — so that no unscanned or unsigned build reaches production.
→Secured the Docker estate: minimal pinned base images, non-root containers, private Docker networks, databases kept off public interfaces, and registry scan-on-push in Amazon ECR.
→Introduced automated SBOM generation and tracking (Syft → CycloneDX, scanned with Grype, catalogued in OWASP Dependency-Track), giving a per-release component inventory that satisfied client security due-diligence and audit requests.
→Rolled out Wazuh SIEM, file-integrity monitoring and CIS configuration assessment across the server estate, giving central visibility of privilege escalation, file changes and configuration drift.
→Hardened production servers to CIS benchmarks and cut external exposure to the approved minimum — bastion-only SSH, UFW default-deny mirrored in cloud security groups, MFA on privileged access.
→Built load balancing on on-premises infrastructure, distributing traffic across multiple backend nodes and removing single points of failure where no managed cloud load balancer was available.
→Optimised server file-system and disk I/O layout to separate call recording, logging and application workloads — clearing slowdowns that previously appeared only at peak call volume.
→Implemented database replication across MySQL and MongoDB with encrypted off-server backups and scheduled restore testing recorded as audit evidence.
→Implemented rate limiting and an Nginx-based API gateway — stricter limits on authentication and OTP endpoints, burst handling and per-IP controls protecting upstream services from brute-force and API abuse.
→Deployed and commissioned an outbound dialer at client premises for a state power-utility client and a collections operation, taking it from on-site installation through to live production use.
→Hardened a client website to clear a major platform's security audit, remediating every reported finding and getting the site approved for release.
→Delivered site-to-site connectivity on FortiGate firewalls — point-to-point links and IPsec tunnels between on-premises sites, client networks and Azure, integrating into clients' existing infrastructure without disrupting live services.

Figures shown are the two I can substantiate. Nothing else here is expressed as a percentage, and no uptime, traffic, user or cost-saving number is claimed.

Sheet 15Key PlatformsOwnership

Systems I keep running.

Infrastructure ownership rather than one-off project delivery.

AI Speech-Analytics Platform · cloud-hosted, client security-reviewed

Convoze

Own the infrastructure and the DevSecOps toolchain for a speech-analytics platform — secure-SDLC gates, container image scanning and signing, the SBOM inventory and the evidence pack presented in client security due-diligence reviews.

AzureAzure OpenAIReact · Node.js · PythonDockerMongoDBSBOM
AI Voice Infrastructure

Xeny

Infrastructure architecture connecting voice systems to AI services for real-time interaction — telephony into audio streaming into STT, LLM and TTS and back to the caller, inside a conversational latency budget.

TelephonyFreeSWITCHSTTLLMTTSCloud
Contact Centre · Infrastructure & Operations

Justtawk

I don't build the product — I run what it runs on. Deployments and release rollout, server security hardening, and the optimisation that keeps calls smooth under load: SIP routing, recording storage, monitoring and the networking that holds it together.

DeploymentsSecurity hardeningServer optimisationAsteriskFreeSWITCHMonitoring
Multi-tenant SaaS · Cloud PBX · Administration

Ringingo

Administer and operate a multi-tenant cloud PBX on FreeSWITCH and Asterisk, including a second regional deployment — VPN routing, inter-server SIP trunking and ACL work between sites, plus the tuning that keeps concurrent call volume stable.

Multi-tenant opsIPsec VPNSIP trunkingACLsKernel & Nginx tuning
Enterprise HRMS

HRMS Platform

Deployments, infrastructure and environment stability for the employee lifecycle, payroll and internal operations modules of an enterprise human-resource management system.

JavaMySQLDockerNginxBackups
SaaS & E-Commerce Portfolio · hospitality, retail, healthcare, trade, fintech

Platform Portfolio

Cloud and server operations for a portfolio spanning hospitality feedback and stay-experience SaaS, B2C and global e-commerce, an angel-investment funding platform, an international export-trade portal, an event and voting system and a healthcare wellness platform — deployment pipelines, capacity planning and traffic-peak readiness.

AWS · Azure · on-premDockerAnsibleNginxMySQL · MongoDB
Sheet 16Capability IndexDepth, not percentages

Sorted by depth, not by a progress bar.

A percentage next to a technology name means nothing. What matters is whether I run it in production, work with it, or understand it at an architecture level.

Production

Operated daily

Technologies I run, break, fix and maintain in live environments.

LinuxDockerComposeSwarmJenkinsAnsibleGitNginxNetworkingMySQLMongoDBAsteriskFreeSWITCHPrometheusGrafanaWazuhTrivyCosignSyftShell

Working knowledge

Used, not owned end-to-end

Technologies I deploy to and debug without claiming platform-level ownership.

AWSAzureKubernetesEKSArgoCDGitHub ActionsCodePipelineCloudFrontWAFRDSRedisDigitalOceanOVHSemgrepSonarQubeOpenVASOWASP ZAPVaultPythonFortiGate

Architecture

Design-level

Patterns I can reason about and design against, stated as knowledge rather than operating history.

Advanced AWS networkingVPC peeringVPC endpointsTransit-style topologiesCloud-native architectureGitOpsDistributed systemsWireGuard
16.1Technology by layer

Cloud

  • AWS — EC2, ASG, ALB/NLB
  • VPC, Route 53, S3, EBS
  • RDS, IAM, ECR, CloudWatch
  • Azure — VMs, LB, Storage
  • DigitalOcean · OVHcloud
  • On-premises / bare metal

DevOps & Automation

  • Jenkins (pipeline-as-code)
  • AWS Code services
  • GitHub Actions
  • Ansible (role-based)
  • Docker · Compose · Swarm
  • Kubernetes · EKS · ArgoCD
  • Shell · Python · Git

DevSecOps

  • Gitleaks (secret scanning)
  • Semgrep · SonarQube (SAST)
  • OWASP Dependency-Check
  • Trivy (image + filesystem)
  • Cosign / Sigstore
  • OWASP ZAP (DAST)

SBOM & Supply Chain

  • Syft · cdxgen
  • CycloneDX · SPDX
  • Grype
  • OWASP Dependency-Track
  • Versioned SBOM artefacts

Hardening & SecOps

  • CIS benchmarks
  • Lynis · OpenSCAP
  • Wazuh (SIEM · FIM)
  • Falcon runtime protection
  • Fail2Ban · UFW
  • ModSecurity · AWS WAF
  • OpenVAS
  • GuardDuty · Security Hub

Secrets Management

  • HashiCorp Vault
  • AWS Secrets Manager
  • Azure Key Vault
  • Runtime-bound Jenkins creds

Infrastructure & Edge

  • Linux administration
  • Nginx (proxy, TLS, caching)
  • Rate limiting · API gateway
  • DNS · Route 53
  • FortiGate firewalls
  • IPsec · point-to-point
  • VPC / VNet · security groups

Databases & Messaging

  • MySQL
  • MongoDB (replication)
  • Encrypted backups
  • Scheduled restore testing
  • RabbitMQ
  • Amazon RDS · Redis

Observability

  • Prometheus
  • Node Exporter
  • Grafana
  • Alertmanager
  • Amazon CloudWatch
  • Textfile collector

Voice

  • Asterisk · FreePBX
  • FreeSWITCH
  • SIP · RTP · VoIP
  • Outbound dialers
  • Recording storage

AI Infrastructure

  • Azure OpenAI
  • Whisper
  • Ollama
  • TTS
  • Audio streaming

Application Stack

  • Java
  • Node.js · TypeScript
  • React · Next.js
  • Python
  • PHP (Laravel, CodeIgniter)
  • REST APIs
Sheet 17Engineering Philosophy

Production is the real test.

01

Build

Create infrastructure applications can reliably run on.

02

Gate

Nothing unscanned or unsigned gets past the pipeline.

03

Deploy

Automate the path from source code to production.

04

Harden

Reduce the attack surface at build time, not at runtime.

05

Observe

Know when something breaks before a user reports it.

06

Recover

Test the restore. A backup you've never restored is a hypothesis.

07

Troubleshoot

Find the root cause instead of applying a temporary fix.

08

Automate

If the same operational task happens twice, it shouldn't happen a third time by hand.

Build it. Gate it. Deploy it. Observe it. Break it. Fix it. Automate it.

Sheet 18Experience & Education3.5+ years

Developer first, then the infrastructure under it.

3.5+ years of hands-on experience operating cloud and on-premises infrastructure for business-critical, high-availability production systems.

2024 — PresentCurrent

DevOps Engineer

Triotech Bizserve Private Limited · Bhopal, India
  • Own DevOps and DevSecOps operations across AWS, Azure and on-premises servers for a portfolio of 9+ concurrent production platforms plus a live contact-centre system.
  • Provision and maintain AWS compute and networking — EC2, Auto Scaling groups, ALB/NLB, VPC, Route 53, S3, EBS, RDS and least-privilege IAM policies.
  • Build and deploy Dockerised application stacks on private Docker networks, managing image lifecycle and versioning through Amazon ECR.
  • Automate server configuration, patching and repeatable deployments using role-based Ansible playbooks, removing manual build-out steps.
  • Design and maintain CI/CD pipelines with Jenkins and AWS Code services covering build, artefact publishing, approval gates and controlled release.
  • Govern promotion across Testing, UAT and Production, coordinating release windows with development and QA.
  • Engineer blocking security gates into the pipeline — Gitleaks on every commit, Semgrep and SonarQube SAST with enforced Quality Gates, OWASP Dependency-Check, and Trivy image scanning with Cosign signature verification before deploy.
  • Generate a CycloneDX/SPDX SBOM on every build using Syft, stored as a versioned artefact tied to the release number, scanned with Grype and tracked in OWASP Dependency-Track — with a defined process for sharing SBOMs with clients under NDA.
  • Harden production servers to CIS benchmarks — dedicated non-root users, key-only SSH through a bastion host, UFW default-deny mirrored at cloud security-group level, MFA on privileged access.
  • Operate Wazuh across the estate for SIEM, file-integrity monitoring and CIS configuration assessment, with alerts correlated to MITRE ATT&CK alongside Falcon runtime protection.
  • Run Fail2Ban and Nginx rate limiting with OpenVAS plus scheduled OWASP ZAP baseline scans against staging.
  • Manage MongoDB and MySQL backup, retention, encryption and replication, with scheduled restore tests recorded as audit evidence.
  • Stand up fleet-wide monitoring with Prometheus Node Exporter, Grafana and Alertmanager alongside CloudWatch, analysing logs to trace call failures, latency and resource exhaustion.
  • Tune Linux kernel, file-descriptor/ulimit and Nginx parameters for high-concurrency real-time VoIP traffic, improving stability under peak call load.
  • Maintain the security evidence pack — pipeline gate results, SBOMs, scan and signature-verification reports, patch compliance and restore-test records — used to answer client and audit questionnaires.
2023 — 2024

Backend Developer

Alina Software LLP
  • Built and maintained backend services and REST APIs supporting production web applications.
  • Handled application deployment, environment configuration and post-release stability on Linux servers.
  • Worked across MySQL and MongoDB data layers — schema changes, query tuning, backups and replication setup.
2022 — 2023

PHP Developer

Triosoft Technologies
  • Developed and maintained web applications using PHP (Laravel, CodeIgniter) with MySQL backends.
  • Deployed builds to staging and production, configured Nginx/Apache virtual hosts, SSL and routing, and resolved live defects.
2021 — 2022

Apprentice

ECIL · Hyderabad, India
  • Completed a structured apprenticeship covering systems administration, networking fundamentals, server setup and application support.
Education

B.E. Computer Science & Engineering

Sagar Institute of Research, Technology & Science (SIRTS), Bhopal · 2016 – 2020 · 7.1 CGPA

How I work

Soft skills

Ownership in production-critical environments · cross-functional collaboration with development and QA · analytical troubleshooting under pressure · clear incident communication · documentation and audit discipline.

Based in · Languages

Bhopal, India

English · Hindi. Working across Indian and international regions, including a Middle East deployment and client-network integrations abroad.

Sheet 19ContactEnd of drawing set

Let's build infrastructure that works in production.

Open to DevOps Engineering, CloudOps, DevSecOps, Site Reliability Engineering and Cloud Infrastructure Engineering roles and conversations.

Emailinfo@devhub.work Altahadkhalid117@gmail.com Phone+91 79748 57585 LinkedIn/in/ahad-khalid-engineer Webdevhub.work
GitHub[ADD GITHUB URL]
Resume[ADD RESUME LINK]
LocationBhopal, Madhya Pradesh, India