Rubycon Italy’s Post

Spent the last few weeks heads down building LaunchForge, a SaaS-style project where I focused on applying backend and system design concepts in practice. No tutorials. Just build → break → fix → repeat. Here’s what I actually shipped: 🧠 What I Built Modular backend architecture (routes → services → database layer) Implemented caching + query optimization to reduce unnecessary DB load Added rate limiting to protect APIs from abuse Designed APIs with cleaner request flow to minimize redundant calls ⚙️ Tech Stack → Node.js, Express.js → PostgreSQL + Prisma ORM → React / Next.js → Docker, Prometheus, Grafana ⚡ Performance Work Reduced redundant database queries using caching logic Optimized slow queries using indexing and better schema design Implemented basic rate limiting (middleware-based) Improved API response consistency by removing unnecessary calls 📊 Monitoring & Observability Integrated Prometheus for metrics collection Built Grafana dashboards to track request rate, latency, and system health 🚧 Next Focus → Redis for distributed caching → Advanced rate limiting (production-level) → Better scaling strategies 💡 Key Realization There’s a big difference between knowing tools and building systems that can survive real-world load. This project pushed me from theory into that gap, and I’m actively closing it. Build like it’s going to production. Even if it never does. #Backend #FullStack #DevOps #SystemDesign #BuildInPublic #SaaS #LearningByBuilding

Most projects stop at “it works on my machine.” This one doesn’t. I built a simple full-stack application — but focused on how it actually runs in a real environment. Here’s what’s inside: • Frontend served via Nginx (containerized) • Backend API built with Node.js (Express) • Separate containers for each service • Docker Compose used to run everything together Instead of mixing everything in one setup, the application is split into services — just like real systems. How it flows: User → Frontend (Nginx) → Backend API → JSON Response No complexity for the sake of it. Just a clean setup that shows how services talk to each other. What this project helped me understand better: • How containers isolate services • How frontend and backend communicate in a containerized setup • Why multi-container architecture matters • How Docker Compose simplifies orchestration This is a small project, but it reflects a mindset shift: From writing code → to thinking about deployment. GitHub: https://lnkd.in/gctxFU4Z #Docker #DevOps #NodeJS #Nginx #FullStack #DockerCompose

Being a full-stack dev taught me this: Your backend choices become your frontend problems. Your database design becomes your 3AM problems. Your DevOps skills become your “it works now” problems. Learn the glue between layers. That’s where 90% of bugs live. What’s your hardest “glue” lesson? 👇 #FullStackDeveloper #WebDev #DevTips

⭐ 𝐃𝐢𝐬𝐜𝐨𝐯𝐞𝐫𝐞𝐝 𝐚𝐧 𝐨𝐩𝐞𝐧-𝐬𝐨𝐮𝐫𝐜𝐞 𝐩𝐫𝐨𝐣𝐞𝐜𝐭 𝐰𝐨𝐫𝐭𝐡 𝐬𝐡𝐚𝐫𝐢𝐧𝐠: 𝐊𝐮𝐛𝐞𝐏𝐨𝐥𝐚𝐫𝐢𝐬 If you've ever managed multiple Kubernetes clusters, you know the pain: - Jumping between servers just to switch clusters - Writing endless long kubectl commands to check a pod log - Opening Grafana, then AlertManager, then back to the terminal all for a single issue - Configuring RBAC just to give a developer read-only access KubePolaris addresses all of this with a clean, modern web UI built in React + Go. 𝐖𝐡𝐚𝐭 𝐦𝐚𝐤𝐞𝐬 𝐢𝐭 𝐢𝐧𝐭𝐞𝐫𝐞𝐬𝐭𝐢𝐧𝐠: 🏢 Multi-cluster management from a single interface no more context switching chaos 🔌 Native integration with Prometheus, Grafana, AlertManager, and ArgoCD 🔒 Enterprise-grade RBAC, audit logs, and permission control out of the box 🖥️ Built-in web terminal powered by xterm.js — no local kubectl required 🚀 One-command Docker deployment to get started in minutes 💯 Fully open source under Apache 2.0 The name says it all "𝐏𝐨𝐥𝐚𝐫𝐢𝐬" is the North Star, meant to guide your K8s operations reliably. It's still a young project, but the architecture is solid (single Go binary with embedded React frontend), the documentation is clean, and it already solves real DevOps pain points. If you work with Kubernetes at scale, it's definitely worth a look 👇 https://lnkd.in/es_7E_B9 #Kubernetes #CloudNative #DevOps #OpenSource #K8s #Platform Engineering

