One of fewer than 250 Docker Captains worldwide. 10 vendor community titles across Docker, IBM, CNCF, AWS, HashiCorp, Snyk, Cypress, Notion, GitKraken, and Platform Engineering, earned through contribution rather than credentials.

Every architecture recommendation backed by production experience. Earlier: operations and support roles at IBM, IPONWEB, Amazon and Thales (2016–2019). I design scalable systems and publish what I learn: reference architectures for container security, AI governance, and platform engineering used by practitioners worldwide.

Docker CEO on my contributions to the ecosystem

"Vladimir has written more than 100 pieces of content for Docker in the past year. He has also helped us find customer stories that we've been able to document and share throughout the rest of the community. And he's met with multiple product managers internally to share his product feedback."

— Scott Johnston, CEO, Docker (2019–2025)

"Vladimir is among a small number of Captains whose work has both shaped Docker's developer ecosystem and demonstrated technical communication at the highest level."

— Eva Bojorges, Senior Developer Relations Manager, Docker, Inc. (recommendation letter, 2026)

"The program ran above fifty ambassadors at its strongest … Across his tenure he sat consistently among the top three by sustained contribution …"

— Gérald Crescione, Head of AI Security Engineers Community, Snyk (recommendation letter, 2026)

Snyk Ambassador Award finalist (2023) · Named first-hand references, with linked proof

Kubernetes, tested every day on kind and every week on a real AWS account; every claim is a check that fails the build

• aws-eks-reference-platform: a multi-tenant platform for Amazon EKS, delivered as Argo CD ApplicationSets. Admission policies compiled into native ValidatingAdmissionPolicies keep refusing with Kyverno stopped, tenants are confined by their own Argo CD projects and enforced sync impersonation, and a daily drill restores a deleted tenant from backup. Thirteen decision records, each ending with how the choice would be explained to a customer, a threat model and a Well-Architected review. 56 checks on a fresh cluster every day, and 56 again after upgrading one from the previous release. The AWS side runs every week on a real account: the first passing run, on 15 October 2026, applied 101 resources, brought every Application up on EKS 1.37, passed 14 checks against AWS, tore everything down and cost about $0.20. The seven runs before it found what no mocked plan could, among them an EKS add-on build that leaves Argo CD unable to read the cluster.
• kubernetes-ai-agent-sandbox: what an AI agent that has been talked into something can reach. gVisor as the kernel boundary, an egress allowlist with a second wall at the destination, and one door to the tools: an MCP server that knows which agent is calling, grants each one named tools, holds the credentials no agent pod may carry, and logs every call. A demo agent is fooled on purpose in every run, and the official MCP SDK drives the server in CI. It found that on a node with swap, a gVisor pod's memory limit is not the limit.
• kubernetes-supply-chain-admission: the cluster runs an image only if one build signed it and attached provenance, an SBOM and a scan from the last day. It found that the most common scanner gate passes an image the scanner could not read, and that Kyverno's image policy can read the wrong attestation when a registry lists them out of order.
• kubernetes-postgres-recovery: PostgreSQL on CloudNativePG, restored every day three ways: to a second before a DROP TABLE, onto a standby after the primary is killed mid-write with no acknowledged write lost, and from the bucket alone after the cluster and its volumes are deleted. It found that a cluster can report Ready while it backs up nothing.

Reported upstream from these repositories: gVisor, Kyverno with a reproduction, a split of a Kyverno fix that has since merged, Kyverno's docs, Trivy and metrics-server on EKS.

Selected publications on vendor platforms

