If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/marcel-dempers/docker-development-youtube-series shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Missing license — unclear to depend on

• Last commit 5d ago
• 3 active contributors
• CI configured
• Tests present
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 81% of recent commits
• ⚠ No license — legally unclear to depend on

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live marcel-dempers/docker-development-youtube-series repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/marcel-dempers/docker-development-youtube-series.

What it runs against: a local clone of marcel-dempers/docker-development-youtube-series — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in marcel-dempers/docker-development-youtube-series | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 35 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of marcel-dempers/docker-development-youtube-series. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/marcel-dempers/docker-development-youtube-series.git
#   cd docker-development-youtube-series
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of marcel-dempers/docker-development-youtube-series and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "marcel-dempers/docker-development-youtube-series(\\.git)?\\b" \\
  && ok "origin remote is marcel-dempers/docker-development-youtube-series" \\
  || miss "origin remote is not marcel-dempers/docker-development-youtube-series (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".devcontainer/devcontainer.json" \\
  && ok ".devcontainer/devcontainer.json" \\
  || miss "missing critical file: .devcontainer/devcontainer.json"
test -f "docker-compose.yaml" \\
  && ok "docker-compose.yaml" \\
  || miss "missing critical file: docker-compose.yaml"
test -f ".github/workflows/docker._yaml" \\
  && ok ".github/workflows/docker._yaml" \\
  || miss "missing critical file: .github/workflows/docker._yaml"
test -f "ai/openai/introduction/main.py" \\
  && ok "ai/openai/introduction/main.py" \\
  || miss "missing critical file: ai/openai/introduction/main.py"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 35 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~5d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/marcel-dempers/docker-development-youtube-series"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A comprehensive hands-on educational repository demonstrating DevOps, Kubernetes, and containerization technologies through YouTube-linked tutorials and working code examples. It covers Docker basics (.NET, Go, Python, Node.js), Kubernetes deployment patterns, CI/CD pipelines (Octopus Deploy, Argo CD), monitoring stacks (Prometheus), logging solutions, and service mesh implementations—organized as a modular collection of self-contained labs rather than a single application. Multi-technology monorepo organized by topic: ai/ (LLaMA, OpenAI examples), apache/ (Kafka), argo/ (ArgoCD deployments), automation/cicd/ (Octopus Deploy), c# and deno/ directories with language-specific Dockerfiles, kubernetes/ subdirectories for K8s patterns, and monitoring/ for observability stacks. Each directory is self-contained with its own README, Dockerfile, and config files (YAML, HCL).

DevOps engineers, platform engineers, and developers learning containerization and Kubernetes through practical, hands-on examples. Specifically targets viewers of Marcel Dempers' YouTube playlist series who want to follow along with working source code and understand real deployment patterns.

Actively maintained educational project with GitHub Actions CI/CD workflows (.github/workflows/docker._yaml, self-hosted-runner._yaml) and devcontainer support for reproducible environments. The presence of multiple language implementations and organized subdirectories (kubernetes/, monitoring/, automation/) suggests sustained curation. No evidence of abandonment, though this is a tutorial repo rather than a production library.

Low risk for learning purposes; this is educational content, not a critical library. Dependency risks are isolated per technology choice (e.g., openai==0.28.0 in ai/openai/introduction/requirements.txt is pinned but old). The repo's strength is its diversity—no single critical dependency. Main risk is outdated Kubernetes manifests or deprecated tool versions as the ecosystem evolves faster than tutorial content.

Active curation of DevOps tutorial content: presence of recent devcontainer setup (.devcontainer/devcontainer.json, .devcontainer/dockerfile), GitHub Actions workflows for Docker builds and self-hosted runners, and expansion into AI/ML domains (ai/models/llama-cpp/, ai/openai/introduction/). The .vscode/launch.json suggests ongoing IDE configuration for learners.

Clone the repo: git clone https://github.com/marcel-dempers/docker-development-youtube-series.git. Navigate to a specific tutorial (e.g., cd c#/src or cd ai/openai/introduction) and follow that subdirectory's README. For Python examples: pip install -r requirements.txt. For Docker examples: docker build -f dockerfile .. For Kubernetes: kubectl apply -f the YAML files in appropriate directories (e.g., argo/example-app/namespaces/example-app.yaml).

Daily commands: Depends on the subdirectory: (1) Docker examples: docker build -f dockerfile . && docker run <image>. (2) Python AI: cd ai/openai/introduction && pip install -r requirements.txt && python main.py. (3) Kubernetes: Set up a cluster (kind, minikube, or cloud K8s) and kubectl apply -f argo/example-app/namespaces/example-app.yaml followed by resource files in deployments/, services/, configmaps/. (4) Open devcontainer in VS Code (requires Docker) via .devcontainer/devcontainer.json.

