Skip to content
Ilia Shakeri

DevOps Engineer / Tehran, Iran

Built to ship.Built to stay up.

I’m Ilia Shakeri, a DevOps engineer working across Linux, containers, delivery pipelines, and monitoring. I build systems that deploy the same way every time, and that tell you when something is wrong.

Explore my projectsDownload résumé

Systems in orbit / v.01

portfolio ~ mainREADY

$ ./deploy.sh --status

✓ Built to ship. Built to stay up.

  • My operating layer
  • Linux & hardening
  • Delivery automation
  • Reliability & observability

01 / The human layer

whoami

Name
Ilia Shakeri
Role
DevOps Engineer
Based in
Tehran, Iran
Focus
Linux · Automation · Reliability

// Open to remote DevOps & platform roles.
// Persian (native) · English (professional working).

A systems thinker.
A builder at heart.

I work where code meets servers: hardening Linux hosts, packaging services into containers, wiring CI pipelines, and putting Prometheus, Grafana, and Loki in front of what runs in production. Most of my day-to-day tooling is Bash, Python, Ansible, Docker Compose, and n8n.

I work from evidence: write the runbook, test the restore, record what was actually verified. Outside the terminal, I follow open-source DevOps tooling and have played the piano for more than ten years.

Automate the repeatable.

Scripts, playbooks, and workflows over manual steps.

Make reliability visible.

Health checks, alerts, and evidence you can read.

02 / Selected builds

Complex problems.
Practical systems.

Three projects told as engineering work: the problem, the decisions, and what is actually running. Each links to its source.

Deployment blueprint / isolated Compose stack

Nginx edge

TLS · rate limits · write-stop

Signed manifest

Ed25519 · feature switches

Private backend network

Django web

Read-only container · health probes

Realtime

Server-sent events

PostgreSQL

4 scoped roles · no public port

One-shot jobs

bootstrap → migrate → finalize

Backups

sha256 · restore-verified offline

BackupMigrateGrantServe/ rollback ready

01 / Platform delivery

Dolphin CRM · 2026 · Sole engineer

One codebase. Locked-down, repeatable deployments.

A Persian-first CRM/ERP for sales, billing, inventory, telephony, and after-sales. I built the application and the delivery around it: each installation runs as an isolated Compose stack whose features are switched by a signed manifest, behind an Nginx edge, with least-privilege PostgreSQL roles.

  • Django
  • PostgreSQL
  • Docker Compose
  • Nginx
  • Ed25519

Delivery / Shipped as tagged releases (v2.40.42 in October 2026), with a deploy script that backs up, migrates, and can roll back.

Engineering notes

Problem

The same CRM has to run as separate installations, each with its own database, secrets, and feature set, and an administrator on the host must not be able to change which features are enabled.

My role

Sole author of the repository: application, PostgreSQL bootstrap, Compose topology, Nginx edge, deployment scripts, and the operations runbook.

Approach

  • Feature availability comes from a manifest signed with an Ed25519 key that never leaves the platform owner. Production refuses to start if the manifest is missing, tampered with, or signed by an unknown key.
  • Four PostgreSQL logins with separate rights: bootstrap, migration owner, runtime application, and a read-only backup role. One-shot jobs (db-bootstrap → migrate → db-finalize) apply exact grants before the web service may start.
  • Images are referenced by sha256 digest and built from the tagged commit, not the working tree.

Security & reliability

  • deploy.sh refuses to half-apply an upgrade: backup, migrations, grant refresh, and Nginx config reload run in a fixed order, with --rollback to the previous image.
  • An Nginx write-stop mode rejects POST/PUT/PATCH/DELETE during maintenance while reads keep working.
  • Backups are checksummed and restored into an isolated container with networking disabled, so a backup counts only once it has been restored.
  • Containers run read-only with all capabilities dropped and no-new-privileges.

Result

  • Versioned releases with a changelog for each one; the repository records a suite of about 3,500 automated tests.
  • A single deployment runbook covers first install, update, backup/restore, rollback, and incident response.
main / .github/workflows/ci.yml✓ 2.8.1 · all jobs passed
  1. BuildLocked npm
  2. TestPython · Go
  3. IntegrateTimescale · Redis
  4. E2EBrowser auth
  5. ScanTrivy · pip-audit
