I test what ships and publish what I find, failures included: 100+ public repositories, every restore script run by CI, every finding on the ledger with its rule. 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.

I design cloud and container platforms on Kubernetes, Terraform and AWS, secure their software supply chain, and explain the trade-offs to engineers, customers and leadership. The repositories below are reference architectures, and each says so. Earlier: operations and support roles at IBM, IPONWEB, Amazon and Thales (2016–2019).

Docker's then-CEO on video, and three program leads on LinkedIn

"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 belongs to a small group of Captains whose work has shaped Docker's developer ecosystem while setting the standard for technical communication in our community."

Eva Bojorges, Senior Developer Relations Manager, Docker, Inc. (recommendation on LinkedIn)

"Vladimir consistently ranked among the top three for sustained contribution in a program that had over 50 ambassadors across all continents at its peak at the time … He is one of the strongest security practitioners I have worked with anywhere."

Gérald Crescione, Head of AI Security Engineers Community, Snyk (recommendation on LinkedIn)

"He brought us well-developed drafts he had written himself, with customer results already gathered and a clear understanding of both the technical work and its business impact."

Dan Stelzer, partner marketing and the customer case study program, Docker (recommendation on LinkedIn)

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

Kubernetes, tested every day on kind, and weekly on a real AWS account from 21 October 2026; every claim is a check that fails the build

• kubernetes-air-gapped-ai-agent: an AI agent in a Kubernetes cluster with no route to the internet. Everything it runs crosses in as one signed file; the model is a reproducible image signed with the operator's key and carrying a signed AI-BOM, and admission checks both offline before the model server may mount it. Its tools go through the sandbox's MCP server, which holds the email tool's recipient to the company's domain, and its models sit behind one gateway that routes each request to the model it names and limits each client. Every day six open-weights models from four makers go through the same fifteen tasks with instructions planted in what they read: in the run v1.1.0 was cut from they acted on between none and half of them, and nothing left the company for any of the six, at $0.0001 to $0.0003 of model-server time a task; the table is rewritten after every run. Part of the models' restraint turned out to be the model server's: with the tool schema's pattern hidden from them, all six tried to send data outside, 92 times, and the tool server refused every attempt. A review of its own checks found a way out by DNS through the kind node that every release before v1.5.0 had; it is closed, and tried on every run.
• 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. v1.2.0 closed a way out its threat model had accepted, lookups through the cluster's DNS, and found that kind's network plugin lets a new pod's first packets through before its network policy applies.
• 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, fixed by the maintainers in #18049, Kyverno and image volumes with a tested workaround, a split of a Kyverno fix that has since merged, Trivy and metrics-server on EKS. Still open: a change to Kyverno's docs.

A move from one vendor to another, run in CI on every change, with each step shown the failure it prevents

• docker-hardened-images-migration: a production Compose stack, Keycloak behind Traefik on PostgreSQL, moved to Docker Hardened Images. Swapping the images alone broke five things, and in a stack without a read-only root one of them loses data with no error: the hardened PostgreSQL keeps its cluster in a versioned directory, so a compose file still mounted at the official image's path writes inside the container. Each change in the override is taken out in CI to show the failure it fixes, an install moved from the official images keeps its data, and the CVE counts are given by both Trivy and Docker Scout, which disagree. As written, the direct-copy route in Docker's own guide ends on an empty cluster the same way; the fix is open as docker-hardened-images/catalog#685.
• snyk-to-gitlab-security-migration: application security moved from Snyk to GitLab's scanners. Both run on one image in every CI run, every Snyk finding is mapped to what GitLab reports for it, ignores carry their reasons and expiry dates, and a gate fails when the move would lose a critical or high finding. It found that GitLab's vulnerability allowlist has no expiry, so a temporary acceptance carried as it is becomes a permanent one.

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:

101 repositories under this standard: 51 self-hosted applications behind Traefik, 17 game servers, 8 other stacks, 8 Terraform pipelines on AWS, 6 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-29 13:20 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: 76 restore scripts across 50 repositories, every one of them run by CI. 1753 releases are tagged across the fleet. 47 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 20 s. OpenSSF Scorecard, run by OpenSSF and not by me, puts the median at 7.3 across 112 repositories. The OpenSSF Best Practices badge, a questionnaire I answered and OpenSSF publishes with every answer, is passing on 102 of 102 registered repositories. The 10 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-29 13:20 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. I drove the container platform decision (Docker over Podman) for moving legacy applications to containers, and I am the customer-side voice of Docker's enterprise customer story on that move: 75% faster deployments and 40% fewer servers.

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

The decisions I publish come from production work. Named first-hand references, each with linked proof: from Docker's then-CEO, the Docker Captains program lead, the lead of Docker's customer case study program, a published security author, and the lead of Snyk's ambassador program.

10 vendor community titles