DEV Community: BuildMintZ Media

AWS vs Azure on a Budget: Building a Production-Like Cloud Platform on an 8GB Dell PC

BuildMintZ Media — Thu, 18 Jun 2026 15:48:53 +0000

From Docker Desktop to Cloud Architect: Building a Production-Grade Platform on an 8GB Dell

You've felt it. That moment when Docker Desktop starts consuming 6GB of your 8GB RAM and your Slack notifications turn into a slideshow. You've hit the ceiling. The obvious next step—jumping straight to AWS or Azure—can quickly turn into a monthly bill once virtual machines, storage, databases, load balancers, and monitoring services begin to accumulate.
There's a third path. One that enterprises have been using for two decades. One that teaches you actual cloud architecture instead of cloud bill shock.
This is everything I learned building that third path on an old Dell desktop.

The Problem Most Beginners Face

Here's how it goes for most engineers I talk to. You start enthusiastically:
text
Laptop (16 GB RAM, plenty to spare)
↓
Docker Desktop
↓
"Let me spin up 20 containers"
↓
RAM exhaustion
↓
Networking confusion
↓
Everything breaks after reboot

And then comes the realization. Docker Desktop is genuinely brilliant for getting started. It abstracts away networking complexity, allowing you to have PostgreSQL, Redis, Nginx, and your app running locally in minutes. That's valuable. But here's what it doesn't teach you: It doesn't teach you how infrastructure actually works.
When you hit its limits, the natural reaction is to jump straight to AWS EC2 or Azure VMs. You provision an instance, install Docker, and suddenly you're paying $50–200/month to learn—and you're learning cloud provider abstractions, not the fundamentals.
There's a middle ground. One that costs nothing and scales from your laptop to actual production architectures. Most beginners don't know it exists.

Why Not Just Use AWS or Azure?

Before we go any further, it's important to clarify something.
The goal of this project is not to replace AWS or Azure.
The goal is to understand the architectural principles that make AWS and Azure work.
Many engineers reach a point where Docker Desktop is no longer enough and immediately jump into cloud providers. While this is a valid path, it often means paying monthly cloud costs before fully understanding the underlying infrastructure.
For learning purposes, an old Dell desktop can teach many of the same concepts:

**Requirement AWS Azure Old Dell/Homelab

Learn Linux Administration ✓ ✓ ✓
Learn Virtualization Hidden Hidden ✓
Learn Kubernetes EKS AKS K3s
Learn Networking ✓ ✓ ✓
Learn GitOps ✓ ✓ ✓
Learn Monitoring & Observability ✓ ✓ ✓
Learn Backup & Disaster Recovery ✓ ✓ ✓
Monthly Cost $$$ $$$ Existing Hardware**

For reference, even a small cloud learning environment can quickly accumulate costs:
• EC2 Virtual Machine (AWS): ~$30–40/month
• Azure Virtual Machine: ~$30–40/month
• EKS Control Plane: ~$72/month
• Managed PostgreSQL: ~$20–50/month
• Load Balancers, Storage, Monitoring: Additional costs

Meanwhile, an existing Dell desktop can provide a self-hosted platform for experimenting with the same cloud architecture concepts.

Who Is This For?
This approach is ideal for:
• Developers learning Kubernetes
• DevOps Engineers
• Platform Engineers
• Cloud Engineers
• Students building real-world experience
• Anyone interested in Cloud Architecture, GitOps, Observability, and Disaster Recovery

This approach is NOT intended for:
• High-traffic production workloads
• Mission-critical applications
• Multi-region high-availability systems
The purpose is education, experimentation, and developing a deep understanding of how modern cloud platforms operate beneath the managed services.

What This Teaches That Cloud Certifications Don't
By building everything yourself, you will eventually encounter:
• DNS failures
• Storage failures
• Node failures
• Networking failures
• Backup failures
• Recovery procedures

These are lessons that managed cloud services often hide.
For example:
• EKS hides the Kubernetes control plane
• AKS hides much of the cluster management
• RDS hides database operations
• Azure Database for PostgreSQL hides backup and recovery complexity

Building a self-hosted Kubernetes cluster forces you to understand these systems directly, making the transition to AWS, Azure, or Google Cloud significantly easier later.

The Missing Layer: Platform Engineering
Many engineers think cloud architecture is simply learning AWS services or Azure services.
In reality, modern organizations are increasingly adopting Platform Engineering practices.
Platform Engineering focuses on creating self-service platforms that allow developers to deploy, monitor, and manage applications without needing to understand every infrastructure detail.

The architecture built in this guide introduces many of the same concepts used by internal platform teams:
• Infrastructure as Code (Terraform, Ansible)
• Kubernetes orchestration
• GitOps workflows
• Observability and Monitoring
• Secrets Management
• Disaster Recovery
• Automation and Self-Service

Whether the underlying infrastructure runs on AWS, Azure, Google Cloud, OpenStack, or a Dell desktop in your home office, the architectural principles remain largely the same.
The goal is not simply to learn cloud services.
The goal is to understand how modern platforms are designed, operated, secured, and automated.
As organizations adopt Kubernetes, GitOps, Infrastructure as Code, and self-service developer platforms, Platform Engineering has emerged as one of the fastest-growing disciplines in modern infrastructure teams.

The concepts covered throughout this guide form many of the foundational building blocks used by Platform Engineering teams today.