Day 7: The Chicken & Egg Problem in Terraform One thing that caught my attention while working with Terraform is the initialization paradox. Terraform needs infrastructure to exist (like a remote state bucket)… But you also want Terraform to create that same infrastructure. That’s a circular dependency. A needs B to exist B needs A to be created Common Scenarios You need an S3 bucket for remote state → but want Terraform to create it Creating a security group that depends on another security group ID → which doesn’t exist yet A CI/CD pipeline needs IAM permissions → but those permissions are managed by Terraform itself So how do we solve it? There are a few practical approaches: 1. Manual Bootstrapping Create the required resource (e.g., S3 bucket) manually using CLI or console, then bring it under Terraform. 2. Two-Stage Deployment Use a separate, minimal Terraform setup just for backend resources. Once created → use it to run your main infrastructure. 3. External Scripting Use scripts (Bash, Python, etc.) to provision prerequisites before running: terraform init terraform apply My Take This problem is inevitable when working with infrastructure. What matters is understanding that:  Not everything can be fully “Terraform-managed” from day one Sometimes you need a bootstrap phase before full automation And once that’s in place… everything becomes repeatable, scalable, and clean. The goal isn’t to avoid these problems. It’s to design around them like an engineer. #Terraform #DevOps #AWS #InfrastructureAsCode #CloudEngineering #ChickenEggProblem

Building a real-time DevOps terminal on a 1GB RAM cloud server forces you to get incredibly creative with infrastructure. Today, I am opening up DriftSeek for core open-source contributions. DriftSeek is an AIOps infrastructure lifecycle manager. It monitors server drift via a Redis-backed cron engine, triggers Telegram alerts with smart cooldowns, and instantly spins up a web-based "War Room" terminal for the team to debug the server together. The Current Architecture: - Frontend: Next.js with node-pty and Socket.io for managing multiple concurrent terminal tabs. - Backend: Express server dynamically spawning alpine:latest Docker containers. - Resource Control: Containers are strictly hardware-capped at 256MB RAM and 0.5 vCPUs to prevent OOM crashes on the host machine. - Speed Layer: Redis Pub/Sub handles the live system metric broadcasting. What we are building next (Looking for Collaborators): We have the foundation, but we are currently tackling a major distributed systems challenge to make the platform production-ready: - Ephemeral Git Workspaces: Intercepting WebSocket disconnects to auto-commit the container's state back to GitHub before instantly destroying the Alpine container (NextAuth repo scopes are already configured). If you are a builder wrestling with Docker resource constraints, Next.js WebSocket state management, or cloud architecture, drop a comment or send me a DM. I will share the repo and the architectural blueprint. Let's build something that actually scales under pressure. #DevOps #Docker #NextJS #OpenSource #SoftwareEngineering #CloudArchitecture

