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 on kind every day (the OSCAL evidence on every push and every week), 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. SCADA StrangeLove's awesome-ai-security-tools keeps it on its watchlist, with the air-gapped claim scoped to the local-model profile.
• 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. Jimmy Song's awesome-cloud-native lists it under Security & Compliance.
• kubernetes-llm-inference-gateway: what routing by prefix cache is worth on Kubernetes, measured. The llm-d router against a plain round-robin Service, in front of the same four simulated vLLM replicas, under conversations that resend their history: on every run the router brings the median time to first token after the first turn to about a third of round-robin's and finds 79% of prompt tokens in cache against about 40%. It also found the price of routing by load. A replica that answers every request with an instant error while its health check passes never looks busy, and it took three quarters of the router's requests at 150 a second; llm-d's endpoint-health-filter, merged after v1.0.0, brought that to none, and both builds are measured every week. The first run on a real GPU, by hand on an NVIDIA A10G because no L4 was free, kept the router at 0.42 to 0.50 of round-robin's time to first token after the first turn, and put a million output tokens at $0.84 against $1.23.
• 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.
• kubernetes-oscal-evidence: the flagship's admission policies turned into evidence an auditor can check without trusting me. Every push brings them up on kind, shows them the flagship's planted pods, and turns what happened into OSCAL assessment results with OSCAL Compass: C2P reads Kyverno's PolicyReports, compliance-trestle builds and validates the documents, and each release carries them signed with cosign. In run 41361749143 all 8 controls from the SSDF, SP 800-53 and the AI RMF were satisfied, each on a row of the account's control-to-test matrix, and 16 planted pods were refused. It found that Kyverno 1.19 writes no admission report for a CEL policy that can deny, not even for the pod it admits: an auditor reading the reports would have seen nothing where the strongest control was working.
• cypress-cloud-triage-agent: a failing Cypress test is untrusted input to the AI agent that triages it, because the failure message carries whatever the application showed. The stack around the agent assumes it will obey a note planted there: only a signed delivery starts a triage, the agent reads its own run and no other through a door in front of Cypress Cloud's MCP tools, holds no Cypress, Slack or Kubernetes credential, and posts once, through a notifier that writes Cypress's own counts above its words. It found that Cypress's docs keyed replay protection on a header the signature does not cover, and proposed a change to them.

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, metrics-server on EKS, why Kyverno reports an attestation as missing when its download failed, traced to the lines that drop the error, llm-d's endpoint-health-filter measured before any release carries it, OSCAL Compass's C2P with a reproduction, Kyverno's missing admission reports reproduced independently, gVisor's fix for the swap finding tested on the reproducer, and review suggestions to Kyverno's docs, applied as written and merged, and to two of its policies, on Flux image provenance and runtime socket mounts, taken up by their authors. Kyverno has since merged a change to its 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.
• os-shell-docker and kubectl-docker: a way off Bitnami's frozen images. bitnami/os-shell and bitnami/kubectl stopped publishing versioned tags in August 2025, and the charts that pinned them stopped getting fixes; on 2026-10-30 the last versioned os-shell carried 119 critical and high findings with a fix it will never get. These two keep the layout Bitnami's charts expect and are checked against the last versioned Bitnami image on every weekly, signed build. os-shell also runs Bitnami's own PostgreSQL and Redis charts on kind before it publishes, and refuses an image that carries a fixable critical or high finding.
• jmx-exporter-docker: the same way off for bitnami/jmx-exporter, the JMX sidecar that Bitnami's Kafka, Tomcat and SonarQube charts, among others, start with a command line their values cannot change. The exporter is built from source at a pinned commit, every Maven artifact the build resolves is checked against a recorded SHA-512, and Bitnami's own Kafka chart runs it on kind before anything is published; on 2026-11-02 the last versioned Bitnami image carried 55 critical and high findings with a fix.
• 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. Amazon credits me as Editor on the paperback, hardcover and Kindle editions, with an author page; also on 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:

105 repositories under this standard: 51 self-hosted applications behind Traefik, 17 game servers, 10 other stacks, 8 Terraform pipelines on AWS, 8 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-11-03 04:16 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. 2005 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 18 s. OpenSSF Scorecard, run by OpenSSF and not by me, puts the median at 7.5 across 116 repositories. The OpenSSF Best Practices badge, a questionnaire I answered and OpenSSF publishes with every answer, is passing on 104 of 104 registered repositories. The 12 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-11-06 14:36 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