Run 38222923015 · 15/15 jobs (opens in a new tab)image gate → production

02 / Delivery & reliability

Nerkhbaan · 2026 · Sole engineer

Market prices you can trust, shipped through gated CI.

A live gold, currency, and crypto price platform: FastAPI, PostgreSQL with TimescaleDB, and Redis behind an Nginx ingress, with web, admin, and desktop clients. Prices carry their source time and expire rather than going quietly stale.

  • FastAPI
  • TimescaleDB
  • Redis
  • GitHub Actions
  • Trivy
  • Prometheus

Running / Release 2.8.1 deployed to nerkhbaan.ir with two API replicas, according to the project status record of 12 Oct 2026.

Engineering notes

Problem

Price sources fail, lag, and disagree. Showing an old quote as if it were current is worse than showing nothing, and every release has to keep existing users and history intact.

My role

Sole author: API, data model and migrations, frontends, Go feed sidecar, Compose production stack, CI, and monitoring.

Approach

  • CI on every push: locked Node builds, Python unit tests, a Go sidecar, Compose validation, browser end-to-end tests, repository security scans, and per-image Trivy scans.
  • Integration jobs run real TimescaleDB and Redis: migrations must be idempotent and checksummed, and lease handover between API replicas is tested.
  • Python dependencies install from hash-pinned lock files and are checked with pip-audit.

Security & reliability

  • Readiness checks the database, Redis, and pricing health, not just whether the process is up. API port 8000 is internal only.
  • Prometheus alert rules cover API down, unavailable or expired prices, stalled refresh, provider failure rate, dead letters, persistence backlog, and Redis memory.
  • External price workers sign the records they submit; the feed sidecar holds no database or admin credentials.
  • The admin panel has its own session cookies, CSRF protection, permission checks, re-authentication, and TOTP MFA.

Result

  • The 2.8.1 release passed all CI jobs before deployment; the final API image reported no HIGH or CRITICAL findings.
  • The project status record keeps dated evidence and states what was not proven, for example that zero downtime is not claimed.
n8n / chatops-bridgesretry · backoff + jitter

Alerts

  1. Prometheus

    Rules fire

  2. Alertmanager

    Webhook JSON

  3. n8n

    Auth · HTML format

  4. Matrix room

    Firing / resolved

Tickets

  1. Jira

    Issue webhook

  2. Mention parser

    Assignee · @user

  3. n8n

    User → DM room

  4. Matrix DM

    Direct notice

03 / Observability & ChatOps

Prometheus & Jira → Matrix bridges · 2025 · Author

Less noise. Alerts that reach the right person.

Two n8n workflows from my ChatOps work: one turns Alertmanager webhooks into readable HTML alerts in Matrix rooms, the other routes Jira assignments and @mentions to the right person’s Matrix direct messages.

  • n8n
  • Prometheus
  • Alertmanager
  • Matrix
  • Jira

Design / Tokens are checked before use and renewed on 401; delivery retries with exponential backoff and jitter on HTTP 429.

Engineering notes

Problem

Plain webhooks fail silently when a bot token expires or the chat server rate-limits, and email notifications get ignored. Alerts and ticket updates need to land where the team already works.

My role

Designed and published both workflows.

Approach

  • Alertmanager posts to an n8n webhook; labels and annotations become a colour-coded firing/resolved message with a link back to the Prometheus graph.
  • Jira webhooks are parsed for assignees and @mentions in comment HTML, mapped to Matrix users, and delivered to cached direct-message rooms that are created on first use.

Security & reliability

  • Access tokens are cached in n8n tables, validated with whoami before use, and renewed automatically on expiry.
  • Login and delivery retry with exponential backoff and jitter.

Result

  • Both workflows are published as importable n8n JSON with setup guides.

More from GitHub

// No illustrative metrics. Figures above come from each repository’s own records.

03 / Technical toolkit

The right tools.
For the right problem.