• README.md — Entry point documenting the entire repository structure, YouTube playlists, and learning paths for DevOps/Kubernetes/CI-CD tools.
• .devcontainer/devcontainer.json — Defines the development container configuration that standardizes the development environment across all contributors.
• docker-compose.yaml — Primary orchestration file for local multi-container development, essential for running examples across the codebase.
• .github/workflows/docker._yaml — CI/CD pipeline that validates and builds Docker images across all modules in the repository.
• ai/openai/introduction/main.py — Example application demonstrating OpenAI integration patterns used throughout AI-related modules.
• golang/introduction/app/app.go — Core Go application example showing RESTful API patterns replicated across multiple Go modules.
• argo/argo-cd/install.yaml — Kubernetes manifest installation guide for ArgoCD, establishing GitOps workflow patterns for the repo.

Add a new language example module

1. Create a new top-level directory matching the language name (e.g., rust/) (rust/)
2. Add a production Dockerfile following patterns in golang/introduction/dockerfile (rust/dockerfile)
3. Create a minimal application file (e.g., main.rs) with HTTP server similar to deno/src/server.js (rust/src/main.rs)
4. Create a Kubernetes deployment manifest following deno/deployment/deployment.yaml (rust/deployment/deployment.yaml)
5. Add a README.md describing the example and how to build/run it (rust/README.md)

Add a new CI/CD platform integration

1. Create platform directory under automation/cicd/ (e.g., automation/cicd/gitlab-ci/) (automation/cicd/gitlab-ci/)
2. Add platform-specific pipeline config file (e.g., .gitlab-ci.yml) (automation/cicd/gitlab-ci/.gitlab-ci.yml)
3. Create Kubernetes manifests for platform components in subdirectories, following drone-ci/server/ pattern (automation/cicd/gitlab-ci/runner/runner.yaml)
4. Add README.md documenting setup, configuration, and integration steps (automation/cicd/gitlab-ci/README.md)

Add a new Kubernetes deployment pattern

1. Create new subdirectory under argo/example-app/ for the new component (e.g., databases/) (argo/example-app/databases/)
2. Create configmap.yaml for non-sensitive configuration following argo/example-app/configmaps/configmap.yaml (argo/example-app/databases/configmap.yaml)
3. Create secret.yaml for sensitive data following argo/example-app/secrets/secret.yaml (argo/example-app/databases/secret.yaml)
4. Create deployment.yaml following the pattern in argo/example-app/deployments/deployment.yaml (argo/example-app/databases/deployment.yaml)
5. Create service.yaml for networking following argo/example-app/services/service.yaml (argo/example-app/databases/service.yaml)