Spent the last 2.5 days debugging something that looked simple — but turned into a full-stack networking puzzle. I had an application working perfectly on: IP:port 😊 But the moment I mapped it to a domain (DNS + reverse proxy), everything started breaking. 😶 Here’s what I was dealing with: 🏗️ Hybrid setup Docker services (frontend, backend workers) Kubernetes cluster (Hatchet, Postgres, RabbitMQ) Reverse proxy using Caddy Keycloak for authentication 💥 Problems I faced 1. Frontend showing OAuth callback errors 2. Keycloak login not redirecting properly 3. Hatchet stuck on "Verify Email" loop 4. API working via curl but not via browser 5. gRPC workers failing with connection refused 6. DNS working, but routing broken 7. Same server, but Docker ↔ Kubernetes networking failing --> What made it tricky Everything worked individually: ✔ Services running ✔ Pods healthy ✔ APIs responding But together: 🪢 Routing + cookies + auth + networking = chaos 🫣 💥 Key lessons learned 🤗 ✔ /api routing must explicitly go to backend (not frontend) ✔ Reverse proxy misrouting can look like auth failures ✔ Kubernetes NodePort vs port-forward → completely different behaviors ✔ Docker container “localhost” ≠ host machine ✔ host.docker.internal needs explicit mapping on Linux ✔ Browser cache can break Next.js Server Actions ✔ Resetting DB = losing tokens (hidden dependency!) ⚡ Final architecture that worked Domain → Caddy ├── / → Frontend (Docker) ├── /api → Backend (Docker) ├── /auth → Keycloak └── /hatchet → Kubernetes services Workers → Docker→ host.docker.internal → port-forward → Hatchet engine 🎯 Biggest takeaway Most “auth issues” are actually routing or networking issues in disguise. If you're working with: Docker + Kubernetes hybrid setups Reverse proxies (Caddy / Nginx) OAuth (Keycloak / NextAuth) gRPC services 🧐 Double-check networking before debugging application logic. 😎 This was frustrating — but honestly one of the best learning experiences I’ve had in DevOps. #DevOps #Kubernetes #Docker #Caddy #Keycloak #Debugging #SRE #AWS #Cloud #Jenkins

🚨 𝐌𝐲 𝐊𝐮𝐛𝐞𝐫𝐧𝐞𝐭𝐞𝐬 𝐩𝐨𝐝 𝐤𝐞𝐩𝐭 𝐫𝐞𝐬𝐭𝐚𝐫𝐭𝐢𝐧𝐠 𝐞𝐯𝐞𝐫𝐲 𝐟𝐞𝐰 𝐡𝐨𝐮𝐫𝐬… 𝐚𝐧𝐝 𝐈 𝐡𝐚𝐝 𝐧𝐨 𝐜𝐥𝐮𝐞 𝐰𝐡𝐲. No errors in the logs. No crash messages. Everything looked normal. Still… the pod kept disappearing. 𝐎𝐮𝐭 𝐨𝐟 𝐜𝐮𝐫𝐢𝐨𝐬𝐢𝐭𝐲, 𝐈 𝐫𝐚𝐧: kubectl describe pod <pod-name> And found the real reason: 💥 𝐎𝐎𝐌𝐊𝐢𝐥𝐥𝐞𝐝 (𝐄𝐱𝐢𝐭 𝐂𝐨𝐝𝐞 137) That’s when it hit me, the application wasn’t crashing… Kubernetes was killing it due to memory exhaustion. 𝐇𝐞𝐫𝐞’𝐬 𝐰𝐡𝐚𝐭 𝐈 𝐢𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐝 👇 1️⃣ 𝐍𝐨 𝐦𝐞𝐦𝐨𝐫𝐲 𝐥𝐢𝐦𝐢𝐭𝐬 𝐝𝐞𝐟𝐢𝐧𝐞𝐝 The pod was allowed to consume unlimited memory. Eventually, it exhausted the node’s memory and got terminated. 👉 𝐅𝐢𝐱: 𝐀𝐥𝐰𝐚𝐲𝐬 𝐝𝐞𝐟𝐢𝐧𝐞 𝐫𝐞𝐬𝐨𝐮𝐫𝐜𝐞 𝐫𝐞𝐪𝐮𝐞𝐬𝐭𝐬 𝐚𝐧𝐝 𝐥𝐢𝐦𝐢𝐭𝐬 𝘳𝘦𝘴𝘰𝘶𝘳𝘤𝘦𝘴:  𝘳𝘦𝘲𝘶𝘦𝘴𝘵𝘴:   𝘮𝘦𝘮𝘰𝘳𝘺: "256𝘔𝘪"  𝘭𝘪𝘮𝘪𝘵𝘴:   𝘮𝘦𝘮𝘰𝘳𝘺: "512𝘔𝘪" 2️⃣ 𝐉𝐕𝐌 𝐰𝐚𝐬 𝐧𝐨𝐭 𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫-𝐚𝐰𝐚𝐫𝐞 The Java application calculated heap size based on the node’s total memory, not the container limit. 👉 𝐅𝐢𝐱: 𝐓𝐮𝐧𝐞 𝐉𝐕𝐌 𝐟𝐨𝐫 𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫 𝐞𝐧𝐯𝐢𝐫𝐨𝐧𝐦𝐞𝐧𝐭𝐬 -𝘟𝘟:+𝘜𝘴𝘦𝘊𝘰𝘯𝘵𝘢𝘪𝘯𝘦𝘳𝘚𝘶𝘱𝘱𝘰𝘳𝘵 -𝘟𝘟:𝘔𝘢𝘹𝘙𝘈𝘔𝘗𝘦𝘳𝘤𝘦𝘯𝘵𝘢𝘨𝘦=75.0 3️⃣ 𝐌𝐞𝐦𝐨𝐫𝐲 𝐥𝐞𝐚𝐤 𝐢𝐧 𝐭𝐡𝐞 𝐚𝐩𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 Even after setting limits, memory usage kept increasing over time. Root cause: A background process was holding objects and not releasing them. 👉 Fix: Monitor memory trends using Prometheus and Grafana If memory steadily increases and doesn’t drop, it’s likely a memory leak. 💡 𝑲𝒆𝒚 𝒕𝒂𝒌𝒆𝒂𝒘𝒂𝒚𝒔: • Always define memory requests and limits • Make your application container-aware • Monitor trends, not just logs • OOMKilled = container terminated by the system, not an app crash This is one of the most common (and confusing) issues in Kubernetes. Have you faced something similar? 𝑾𝒐𝒖𝒍𝒅 𝒍𝒐𝒗𝒆 𝒕𝒐 𝒉𝒆𝒂𝒓 𝒉𝒐𝒘 𝒚𝒐𝒖 𝒅𝒆𝒃𝒖𝒈𝒈𝒆𝒅 𝒊𝒕 👇 #Kubernetes #DevOps #K8s #CloudNative #SRE #PlatformEngineering

