# I Built an AI That Designs MLOps Infrastructure (Without Letting AI Generate YAML) > Source: > Published: 2026-07-09 04:46:18+00:00 If you've ever started an AI project, you've probably asked yourself questions like: Should I deploy on Kubernetes or Cloud Run? Do I need Redis? Which database fits this workload? How should I structure CI/CD? What monitoring stack should I use? Choosing an architecture is often harder than writing the application itself. I wanted to see if AI could help with those decisions while keeping the generated infrastructure deterministic and reliable. That idea became DeployCraft AI. The Goal The application asks for a few high-level inputs: Application Framework Cloud Provider Deployment Target Database Vector Database Cache Monitoring Authentication Traffic Budget High Availability Instead of generating code from a prompt, it builds a structured deployment blueprint. The output includes: ✅ Architecture reasoning ✅ Architecture score ✅ Mermaid diagram ✅ Docker Compose / Kubernetes / Cloud Run manifests ✅ GitHub Actions workflow ✅ Security report ✅ Monitoring recommendations ✅ Cost estimation ✅ Downloadable ZIP package The Most Important Design Decision One thing I intentionally didn't do: I never let the LLM generate deployment manifests. Instead, I separated the project into three layers. ``` Configuration │ ▼ Rules Engine │ ▼ Blueprint ┌───────────────┐ │ │ ▼ ▼ Generators AI Advisor │ │ ▼ ▼ YAML Explanations ``` Everything infrastructure-related is deterministic. The rules layer decides: which services exist networking environment variables autoscaling storage deployment topology No AI involved. Template-Based Infrastructure Once the blueprint is built, Jinja2 templates generate: Docker Compose Kubernetes manifests Cloud Run YAML GitHub Actions workflow This means every deployment file is reproducible. AI Only Explains The LLM receives the architecture and answers questions like: Why Cloud Run? Why PostgreSQL? Why Redis? What are the risks? How could this scale? The AI becomes an architecture reviewer rather than an infrastructure generator. I found this separation makes the outputs much more trustworthy. Some Interesting Challenges A few things that took more work than expected: Supporting multiple deployment targets Each target needs different templates while sharing the same architecture model. Making AI output reliable LLMs occasionally fail or return unexpected responses. Instead of crashing the application, I implemented graceful fallbacks so the UI always remains usable. Architecture scoring Rather than asking AI for a score, the application evaluates: Security Scalability Reliability Cost Efficiency Observability using deterministic rules. Packaging everything Instead of displaying lots of text, the application bundles every generated artifact into a downloadable ZIP. Tech Stack Python Gradio Hugging Face Inference API Jinja2 Docker Kubernetes Google Cloud Run GitHub Actions What I Learned This project reinforced something I've been thinking about for a while: AI doesn't need to replace software engineering. It becomes much more useful when it's responsible for reasoning, while deterministic code remains responsible for correctness. That balance made the application significantly more reliable. Try It 🌐 Live Demo: [https://huggingface.co/spaces/Upshivam786/deploycraft-ai](https://huggingface.co/spaces/Upshivam786/deploycraft-ai) 💻 GitHub: [https://github.com/Upshivam786/DeployCraft-AI/tree/main](https://github.com/Upshivam786/DeployCraft-AI/tree/main) I'd appreciate any feedback or suggestions from people working in DevOps, Cloud Engineering, or MLOps.