DEV Community

SHIVAM UPADHYAY
SHIVAM UPADHYAY

Posted on

I Built an AI That Designs MLOps Infrastructure (Without Letting AI Generate YAML)

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
Enter fullscreen mode Exit fullscreen mode

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

💻 GitHub: https://github.com/Upshivam786/DeployCraft-AI/tree/main

I'd appreciate any feedback or suggestions from people working in DevOps, Cloud Engineering, or MLOps.

Top comments (0)