• Docker Official Blog: The Untrusted Autonomous Workload: How AI Coding Agents Reshape What Isolation Has to Do
• Docker Official Blog: How to Build, Run, and Package AI Models Locally with Docker Model Runner
• Docker Official Blog: Testcontainers Cloud vs Docker-in-Docker for Testing Scenarios
• Docker Official Blog: Master Docker and VS Code: Supercharge Your Dev Workflow
• Docker Official Blog: Mastering Docker and Jenkins: Build Robust CI/CD Pipelines
• Docker Official Blog: How to Dockerize a React App (with Kristiyan Velkov)
• Docker Official Blog: Dockerize WordPress: Simplify Your Site's Setup and Deployment
• Docker Official Blog: 8 Top Docker Tips & Tricks
• Docker Enterprise Case Study: Accelerating AI Infrastructure at Ataccama
• Docker Enterprise Case Study: 25% Cost Savings via Container-First Strategy
• Docker YouTube: Why 'latest' Broke Our Staging · Make your security team happy (#captainslog 02)
• Featured by Cypress: Cypress Ambassador Spotlight: Vladimir Mikhalev
• 3 articles for Cypress on DEV: Cypress in the Age of AI Agents · Docker + Cypress: Perfecting E2E Testing · Cypress Test Replay: The Ultimate Guide to Time-Travel Debugging
• Book: Technical Editor of Docker and Kubernetes Security (2025), a DevOps Dozen 2025 finalist for Best DevOps Book of the Year. Retail record: Goodreads
• Open Source: 70+ open-source deployment blueprints, maintained with AI coding agents under policy gates I prove with planted violations · 1.5M+ Docker Hub pulls (aws-kubectl)
• Third-party adoption: aws-kubectl is the default image of the ECR registry helper in OpenMetadata's Helm chart

Formalized supply-chain hardening program for public deployment-template repositories

Self-Host Repo Hardening Runbook is an 8-phase program that brings deployment-template repositories to a supply-chain-hardened baseline: commit-SHA-pinned GitHub Actions with per-job permissions, digest-pinned upstream images with a daily freshness check, OpenSSF Scorecard, CI linting, Trivy upstream scanning.

Reference implementations, three repository shapes with one hardening rigor:

92 repositories under this standard: 49 self-hosted applications behind Traefik, 14 game servers, 6 other stacks, 8 Terraform pipelines on AWS, 4 Kubernetes platforms, 11 operations tools and scripts. Every template is pinned by digest, boots in CI daily, upgrades from its previous release on the same volumes, and is released only after that passes. fleet-ops recounts them once a day and rewrites this line when a number changes; these last changed 2026-10-15 11:43 UTC.

How an AI agent is run on this fleet

An AI agent does most of the typing across these repositories, and nothing it writes ships on its word. It is fast, and it is wrong on a schedule, so a release is cut only after the release commit itself deploys, backs up and restores in CI, and every fleet rule is tested against a planted violation before it is trusted.

Today: 73 restore scripts across 48 repositories, every one of them run by CI. 1337 releases are tagged across the fleet. 45 of 47 templates restored an older release's backup into the current release on a machine that had never run the stack, the fastest in 23 s. OpenSSF Scorecard, run by OpenSSF and not by me, puts the median at 7.3 across 101 repositories. The OpenSSF Best Practices badge, a questionnaire I answered and OpenSSF publishes with every answer, is passing on 94 of 94 registered repositories. The 7 public repositories that hold no code to rate, this profile among them, are not registered. fleet-ops recounts these once a day and rewrites this line when a number changes; these last changed 2026-10-18 11:22 UTC.

What those checks caught on 23 September 2026, the day that line was first written:

• A team wiki whose backup logged Data backup OK for 12 days and 8 releases while it archived a storage volume nothing writes to. The uploaded files were in no backup. The fix now restores a file through S3 in CI on every push.
• On that day, all 72 restore scripts the fleet then carried, across 47 templates, had never been run by CI, the oldest since May 2021. The tests had restored with their own copy of the commands. One of the scripts, before and after: it refused to run on the stack it shipped with. All of them run the shipped script now, and a fleet rule fails any that stops.
• Five mistakes by the agent itself in one day, from an apostrophe that stopped a backup loop to a database client the image does not ship. None reached a release.

And on 24 September, the day after: two defects in the fleet's own watcher, found and fixed before its morning run. A test's fake failed the way the real function never does, so 116 green tests hid a crash; and three templates whose cron had changed the day before would have been reported sixty-two hours late. Both are in the ledger with the rule each produced. The same day every public repository gained a rule against rewriting main and, where it was missing, a security policy; OpenSSF Scorecard scores the result, and the evidence page repeats that score with every check below ten and what it means here.

On 24 September the clean-machine drill went from four templates to every template that ships a restore script, all 47, in one day: each one restores its previous release's backup into the current release on a runner that has never run the stack, weekly, and the time is on the evidence page beside the recovery point the template ships with. The line above counts them; a template whose drill fails is listed as failing and carries no time.

Green is a claim. A restore is evidence.

The evidence, with a restore measured on a clean machine · Every finding, with the rule it produced · The decisions, and what each one cost

Where the decisions come from

I build the platforms, run the company-wide systems on top of them, and am the sole IT and DevOps engineer for North America. I am the Kubernetes and cloud expert on customer calls, answer customer security questionnaires, and run a production platform on Amazon EKS with Terraform and GitHub Actions. Docker published one of my migrations as an enterprise customer story with 75% faster deployments and 40% fewer servers.

Earlier: operations and support roles at IBM, IPONWEB, Amazon and Thales (2016–2019).

Every architecture decision I publish is backed by production experience. Named first-hand references, each with linked proof: from Docker's then-CEO, the Docker Captains program lead, a published security author, and the lead of Snyk's ambassador program.

10 vendor community titles