🚀 Building a 3-Tier Kubernetes App I just deployed a full-stack application on Kubernetes to master containerization, orchestration, and real-world troubleshooting. What I Built: - Frontend (React + Nginx) - Backend (Node.js + Express) - Database (PostgreSQL) Users submit messages → stored in the database → displayed in the UI. Simple but powerful! 💪 The Tech Stack: Docker → Docker Hub → Kubernetes (Minikube) Key Learnings: ✅ Containerized each tier independently ✅ Configured Nginx reverse proxy for service-to-service communication ✅ Deployed with Kubernetes manifests for reproducibility ✅ Debugged real issues: service discovery, build errors, data persistence Want to try it? git clone https://lnkd.in/gxK49hKm cd project kubectl apply -f k8s/ minikube service frontend-service This project shows how DevOps practices bring multiple technologies together into a working system. Each challenge taught me something new about how containers and orchestration work in production. 🎯 Ready to build the next one! 🚀 #DevOps #Kubernetes #Docker #ContainerOrchestration #CloudNative #FullStack #Learning

Microservices sound great… until something breaks 😅 💡 Quick facts: A single user request can touch 5–10+ services One failure can create a chain reaction Logs > Code when debugging 🔍 🛠️ Debugging tricks I’ve learned: ✔️ Use correlation IDs to trace a request across services ✔️ Centralize logs (don’t chase logs in 10 terminals) ✔️ Add timeouts + retries (but avoid infinite retry loops!) ✔️ Monitor inter-service calls, not just APIs 👉 In microservices, debugging isn’t about where it failed… …it’s about where it started failing. #Microservices #Debugging #BackendDevelopment #SystemDesign #NodeJS #SoftwareEngineering