What Is a Hypervisor? (And Why It Matters)
At its core, a hypervisor is simple: it's software that sits between your hardware and your operating systems, letting you run multiple operating systems simultaneously, each thinking it owns the hardware.
Here's the mental model:
text
Physical Hardware (CPU, RAM, Disk, NIC)
↓
Hypervisor
/ | \
VM1 VM2 VM3
(Linux) (Linux) (Windows)

Each virtual machine gets isolated access to vCPUs, RAM, virtual storage, and network interfaces. This is the foundation of every cloud provider. Understanding this is understanding 80% of AWS, Azure, and Google Cloud.
Type 1 vs Type 2 Hypervisors
This distinction matters for your architecture decision.
Type 1 Hypervisors (Bare Metal): Run directly on physical hardware with no host OS. Examples: ESXi, Hyper-V, KVM, Proxmox VE, XCP-ng.
Type 2 Hypervisors (Hosted): Run as an application on an existing OS. Examples: VirtualBox, VMware Workstation, Parallels.

Enterprise environments use Type 1 almost exclusively for direct hardware access, better performance isolation, and lower latency. When you learn on a Type 1 hypervisor, you're learning the exact architecture that banks, hosting providers, and cloud platforms use under the hood.
The Hypervisor Comparison for Your 8GB Dell

Hypervisor Comparison for an 8GB Dell Desktop
Hypervisor Enterprise Adoption Resource Usage Ease of Use Learning Value Cost
Proxmox VE High (SMBs, MSPs, Homelabs) Low Easy ⭐⭐⭐⭐⭐ Excellent Free
VMware ESXi Very High (Enterprise Standard) Low Easy ⭐⭐⭐⭐⭐ Excellent Commercial Licensing
Microsoft Hyper-V Very High (Windows Environments) Moderate Easy ⭐⭐⭐⭐ Good Included with Windows Server
XCP-ng Growing Adoption Low Moderate ⭐⭐⭐⭐ Very Good Free
KVM Extremely High (Cloud Providers, OpenStack, Hosting) Very Low Advanced ⭐⭐⭐⭐⭐ Excellent Free
Recommendation for an 8GB Dell
Requirement Best Choice
Lowest Cost Proxmox VE
Easiest Learning Curve Proxmox VE
Most Enterprise Exposure VMware ESXi
Closest to Cloud Provider Internals KVM
Best Overall Balance 🏆 Proxmox VE

Why Proxmox VE?

Free and open source
Lightweight enough for 8GB RAM systems
Built on proven KVM virtualization technology
Includes a modern web management interface
Supports clustering, snapshots, backups, and storage management
Teaches skills directly transferable to AWS, Azure, Google Cloud, OpenStack, and enterprise datacenters

For an old Dell desktop intended for Kubernetes, GitOps, Platform Engineering, and cloud architecture learning, Proxmox VE offers the best balance between resource efficiency, usability, and real-world relevance.

Why Linux Wins for This Architecture
You need to make a choice early: Windows or Linux? The answer matters more than you think.
Docker Desktop vs. Kubernetes Path
• Windows + Docker Desktop: You're learning containers in isolation, limited to local networking.
• Linux + Kubernetes: You're learning distributed systems, cluster architecture, service discovery, and self-healing.

The Linux Advantages
Linux wins for concrete, measurable reasons:
Resource Efficiency: Proxmox overhead is ~1 GB RAM vs. Windows Server's ~2–4 GB. On an 8GB machine, this is critical.
Native Container Support: The Linux kernel has native container primitives (cgroups, namespaces). Containers are first-class citizens, not emulated.
Kubernetes is Linux-native: Windows support exists but is an afterthought. Networking and observability are all Linux-optimized.
Better Automation: Standard UNIX tooling and Infrastructure-as-Code tools like Ansible and Terraform assume Linux.
Observability: The /proc filesystem gives direct kernel metrics, and eBPF tools work natively.

The Learning Transfer
When you master Linux on your Dell, you're directly learning what powers AWS EC2 instances, Azure VMs, Google Cloud Compute Engine, and 99% of Kubernetes clusters. Windows is viable, but it costs you RAM you don't have and forces you to learn abstractions instead of fundamentals.

What Enterprises Actually Use
You're not building in a vacuum. Here's the landscape:
VMware ESXi (The Incumbent King): Used by banks, healthcare, and Fortune 500s. Broadcom's acquisition changed everything, and many are migrating to open-source alternatives right now.
KVM (The Hidden Giant): Powers AWS, OpenStack, and dozens of major cloud providers. It scales from a single laptop to hyperscale.
Proxmox VE (The Rising Standard): This is a strategic learning choice. It's not just a hypervisor; it's Debian Linux + KVM + LXC + a Web UI + cluster tools. Learning it teaches you Linux administration, KVM virtualization, storage, networking, and high availability concepts simultaneously.
Organizations are actively adopting Proxmox, XCP-ng, and OpenStack to escape licensing costs and vendor lock-in. If you're choosing a hypervisor today, you're learning skills that are in high demand right now.

Resource Consumption on Your 8GB Dell: The Reality
An 8GB Dell with a 500GB disk isn't a powerhouse, but it's enough. Proxmox is surprisingly efficient.
Hypervisor RAM Used
Proxmox VE ~1 GB
ESXi ~1–2 GB
XCP-ng ~1–1.5 GB
Hyper-V ~2 GB+
KVM (bare) ~100 MB