Organized by purpose, not proficiency bars. Each of these appears in my work history or in a public repository.

  • Infrastructure & data

    Linux VPS / LVM / NFS

    Terraform / Ansible

    PostgreSQL / Redis / TimescaleDB

    Provisioning · Configuration · Backup & restore

  • Containers & orchestration

    Docker / Compose / Swarm

    Kubernetes / Helm

    Images · Compose stacks · Charts

  • Delivery & automation

    GitHub Actions / GitLab CI

    n8n / Bash / Make

    Build · Scan · Release · Rollback

  • Monitoring & observability

    Prometheus / Alertmanager

    Grafana / Loki / ELK

    Metrics · Alerts · Logs

  • Operating systems & scripting

    Ubuntu / CentOS / Git

    Bash / Python / Go / SQL

    Scripting · Tooling · Troubleshooting

  • Security & collaboration

    Nginx / Traefik / OpenSSL

    Keycloak / Trivy / UFW / iptables

    Matrix / Jira

    Hardening · TLS · IAM · ChatOps

04 / Experience

A career in building better.

From hands-on Linux administration to owning delivery and monitoring for production services, and building complete products end to end.

// Dates and roles from my résumé;
// project details from GitHub.

  1. DevOps Engineer

    Jun 2025 — Present

    OTICAMP · Tehran, Iran

    Provisioning, hardening, and monitoring Linux infrastructure for internal and product services.

    • Provisioned and hardened Linux VPS environments; Ansible playbooks keep server setup consistent between development and production.
    • Deployed a Prometheus, Grafana, and Loki stack for system metrics and logs.
    • Built ChatOps automation in n8n that routes Prometheus alerts and Jira events into Matrix rooms and direct messages.
    • Deployed and run Keycloak for centralized sign-in across internal services.
    • Ansible
    • Observability
    • ChatOps
    • Keycloak

  2. Product & Platform Engineering

    2026 — Present

    Independent projects · Remote

    Designing, building, and deploying complete products: Dolphin CRM and the Nerkhbaan pricing platform.

    • Dolphin CRM: a Django/PostgreSQL CRM shipped as versioned, tagged releases with Compose-based deployment, scripted rollback, and restore-verified backups.
    • Nerkhbaan: a FastAPI, TimescaleDB, and Redis platform with CI covering integration, browser, and image-scan gates, and Prometheus alerting, running on a live host.
    • Docker Compose
    • PostgreSQL
    • CI/CD
    • Prometheus

  3. Freelance DevOps & Linux Administrator

    Dec 2024 — Jun 2025

    Self-employed · Remote

    Automation scripts and system administration for client servers.

    • Wrote Bash automation for routine maintenance, backups, and log rotation.
    • Audited client servers; configured firewall rules and TLS certificates.
    • Tuned Nginx and Apache configurations, including reverse proxying and load balancing.
    • Linux operations
    • Bash
    • Nginx

05 / How I work

Built in loops, not silos.

Small, reviewable changes, written-down operations, and feedback that reaches the next build.

  1. Understand

    Map the system, its constraints, and what failure would cost.

    Write the contract first: Dolphin’s business rules live in a backend spec, not in memory.

    Output / A clear baseline

  2. Codify

    Turn infrastructure, access, and policy into versioned, reviewable code.

    Compose files, Ansible playbooks, hash-pinned dependencies, and explicit database grants.

    Output / Repeatable systems

  3. Ship safely

    Test, scan, and release in small steps, with a rollback plan.

    Images built from tagged commits, scanned in CI, deployed after a backup, rolled back by script.

    Output / Confident delivery

  4. Observe & refine

    Measure service health, learn from incidents, and reduce toil.

    Readiness checks, Prometheus alerts routed to chat, and restore tests on real backups.

    Output / Continuous improvement

Reliability is never “done.” Every deploy, alert, and restore test feeds the next improvement.

Feedback → forward

06 / Education & training

Always in learning mode.

Education

B.Sc. Computer Science

In progress · since Oct 2026

Studying the computer science fundamentals behind the infrastructure work I do every day.

07 / The takeaway

The full picture.
In one document.

Experience, technical skills, education, and selected work in a two-page PDF, built from the same verified content as this site.

Download résuméPrintable version

PDF · 208 KB
Updated October 2026

08 / Next connection

Let’s build
what’s next.

Looking for a DevOps engineer who treats deployments, backups, and alerts as engineering work? I’d like to hear about the systems you’re running.

iliashkr@gmail.com

Open to remote DevOps & platform roles
Tehran, Iran · IRST · UTC+03:30