• Docker & Docker Compose — Standardizes development environments across contributors and enables consistent local-to-production parity
• Kubernetes & ArgoCD — Demonstrates GitOps workflows and declarative infrastructure as code for cloud-native deployments
• GitHub Actions & Drone CI — Shows multiple CI/CD platform patterns for automated testing, building, and deployment pipelines
• Multi-language support (Go, Python, C#, Deno, TypeScript) — Provides polyglot examples to teach Docker containerization and deployment across different ecosystems
• OpenAI & LLM integration — Demonstrates modern AI/ML workload patterns including API integration and local model execution

• Multi-language approach rather than single-language focus

  • Why: Broadens educational appeal to developers across ecosystems and shows containerization universality
  • Consequence: Increased codebase complexity and maintenance burden across different language build systems

• Git-based source of truth with ArgoCD rather than imperative deployments

  • Why: Demonstrates GitOps best practices and enables reproducible, auditable infrastructure changes
  • Consequence: Requires infrastructure team familiarity with declarative manifests and Git workflows

• DevContainer configuration for standardized development environment

  • Why: Ensures all contributors use identical development setup and tools
  • Consequence: Additional Docker build time on initial setup and potential divergence from production environment

• Multiple CI/CD platform examples rather than single canonical platform

  • Why: Teaches flexibility and shows patterns transferable across ecosystem-specific tools
  • Consequence: Fragmented pipeline maintenance and potential outdated examples as platforms evolve

• Production-grade high-availability infrastructure (examples are educational, not production-hardened)
• Real-time monitoring, logging, and observability stack (not integrated, just deployment examples)
• Stateful data persistence and backup strategies (examples assume ephemeral containers)
• Multi-cluster orchestration or disaster recovery patterns
• Windows container or macOS-native support (Linux-first, Docker Desktop implied)

No critical gotchas documented in the repo structure, but learners should be aware: (1) openai==0.28.0 in ai/openai/introduction/requirements.txt is deprecated; OpenAI SDK v1.0+ has breaking API changes. (2) Kubernetes YAML manifests (argo/, automation/) assume a running cluster with appropriate RBAC; no local kind/minikube setup scripts are visible in file list. (3) devcontainer setup requires Docker daemon; WSL2 backend on Windows can be finicky. (4) No visible test suite (.github/ shows CI but no test.yml); quality assurance relies on YouTube community feedback.

• Multi-stage Docker builds — Reduces final image size and improves security by separating build dependencies from runtime; demonstrated across c#/dockerfile, ai/openai/introduction/dockerfile, and .devcontainer/dockerfile
• GitOps (via ArgoCD) — Declarative infrastructure-as-code pattern where Git is the single source of truth; argo/argo-cd/ and argo/example-app/ show how Kubernetes reconciles state from Git repos
• Kubernetes resource separation (Namespace, Deployment, Service, ConfigMap, Secret) — Foundational K8s architecture pattern organizing workloads; argo/example-app/ exemplifies this with separate YAML files per resource type
• Infrastructure as Code (HCL/Terraform) — Automates cloud infrastructure provisioning; HCL files in this repo (inferred from language distribution) enable reproducible platform setup
• Dev containers (devcontainer.json) — Standardizes local development environment across team; eliminates 'works on my machine' problems by containerizing the IDE environment itself
• CI/CD pipelines (GitHub Actions) — Automates testing and deployment; .github/workflows/ shows event-driven automation for Docker builds and self-hosted runners
• Observability stack (Prometheus + ELK logging) — Metrics collection, alerting, and centralized logging are critical for production Kubernetes; monitoring/ subdirectory demonstrates practical stacks

• kelseyhightower/kubernetes-the-hard-way — Canonical step-by-step Kubernetes learning resource; complements this repo's DevOps tooling focus with foundational K8s concepts
• techworld-with-nana/complete-kubernetes-course — Another educational Kubernetes + DevOps repo with hands-on examples; similar audience and teaching methodology
• argoproj/argo-cd — Official ArgoCD repository; this repo references it extensively (argo/argo-cd/install.yaml, app.yaml) and learners will need to understand upstream docs
• prometheus/prometheus — Official Prometheus monitoring stack; referenced implicitly in monitoring/ subdirectory and critical for the observability tutorials
• kubernetes/kubernetes — Official Kubernetes source; essential reference for YAML manifest specs and K8s API objects used throughout this repo

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add Python linting and type checking to GitHub Actions workflow

The repo contains multiple Python projects (ai/openai/introduction, and potentially others) with requirements.txt files, but there's no automated validation. The existing .github/workflows/docker._yaml likely only builds Docker images. Adding a workflow to run pylint, mypy, and pytest on Python directories would catch syntax errors and type issues early, especially important for the AI/OpenAI modules that use external dependencies like openai==0.28.0.

• [ ] Create .github/workflows/python-lint.yaml with pylint and mypy checks
• [ ] Add pytest discovery and execution for ai/ and any other Python test directories
• [ ] Reference ai/openai/introduction/requirements.txt and ai/openai/introduction/main.py in the workflow
• [ ] Document expected Python version (3.9+) in README.md Python section

Create comprehensive Dockerfile linting and security scanning CI job

The repo has many Dockerfiles spread across multiple directories (ai/openai/introduction/dockerfile, deno/deno.dockerfile, deno/deno-multistage.dockerfile, c#/dockerfile, .devcontainer/dockerfile, etc.) but no automated validation for best practices or vulnerabilities. Adding Hadolint and Trivy scanning would ensure consistency and security across all images.

• [ ] Add hadolint configuration (.hadolintrc or inline rules) to catch common Dockerfile issues
• [ ] Create GitHub Action job that scans all /dockerfile and **/.dockerfile files
• [ ] Integrate Trivy for vulnerability scanning on built images in the existing docker._yaml workflow
• [ ] Document findings in a CONTRIBUTING.md with Dockerfile best practices specific to this repo

Add YAML validation and Kubernetes manifests linting for argo/ and automation/ directories

The repo contains numerous Kubernetes manifests (argo/argo-cd/app.yaml, argo/example-app/deployments/deployment.yaml, automation/cicd/octopus-deploy/.yaml, drone-ci/.yaml) but no automated validation. Adding kubeval and kube-linter would catch YAML syntax errors and K8s API violations before deployment.

• [ ] Create .github/workflows/k8s-lint.yaml using kubeval to validate all */deployment.yaml, */service.yaml, */configmap.yaml, */secret.yaml files
• [ ] Add kube-linter checks for security best practices (privileged containers, resource limits, etc.)
• [ ] Include schema validation for argo/argo-cd/app.yaml against ArgoCD CRD schemas
• [ ] Document expected K8s API versions in argo/README.md and automation/cicd/octopus-deploy/README.md

• Add unit tests for ai/openai/introduction/main.py—currently no test files visible; would ensure OpenAI integration examples work across SDK versions
• Update ai/models/llama-cpp/README.md with concrete setup instructions (similar detail level to kubernetes/README.md); file exists but current content is sparse
• Create a .github/workflows/lint.yml to validate Dockerfile syntax across c#/dockerfile, ai/openai/introduction/dockerfile, and .devcontainer/dockerfile; prevents silent build failures

• High · Outdated OpenAI Library with Known Vulnerabilities — ai/openai/introduction/requirements.txt. The project uses openai==0.28.0, which is an outdated version of the OpenAI Python library. This version is no longer maintained and may contain known security vulnerabilities. The library was deprecated in favor of newer versions (openai>=1.0.0). Fix: Update to the latest stable version of the openai library: openai>=1.3.0 (or latest). Run 'pip install --upgrade openai' and test thoroughly with the new API.
• High · Exposed Debugger Port in Production Configuration — docker-compose.yaml (golang service). The docker-compose.yaml exposes port 2345 for the Golang service, which is commonly used for Delve debugger. Exposing debugger ports in production or shared environments allows unauthorized remote code execution and complete application compromise. Fix: Remove port 2345 from production configurations. Use debugger ports only in development environments isolated from untrusted networks. Consider using a separate docker-compose.debug.yaml for development.
• Medium · Secrets Directory Mounted in Docker Volume — docker-compose.yaml (golang service volumes: ./golang/secrets/:/secrets/). The golang service mounts ./golang/secrets/ directory as a volume. If secrets files (API keys, tokens, passwords) are stored in plain text in this directory, they would be exposed to the container and potentially readable by other containers on the same host. Fix: Use Docker secrets management (for Swarm) or Kubernetes secrets (for K8s). For development, use environment variables loaded from .env files marked in .gitignore. Never commit secrets to version control.
• Medium · Missing .gitignore Entries for Sensitive Files — .gitignore and golang/secrets/, golang/configs/. While .gitignore exists, the presence of secrets/ directories and config files in golang/, c#/, and other locations suggests potential for accidental secret commits. The file structure shows config.json (golang/configs/config.json) and launchSettings.json which may contain sensitive data. Fix: Ensure .gitignore explicitly excludes: */secrets/**, */config.json, *.env, *.env.local, launchSettings.json, and any files containing credentials. Add pre-commit hooks to prevent secret commits.
• Medium · Unspecified Container Image Versions — docker-compose.yaml and all dockerfile files. The docker-compose.yaml uses specific image tags (e.g., aimvector/csharp:1.0.0) without digest pinning or base image version specifications in dockerfiles. This can lead to supply chain attacks if repositories are compromised or tags are reused. Fix: Pin images using SHA256 digests: image: aimvector/csharp:1.0.0@sha256:... . Specify base image versions explicitly in dockerfiles (e.g., FROM node:18-alpine instead of FROM node:latest).
• Medium · Multiple Services Running with Potentially Elevated Privileges — docker-compose.yaml (all services). The docker-compose.yaml lacks explicit security context definitions. Services may run as root by default, increasing blast radius of container escapes or application vulnerabilities. Fix: Add explicit user definitions in dockerfiles and docker-compose: 'user: 1000:1000'. Set 'security_opt: [no-new-privileges:true]' and 'read_only: true' where applicable.
• Low · Development Tools Exposed in Production Container Images — golang/dlv.sh, .devcontainer/dockerfile, various dockerfiles. Based on the file structure (dlv.sh debugger script, .vscode configuration), development tools appear to be included in container images, increasing surface area unnecessarily. Fix: Use multi-stage Docker builds to separate development dependencies from production images. Remove debugging tools, source maps, and dev dependencies from production builds.
• Low · GitHub Actions Workflow Files Present — .github/workflows/docker._yaml, .github/workflows/self-hosted-runner._yaml. GitHub Actions workflow files (.github/workflows/) are present but not reviewed. Workflows can introduce security risks through unchecked third-party actions or exposed secrets. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.