A Realistic Memory Allocation
text
Host OS (Proxmox itself) ~1 GB
Control Plane VM 2 GB
Worker VM #1 2 GB
Worker VM #2 2 GB
Buffer / Overhead 1 GB
─────────────────────────────────
Total 8 GB

This is tight, but it works for learning Kubernetes architecture.
Disk Space
500GB is equally tight. You'll need to implement log rotation and use tmpfs for temporary data. This constraint actually teaches the storage discipline that enterprises require.
text
Proxmox installation: ~20 GB
Control Plane VM (thin provisioned): ~30 GB
Worker VMs (2x): ~60 GB
Storage for databases, logs, backups: ~100 GB
Free space: ~290 GB

Why Not Just Install K3s Directly on the Dell?
This is a critical question. You could install K3s directly on Ubuntu, but the goal determines the path.
Option Pros Cons
A: Direct K3s Faster boot, lower RAM overhead, direct hardware. No snapshots, not cloud-like, teaches OS management instead of infrastructure.
B: Proxmox + VMs + K3s Reproducible snapshots, isolation, closer to cloud architecture, easy recovery. Slightly higher RAM usage (~1 GB overhead), added complexity.
I'm recommending Option B because it directly mirrors how cloud providers architect systems. The 1GB overhead is worth it to learn isolation, networking, and recovery patterns. When you move to AWS, you're already thinking in VMs + clusters, not just containers on a laptop.

Designing the Cluster Architecture
Here's what we're building. This architecture directly transfers to AWS EKS, Azure AKS, and Google GKE.
text
Dell Desktop (8GB RAM, 500GB Disk)
↓
Proxmox VE
/ | \
┌─────────────┐ ┌──────────┐ ┌────────────┐
│ Control │ │ Worker 1 │ │ Worker 2 │
│ Plane VM │ │ VM │ │ VM │
│ (2GB) │ │ (2GB) │ │ (2GB) │
│ • API Server│ │ • Kubelet│ │ • Kubelet │
│ • Scheduler │ │ • Pods │ │ • Pods │
│ • Controller│ │ • Workld │ │ • Workld │
│ • etcd │ │ │ │ │
└─────────────┘ └──────────┘ └────────────┘
↓
K3s Cluster
/ | \
┌─────────┐ ┌─────────┐ ┌──────────┐
│ ArgoCD │ │PostgreSQL│ │Monitoring│
└─────────┘ └─────────┘ └──────────┘

When you manage this cluster, you're learning how to provision resources, network multiple machines, and handle failures gracefully. These are the exact concepts required for any managed Kubernetes service.
Why K3s Instead of Full Kubernetes?
K3s is not "Kubernetes lite" in the sense of being incomplete. It is Kubernetes—certified, with the same API, running the same workloads. It's just optimized for resource-constrained environments.
The critical difference? K3s teaches you what's happening inside the control plane. Both AWS EKS and Azure AKS abstract it away. You see how the scheduler works, how pods get distributed, and how networking functions. When you move to the cloud, you'll understand what's happening behind the service. That makes you a better engineer.

Storage: The Section Everyone Struggles With
Most tutorials skip storage, and that's why most people get stuck in production. Your cluster will run two types of applications:
• Stateless (Frontend, API Gateway): No persistent storage needed. A pod dies, it gets replaced, and no data is lost.
• Stateful (PostgreSQL, Prometheus): Need persistent storage. When a pod restarts, the data must survive.
Kubernetes Storage Concepts
• PersistentVolume (PV): The actual storage, independent of pods.
• PersistentVolumeClaim (PVC): A pod's request for storage ("I need 10GB of fast storage").
• StorageClass: Defines how storage is provisioned dynamically.
When you deploy PostgreSQL with a PVC, K3s automatically creates the underlying storage. The data persists even when the pod restarts. In the cloud, AWS uses EBS volumes and Azure uses Managed Disks—the Kubernetes abstractions remain the same.

Networking: The Section Everyone Searches For
Networking breaks more homelabs than anything else. Here is the exact architecture you'll be working with:
text
┌─────────────────────────────────────────────┐
│ Node Network (VM to VM) │
│ (192.168.122.0/24 or your Proxmox range) │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ Kubernetes Service Network │
│ (Usually 10.43.0.0/16 in K3s) │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ Kubernetes Pod Network │
│ (Usually 10.42.0.0/16 in K3s) │
└─────────────────────────────────────────────┘
Common Networking Mistakes (And How to Avoid Them)
• Mixing Docker Networks: Keep Docker out of your cluster entirely. Use only Kubernetes' native networking.
• Mixing Host Networking: Avoid hostNetwork: true. Use Services and Ingress for routing to prevent port conflicts.
• DNS Failures: If pods can't find services, check if CoreDNS is down or if the service name is correct, including the namespace.
• Node Communication Failures: Ensure your Proxmox firewall isn't blocking ports (especially 6443 for the API server).
Configuring a bridge network, static IPs, MetalLB for load balancing, and Traefik Ingress mirrors how AWS and Azure handle networking, just with less abstraction.

Security and Infrastructure as Code
A production-like platform is not complete without security and automation.
At minimum, learn and implement:
• RBAC (Role-Based Access Control)
• TLS certificates
• Network Policies
• Least Privilege access
• Kubernetes Secrets
One common misconception is that Kubernetes Secrets are encrypted by default. They are merely base64 encoded unless encryption at rest is configured. This is one of the most common beginner misconceptions and a frequent topic in Kubernetes security audits.
Store sensitive data such as:
• Database passwords
• API keys
• JWT secrets
• Third-party credentials
using Kubernetes Secrets or an external secrets manager.
It's also important to understand the difference between Infrastructure as Code and GitOps:
Terraform or Ansible:
Infrastructure Creation
ArgoCD:
Application Deployment
Terraform creates infrastructure.
ArgoCD keeps applications synchronized with Git.
Together they form the foundation of modern Platform Engineering and Site Reliability Engineering (SRE) practices.

GitOps: Automating Your Infrastructure
Manually running kubectl apply creates drift and isn't reproducible. Enterprise teams use GitOps: Your Git repository is the single source of truth.
text
Git Repository
├─ deployments/postgres.yaml
├─ services/postgres-service.yaml
└─ configmaps/app-config.yaml
↓
ArgoCD (runs in the cluster)
└─ Every change in Git → auto-deployed
└─ Every 3 minutes: "Is the cluster matching Git?"
└─ If someone deletes a resource, ArgoCD recreates it
└─ Full audit trail by Git commit
Setting up ArgoCD in your K3s cluster teaches you to think in infrastructure-as-code. When you move to AWS CodePipeline or Azure DevOps, the pattern is identical.

Monitoring: The Section you should not Skip
Here's a hard truth: if you can't observe it, you can't operate it. You need three things:
• Metrics (Prometheus): CPU, memory, requests per second. Metrics tell you that something is broken.
• Logs and traces are equally important. Logs and traces help explain why.
• Visualization (Grafana): Beautiful dashboards, historical trends.
• Alerting (Alertmanager): Notifications when things go wrong.
Install the kube-prometheus-stack via Helm. Prometheus scrapes /metrics endpoints from your applications, and Grafana visualizes the time-series data. In the cloud, you'll replace Prometheus/Grafana → CloudWatch + Managed Grafana → Azure Monitor + Azure Managed Grafana, but the patterns of metrics, visualization, and alerting are universal.

Database Layer: Where Everything Gets Real
Every real application needs persistent state. Suddenly, you care about data persistence, backups, and resource management.
Deploying PostgreSQL on K3s with a StatefulSet is the standard. This ensures:
• Data persists across pod restarts.
• Stable network identity (your app connects to a Service, not a pod IP).
• Ordered, graceful shutdown and startup.
Your application connects via the service name (e.g., postgres-service.default.svc.cluster.local). You must implement a backup strategy using pg_dump and a CronJob. This directly maps to managed services like AWS RDS and Azure Database for PostgreSQL.

Backups: The Section That Saves Your Life
What needs backing up? Everything.
• Kubernetes Resources: Back up with kubectl get all -A -o yaml or Velero.
• Databases: Automate with a CronJob.
• Persistent Volumes: Use Velero for snapshots.
Store backups off-site. Your 500GB Dell is a single point of failure. Sync to an external drive, a network machine, or cloud storage (S3/Azure Blob).
The hard truth: A backup you've never tested is useless. Monthly, you should delete something critical and restore it from backup to verify the process works.

Disaster Recovery: From Failure to Running
Hardware fails. Disks corrupt. Build resilience with a plan.
• Hardware Failure: Reinstall Proxmox, restore VM images from backup.
• Cluster Failure: Create a new control plane VM, install K3s, and apply your cluster backup (kubectl apply -f cluster-backup.yaml). Recovery time: ~30 mins.
• Database Failure: Delete the corrupted PVC, let the StatefulSet recreate the pod, and restore from your pg_dump backup. Recovery time: ~10 mins.
• Application Failure: git revert the bad commit, push to main, and ArgoCD auto-deploys the previous version. Recovery time: ~30 seconds.
Keep a Disaster Recovery Runbook with step-by-step procedures. When something breaks at 3 AM, you execute a known plan, not figure one out.

Things That Broke Along the Way
No infrastructure project is complete without mistakes.
Some of the most valuable lessons came from failures:
• DNS issues preventing pods from discovering services
• Worker nodes unable to join the cluster
• PersistentVolumeClaims remaining stuck in Pending state
• PostgreSQL pods restarting unexpectedly
• Backup procedures that had never been tested
• Monitoring systems consuming more resources than expected
These failures forced a deeper understanding of networking, storage, observability, disaster recovery, and Kubernetes operations.
Another important lesson was resource management.
On an 8GB system, every workload must have appropriate resource requests and limits configured to prevent a single application from exhausting cluster resources.
yaml
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
Without resource requests and limits, a single misbehaving application can consume all available memory and destabilize the cluster. This becomes especially important on resource-constrained hardware.
This is the same discipline required in production environments regardless of whether the infrastructure runs locally, in AWS, or in Azure.

Why This Transfers to AWS and Azure
Everything you learned locally maps directly to cloud services.
Your Homelab AWS Azure Concept
Proxmox VE EC2 + VPC + EBS Azure VM + VNet + Managed Disk Infrastructure Platform
VM EC2 Instance Virtual Machine Individual server
K3s EKS AKS Kubernetes cluster
Pod Container Container in Pod Smallest deployable unit
Service Service / Load Balancer Service / Load Balancer Network abstraction
Persistent Volume EBS Managed Disk Persistent storage
ArgoCD CodePipeline Azure Pipelines CI/CD automation
PostgreSQL RDS Azure Database for PostgreSQL Managed relational DB
Prometheus CloudWatch Azure Monitor Metrics & monitoring
Ingress (MetalLB) ALB/NLB Application Gateway Load balancing
The value of your homelab isn't the infrastructure; it's the mental model. Your Kubernetes YAML files and application code work unchanged on EKS or AKS. You'll just be swapping out managed services.

**
What I Would Do Differently: Lessons Learned the Hard Way**
Don't learn on Docker Desktop for too long: Start with Proxmox and VMs immediately. The initial time investment pays off in deep understanding.
Don't mix Docker and VM workers: Choose one abstraction layer. Running Docker containers and Kubernetes pods on the same VM is a debugging nightmare.
Implement backups on day one: The cost of learning this lesson is 3–4 days of reconstruction. It's insurance, not wasted effort.
Use GitOps early: Set up ArgoCD from the start. All changes in Git, no manual kubectl commands. This gives you a complete, auditable history.
Learn networking fundamentals first: Understand Proxmox bridges, Linux bridges, iptables, and DNS before deploying Kubernetes. This saves weeks of pain.
Plan for growth: Design abstractions that allow you to add more nodes later, even if you're starting on a single Dell.

The Complete Architecture Diagram
text
╔════════════════════════════════════════════════════════════════╗
║ Dell Desktop (8GB RAM, 500GB Disk) ║
║ ║
║ ┌────────────────────────────────────────────────────────┐ ║
║ │ Proxmox VE │ ║
║ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ ║
║ │ │ Control │ │ Worker 1 │ │ Worker 2 │ │ ║
║ │ │ Plane VM │ │ VM (2GB) │ │ VM (2GB) │ │ ║
║ │ │ (2GB RAM) │ │ • Kubelet │ │ • Kubelet │ │ ║
║ │ │ • API Server │ │ • Pods │ │ • Pods │ │ ║
║ │ │ • etcd │ │ │ │ │ │ ║
║ │ └──────────────┘ └──────────────┘ └──────────────┘ │ ║
║ └────────────────────────────────────────────────────────┘ ║
║ ↓ ↓ ↓ ║
║ ┌──────────────────────────────────────────────────────────┐ ║
║ │ Kubernetes Services │ ║
║ │ ┌────────────┐ ┌────────────┐ ┌─────────────────────┐ │ ║
║ │ │ PostgreSQL │ │ ArgoCD │ │ Prometheus/Grafana │ │ ║
║ │ │ (Stateful) │ │ (GitOps) │ │ (Monitoring) │ │ ║
║ │ └────────────┘ └────────────┘ └─────────────────────┘ │ ║
║ │ ┌────────────┐ ┌────────────┐ ┌─────────────────────┐ │ ║
║ │ │ Nginx │ │ Backend │ │ Frontend │ │ ║
║ │ │ Ingress │ │ API │ │ (React/Vue) │ │ ║
║ │ └────────────┘ └────────────┘ └─────────────────────┘ │ ║
║ └──────────────────────────────────────────────────────────┘ ║
║ ║
║ ┌────────────────────────────────────────────────────────┐ ║
║ │ Backup & Recovery Strategy │ ║
║ │ • Daily: PostgreSQL dump → backup PVC │ ║
║ │ • Weekly: Velero cluster backup │ ║
║ │ • Monthly: Restore test │ ║
║ │ • Off-site: Weekly sync to USB drive │ ║
║ └────────────────────────────────────────────────────────┘ ║
╚════════════════════════════════════════════════════════════════╝

Transfer to Cloud Platforms
AWS: EKS, EC2, RDS, ALB, CloudWatch
Azure: AKS, VMSS, Azure DB, App Gateway, Azure Monitor

The Path Forward: From Homelab to Production
Weeks 1-4: Solidify. Get K3s running, deploy a simple app, set up GitOps and monitoring, and test a real restore.
Weeks 5-8: Harden. Add RBAC, network policies, secrets management, and resource quotas.
Weeks 9-12: Advance Observability. Implement tracing, log aggregation, alerting, and a runbook. Practice disasters.
Weeks 13+: Move to Cloud. Provision an EKS or AKS cluster. Your YAML files and app code won't change—only the underlying managed infrastructure will.

The One Thing This Accomplishes
This isn't just a tutorial on setting up Proxmox. It's about understanding the relationship between your physical hardware, hypervisors, Kubernetes orchestration, and cloud platforms.
When you finish, you'll understand AWS and Azure not as magic, but as implementations of the same concepts you built locally. Cloud certifications validate knowledge. Building the platform yourself develops operational experience. Both are valuable, but operational experience is what ultimately teaches you how systems behave under failure.

Key Technologies Covered
**• Proxmox VE
• KVM Virtualization
• Linux Administration
• Kubernetes (K3s)
• GitOps
• ArgoCD
• Terraform
• Ansible
• PostgreSQL
• Prometheus
• Grafana
• Disaster Recovery
• Observability
• Platform Engineering
• Site Reliability Engineering (SRE)
• Cloud Architecture
• AWS
• Azure
• Self-Hosted Infrastructure
• Homelab Kubernetes

**
What This Does Not Replace
This architecture is designed for learning, experimentation, and skill development.

It is not intended to replace enterprise cloud platforms.

AWS, Azure, and Google Cloud provide capabilities that are difficult or impossible to reproduce on a single desktop:

Multi-region availability

Managed control planes

Elastic scaling

Enterprise support

Global networking

Managed security services

The purpose of this project is not to compete with cloud providers.

The purpose is to understand the technologies and architectural patterns that cloud providers build upon.

Final Checklist: What You'll Have Built
✅ Proxmox VE running on bare metal
✅ Three Linux VMs (control plane + 2 workers)
✅ K3s Kubernetes cluster
✅ Persistent storage (PostgreSQL with PVCs)
✅ Monitoring stack (Prometheus + Grafana)
✅ GitOps automation (ArgoCD)
✅ Full application layer (frontend + backend + database)
✅ Backup strategy (daily dumps, Velero snapshots)
✅ Tested disaster recovery runbook
✅ A deep understanding of how this maps to AWS and Azure

This is everything I learned building a production-like platform on an 8GB Dell. The mistakes, the victories, the architectural decisions. I hope your journey is less painful and just as enlightening as mine.

What's your experience with homelab Kubernetes clusters? Drop a comment below or connect with me on LinkedIn—I'd love to hear about your journey!

🔗 Related Resources:
• Official K3s Documentation
• Proxmox VE Wiki
• ArgoCD Getting Started Guide
• Prometheus Operator Guide

📌 Share this guide with someone who's struggling with Docker Desktop limits!

Tags: #Kubernetes #DevOps #CloudArchitecture #Homelab #Proxmox #K3s #GitOps #PlatformEngineering #SRE #AWS #Azure #SelfHosted #LearningInPublic

How to Build a Production-Ready SaaS Integration Layer on Azure and AWS (.NET 8)

BuildMintZ Media — Fri, 17 Apr 2026 00:04:43 +0000

I Rebuilt the Same SaaS Integration Layer 6 Times. So I Stopped.

Every new project. Same boilerplate. Different client. Same pain.

After years working as a DevOps engineer — architecting solutions on Azure and AWS, shipping .NET backends, connecting SaaS products to the tools their customers actually use — I noticed a pattern I couldn't shake.

Every project started the same way.

Not with the product. With the plumbing.

Stripe. SendGrid. Twilio. Webhooks. File storage on S3 or Azure Blob. JWT auth. Multi-tenant architecture. Rate limiting. Audit logs.

Six different projects. Six times rebuilding the same foundation. The specifics changed — the stack stayed identical.

So I finally did something about it.

What "the plumbing" actually looks like in production

Let me be specific, because this is where most tutorials stop short.

Webhooks aren't fire-and-forget

Everyone knows how to send a webhook. You POST to a URL. Done.

What most developers underestimate is the retry layer. In production, the receiving end will go down. It will timeout. It will return a 500 at 2am. If you're not handling that, you're losing data.

A production webhook dispatcher needs:

Exponential backoff — not fixed retries. 1min → 2min → 4min → 8min → 16min. Linear retries hammer a struggling server.
Delivery tracking — you need to know which events succeeded, which failed, and which are queued.
Manual retry — operations teams need a button to replay a failed event without re-triggering the source.
Dead letter handling — after N failures, park it somewhere and alert. Don't silently drop it.

I've seen teams burn two weeks building this correctly. Most don't build it correctly at all.

Multi-tenant isn't just a `tenantId` column

Adding a tenantId to your tables is the beginning of multi-tenancy, not the end.

A real multi-tenant architecture means:

Per-tenant database isolation — not just row-level filtering, but the option to physically separate tenant data when compliance requires it
Per-tenant rate limiting — one noisy tenant shouldn't degrade experience for others
Per-tenant audit logs — every action logged, attributable, exportable
Per-tenant API keys — rotation, scoping, revocation, all manageable per customer

This is the stuff that kills SaaS MVPs post-launch when enterprise customers start asking questions.

Data transformation is the unsexy problem nobody talks about

You've connected Shopify to your platform. Now you need to forward that order to your warehouse system — which expects a completely different JSON schema.

You've connected Stripe to your billing layer. Now you need to push that event to your accounting software — which expects yet another format.

This happens constantly in integration work. The standard answer is "write a mapper function." The problem is you end up with dozens of brittle, untestable mapper functions scattered across your codebase.

A better pattern: Liquid templates for JSON-to-JSON transformation. Define the mapping as a template. Test it against sample payloads before deploying. Change the mapping without touching application code.

Shopify order → [Liquid template] → Warehouse API format
Stripe event  → [Liquid template] → Accounting platform format

It sounds simple. It changes how you think about integrations entirely.

The stack that actually covers it

After the sixth rebuild, I documented every decision I'd made — and packaged it into a single .NET 8 platform. Here's what ended up in it:

Payments
Stripe integration, PCI compliant, supporting 7+ payment methods (PayPal, iDEAL, Klarna, Bancontact, Giropay, Sofort). Webhook-driven, not polling.

Webhooks
Full dispatcher with exponential backoff retries, delivery tracking, manual retry, and monitoring.

Email & SMS
SendGrid for transactional email (welcome flows, receipts, alerts). Twilio for SMS (security codes, payment confirmations). Template system with delivery history.

File Storage
AWS S3 and Azure Blob — both, so your cloud strategy doesn't lock you in. Tenant-isolated. Full CRUD.

Data Transformation
Liquid template engine. JSON-to-JSON mapping. Testable before deploy.

Security
JWT with refresh tokens. MFA via TOTP. API key management with rotation. SSO via Google, Azure AD, and Okta. Session management. Rate limiting with configurable quotas per tenant.

Subscriptions
Plan management (Basic/Pro/Enterprise). Lifecycle handling. Cancel and refund flows. Metered billing support.

Observability
Complete audit logging. Health checks (liveness, readiness, detailed). Request/response logging. Performance metrics.

61 endpoints total. Docker-ready. SQLite for local development, SQL Server for production. Swagger/OpenAPI docs included. Deployable to Azure App Service or AWS ECS.

Why build this vs. using Zapier or Make?

Fair question. Here's the honest breakdown:

	This platform	Build yourself	Zapier/Make
Cost	€399 one-time	€30k+ dev time	€500+/month
Time to launch	~10 minutes	3–6 months	~1 day
Full source code	✅	✅	❌
Self-hosted	✅	✅	❌
Webhook retries	✅ built-in	Build yourself	✅
Custom transforms	✅ Liquid templates	Build yourself	Limited
Multi-tenant	✅ built-in	Build yourself	❌
Audit logging	✅ built-in	Build yourself	❌

Zapier is fine for simple automations. It breaks down fast when you need custom transforms, tenant isolation, or anything that touches compliance.

Who this is for

SaaS founders who want to ship product, not infrastructure
Freelancers who deliver .NET backends and are tired of the same setup overhead on every engagement
Dev teams starting greenfield projects who want a production-ready base, not a tutorial skeleton

It is not for you if you enjoy building webhook dispatchers. Some people do. I respect it.

Try it before you buy it

There's a live Test Hub at localhost:5000/testhub after you clone and run docker compose up. Every one of the 61 endpoints is testable before you spend a cent.

If you want to grab it: API Integration & Automation Platform on Gumroad — €399, one-time, full source code, lifetime updates, commercial license. https://youtu.be/3nQfoa8x_kc?si=IGMg41Tt-98q5VOD

30-day money-back guarantee. No questions asked.

Built on .NET 8 · Runs on Azure & AWS · Part of the BuildMintZ platform

What's the integration you've rebuilt the most times? Drop it in the comments — genuinely curious whether webhook retries or multi-tenant auth is the more universal pain point.

Tags: dotnet devops azure aws webdev saas architecture productivity

I was tired of juggling AI APIs… so we built one API for everything

BuildMintZ Media — Tue, 07 Apr 2026 12:37:17 +0000

I got tired of juggling AI APIs… so we built one API for everything

If you’ve worked with AI APIs recently, you probably know the pain:

One API for text
Another for images
Another for speech
Different formats, auth, pricing, limits…
Glue code everywhere

At some point, it stops being “building with AI” and starts being managing APIs.

So we decided to fix that.

What we built

We created a Unified AI Gateway — one API that handles:

Text generation
Image generation
Speech (TTS / STT)
Vision + document analysis
Translation & transcription

All through a single endpoint.

What this actually looks like

Instead of juggling multiple SDKs and APIs, you just send:

POST /api/ai/gateway

With something like:

{
"category": "image",
"input": {
"text": "Futuristic data center"
},
"quality": "flux-pro"
}

Or:

{
"category": "document",
"subType": "invoice",
"input": {
"prompt": "Enterprise invoice for AI consulting"
},
"language": "es"
}

That’s it. Same structure. Same endpoint.

Why we built it this way

Most tools optimize for model access.
We wanted to optimize for developer experience.

So we focused on:

⚡ ~50ms average latency
🧠 Intelligent model routing (you don’t have to pick every time)
🌍 100+ languages
💸 Simple usage-based pricing (1000 free daily neurons)
What surprised us

The biggest win wasn’t performance.

It was how much simpler the codebase became.

Less branching.
Less vendor lock-in.
Less time spent debugging weird API differences.

Try it yourself

If you’re curious, you can explore it here:

Docs → https://docs-api.usefreelanceflow.com/
Swagger (live playground) → https://docs-api.usefreelanceflow.com/swagger
OpenAPI spec → https://docs-api.usefreelanceflow.com/openapi.json
Looking for feedback

This is still early, and we’re actively improving it.

If you’re building anything with AI, I’d genuinely love to know:

What’s annoying you right now?
What APIs are you stitching together?
What would make this actually useful for you?

Tear it apart 👇

We Migrated our AI Agents from Azure to AWS — Here's the Minimal Setup You Actually Need

BuildMintZ Media — Fri, 20 Mar 2026 22:26:41 +0000

After migrating our agent-based document processing system from Azure to AWS, one thing became obvious:

Most cloud setups are wildly over-engineered for development.

You don’t need half the services people default to just to build and test a distributed system.

Here’s the minimal AWS architecture you actually need to develop and run an agent-based pipeline end-to-end — plus what each piece maps to if you’re coming from Azure.

The System

Before we even touch the cloud layer, here’s what’s actually running.

At its core, this is a pipeline of independent Python workers processing documents in stages. Each worker listens to its own queue, does one job well, and hands off to the next stage.

In front of that sits a hybrid FastAPI gateway exposing both REST and GraphQL endpoints, depending on the consumer.

Five containers total:

gateway
ai-core
collector
exporter
redis

[insert architecture diagram here]

Core Services — What You Actually Need

If you're building something similar on AWS, these are the essentials.

RDS (PostgreSQL)

This is your source of truth: datasets, schemas, job states.

You can use SQLite for early local testing — but don’t let that leak into staging. You’ll regret it the moment concurrency shows up.

Raw data in. Clean datasets out. Exports delivered.

It’s cheap, durable, and at any meaningful scale, there’s really no alternative.

This is the backbone of the entire system.

Each worker type gets its own queue:

scraper-jobs
validate-jobs
improve-jobs
refurbish-jobs
export-jobs

This gives you full decoupling:

Workers can scale independently
Crashes are isolated
Deployments don’t ripple across the system

Cognito

Handles authentication for the gateway.

Don’t skip this. Retrofitting auth later is always worse than doing it properly from day one.

Everything runs inside it.

Not optional. No shortcuts here.

What You Can Disable in Dev (and Save Real Money)

While you're still building, you don’t need the full production setup.

Service Why you don’t need it yet Monthly saving
ElastiCache (Redis) Run Redis locally in Docker ~$15
Application Load Balancer Not needed before production traffic ~$18
NAT Gateway Only required for private subnet outbound ~$32

That’s roughly $65/month saved — which adds up fast across a team.

Azure → AWS: The Mapping

[insert comparison table here]

The Key Insight

Cloud providers look very different — but under the hood, they all boil down to the same building blocks:

Identity
Messaging
Storage
Database
Networking

The names change. The SDKs change. The auth models definitely change.

But if your architecture is built around these primitives, switching clouds becomes a configuration problem, not a code problem.

In our case, moving from:

SERVICE_BUS_CONNECTION
AZURE_OPENAI_KEY

to:

IAM roles
Amazon Bedrock

…required zero changes to business logic.

All the seams were already at the infrastructure boundary — exactly where they should be.

Final Thought

If you're building in the cloud right now:

Start minimal — these five services are enough to ship something real
Add complexity only when you have a concrete reason
Optimize cost early — small monthly savings compound quickly

All five containers are now running healthy on AWS.

Curious — are you team AWS or Azure right now?
And has anyone done this migration the other way around?

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products!

BuildMintZ Media — Sat, 07 Mar 2026 20:58:34 +0000

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products!

After months of building, I'm excited to share the first product in my ecosystem:

🔷 Azure SaaS Backend Platform

What makes this different?
→ 1 codebase → 4 marketable products
→ 7 microservices (Payments, Auth, Subscriptions, etc.)
→ Multi-tenant architecture out of the box
→ 30+ API endpoints ready to use
→ Deploys to Azure in minutes

👇 Try it LIVE right now (no signup required):
https://saas-backend-40396021-cjezgvgth5csabhf.francecentral-01.azurewebsites.net/testhub

Test every endpoint yourself:
💳 Process a payment
🔐 Create a tenant
📁 Upload a file
📊 Check audit logs

Everything works. No fake demos. No email required.

Note: This is a commercial product, not open source - production-ready code with commercial license and support.

If you're building a SaaS and tired of rewriting auth and billing every time, this is for you.

👉 Get the code (launch special - 60% off):
https://mintzmedia.gumroad.com/l/uwwgvi

What would you build with a production-ready backend?

dotnet #azure #saas #developer #indiehacker #csharp #commercialsoftware

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products! After months of building, I'm excited to share the first product in my ecosystem: 🔷 Azure SaaS Backend Platform

BuildMintZ Media — Sat, 07 Mar 2026 20:55:31 +0000

🚀 Unified SaaS Backend Starter Kit – .NET 8 Production-Ready Boilerplate Launch your SaaS faster with a complete multi-tenant backend built on .NET 8 and real-world production architecture. https://mintzmedia.gumroad.com/l/uwwgvi

BuildMintZ Media — Thu, 05 Mar 2026 01:24:46 +0000

mintzmedia.gumroad.com

DEV Community: BuildMintZ Media

AWS vs Azure on a Budget: Building a Production-Like Cloud Platform on an 8GB Dell PC

How to Build a Production-Ready SaaS Integration Layer on Azure and AWS (.NET 8)

What "the plumbing" actually looks like in production

Webhooks aren't fire-and-forget

Multi-tenant isn't just a tenantId column

Data transformation is the unsexy problem nobody talks about

The stack that actually covers it

Why build this vs. using Zapier or Make?

Who this is for

Try it before you buy it

I was tired of juggling AI APIs… so we built one API for everything

We Migrated our AI Agents from Azure to AWS — Here's the Minimal Setup You Actually Need

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products!

dotnet #azure #saas #developer #indiehacker #csharp #commercialsoftware

🚀 I just launched a production-ready .NET 8 backend that powers 4 complete SaaS products! After months of building, I'm excited to share the first product in my ecosystem: 🔷 Azure SaaS Backend Platform

🚀 Unified SaaS Backend Starter Kit – .NET 8 Production-Ready Boilerplate Launch your SaaS faster with a complete multi-tenant backend built on .NET 8 and real-world production architecture. https://mintzmedia.gumroad.com/l/uwwgvi

Multi-tenant isn't just a `tenantId` column