DEV Community: Mohamed El-

I Locked Myself Out of My Own Server — Here's What I Learned

Mohamed El- — Thu, 14 May 2026 04:34:58 +0000

A solo builder's post-mortem on over-engineering cloud security, losing everything, and rebuilding the right way.

There's a specific kind of silence that hits when you realize the command you just ran worked perfectly — and destroyed everything in the process.

That was me, staring at a terminal that had no response. No SSH prompt. No connection. Just... nothing. My VM was running. My n8n instance was technically alive. But I had sealed it so tightly that not even I could get in anymore. Not even Gemini Cloud Assist — the AI I was relying on to help me navigate GCP — could reach it.

The only path forward? Hit the Project Delete button and start over.

This is that story.

The Heartbreak of "I Was Trying to Be Secure"

I wasn't being reckless. I was being careful — or so I thought.

I had a public-facing Ubuntu VM running n8n, and I knew enough to be worried about it. Open ports. Bot scans. The usual internet noise. So I did what seemed logical: I started locking things down. Removed the external IP. Tightened the firewall rules. Stripped away anything that felt like unnecessary exposure.

What I didn't account for was that I had also stripped away my own access path. No external IP meant no standard SSH. The firewall rules I'd tightened had quietly cut off 35.235.240.0/20 — the IP range Google uses for Identity-Aware Proxy, which is the very backbone of GCP's secure management tunnel. Without it, Gemini Cloud Assist couldn't see my instance. I couldn't SSH in. I was locked outside a door I had just welded shut from the inside.

I spent an hour trying everything. Nothing worked. So I deleted the project, took a breath, and asked myself the only useful question in that moment:

What does "doing this right" actually look like?

The Post-Mortem: What I Did Wrong

Looking back, the failure had one root cause: I tried to harden a bad architecture instead of starting with a good one.

The original setup had a public IP by default — that's the GCP standard. And instead of rethinking that decision from the ground up, I tried to bolt security on top of it after the fact. I removed the public IP mid-flight without first establishing an alternative management path. I closed firewall ports without understanding which ones Google's own tooling needed to stay open.

The lesson isn't "don't be too secure." The lesson is: security has to be designed in, not added on. Retrofitting is where the lockouts happen.

The Rebuild: A "Private First" Architecture

The second time around, I flipped the entire mental model.

Instead of starting with a public VM and removing access, I started with a private VM and added only the access I needed. The machine — an e2-medium on Ubuntu 24.04 LTS — was provisioned with no external IP address from the very first click. It is, by design, invisible to the public internet. No address means no surface. No surface means no bot scans, no brute force attempts, no port knocking. Nothing.

But a private VM still needs to talk to the outside world — to pull Docker images, receive package updates, and run workflows that hit external APIs. That's where Cloud NAT comes in. Paired with a Cloud Router, it gives the VM outbound internet access without exposing any inbound surface. The VM can reach the internet; the internet cannot reach the VM.

For administration — SSH, file transfers, running gcloud commands — I used Identity-Aware Proxy (IAP). Instead of opening Port 22 to the world, I opened it exclusively to 35.235.240.0/20, which is Google's IAP tunnel range. This means every SSH session is authenticated through Google's identity layer before a single packet reaches my VM. The command looks like this:

gcloud compute ssh --tunnel-through-iap <instance-name>

Simple. Audited. No public port.

And for the n8n dashboard itself — the UI I actually use to build workflows — I set up Tailscale. Tailscale creates a private mesh network between my devices using WireGuard under the hood. My VM gets a stable Tailscale IP, and I connect to the dashboard at http://<tailscale-ip>:5678 from any device on my Tailscale network. No SSL certificate configuration needed, no reverse proxy, no public DNS entry. Just a VPN tunnel that works.

The Security Stack:

No External IP → Zero public attack surface

Cloud NAT → Outbound-only internet access

IAP on Port 22 → Google-authenticated SSH, no open port

Tailscale → Private dashboard access via mesh VPN

The Small Fixes That Saved the Setup

Two things tripped me up during the Docker setup that are worth documenting, because they're the kind of issues that don't show up in tutorials.

Volume Permissions. The n8n container was crash-looping on startup. The culprit was ownership on the ~/.n8n directory — Docker's internal n8n user expects 1000:1000 ownership, and it wasn't getting it. One chown command fixed it:

sudo chown -R 1000:1000 ~/.n8n

The Secure Cookie Flag. By default, n8n sets N8N_SECURE_COOKIE=true, which means it will only accept the session cookie over HTTPS. Since my Tailscale access is over HTTP (a private IP, no cert), this caused silent login failures. Setting N8N_SECURE_COOKIE=false in the Docker environment resolved it without opening any real security risk — you're on a private VPN, not the public internet.

These are exactly the kinds of subtle issues where Gemini Cloud Assist earned its keep. Describing the crash loop in natural language and getting back the precise diagnosis — volume permissions, not a misconfiguration — saved me from an hour of Docker log archaeology.

Why Every Developer Running Automation Should Consider This

If you're self-hosting anything — n8n, Zapier alternatives, AI pipelines, bots — and you have a public IP on that machine, you are being scanned right now. Not maybe. Now.

The "Private First" architecture isn't just for enterprises with security teams. It's practical for solo builders. It costs the same on GCP (an e2-medium sits comfortably within the $300 free credit tier). It takes maybe 30 extra minutes to set up compared to a standard public VM. And it gives you something that's genuinely hard to buy with money: the ability to stop thinking about your infrastructure's attack surface.

You can focus on what you're actually building.

The Outcome

My n8n instance now runs on a machine that doesn't exist, as far as the internet is concerned. No public presence. No bot noise in the logs. No anxiety about exposed ports. Gemini Cloud Assist has full visibility through IAP. My workflows run 24/7 — Apify lead pulls, AI processing, email drafts, WhatsApp messages — and I access the dashboard from my laptop over Tailscale like it's a local app.

Fort Knox style, as I like to call it. But it took destroying the first fort to build it properly.

If you're setting up a self-hosted automation stack and want to avoid the project-delete moment — feel free to reach out. The setup is simpler than it looks once you understand the architecture.

Tags: #n8n #GoogleCloud #DevOps #CloudSecurity #Automation #SoloFounder #SelfHosted #Tailscale #BuildInPublic

Building an AI-Powered Lead Gen Workflow with n8n, Apify, and Gemini

Mohamed El- — Fri, 10 Oct 2025 17:48:19 +0000

I spent a weekend building a fun proof-of-concept: a fully automated workflow that scrapes leads from Google Maps, uses an AI to score and personalize messages for them, and then saves it all to a spreadsheet.
Here’s a technical breakdown of the stack and the workflow I built in n8n.

The Data Flow

The logic is pretty linear: Scrape -> Normalize -> Enrich with AI -> Parse -> Format -> Store.

Apify for Scraping: The workflow kicks off with an HTTP Request to an Apify actor. Nothing too complex, just a POST request with my search queries in the JSON body. The free tier gave me enough credits to pull a few hundred records for testing.
AI Agent with Gemini: The core of the workflow is the n8n AI Agent node connected to the Google Gemini API. The prompt engineering was key here. I gave it a detailed system prompt defining its role, the input data structure, and—most importantly—the exact JSON format I needed for the output. This included fields for an outreach_score and a communication object with an email and WhatsApp message.
The Gotcha: Parsing AI Output: As many of you know, getting consistently clean JSON from an LLM can be a challenge. The Gemini model would often wrap its valid JSON in a `json markdown block. My first attempts with a simple JSON.parse() failed.

The fix was an "Edit Fields" node running a bit of JavaScript to clean the string before parsing:
`javascript JSON.parse(rawOutput.replace(/^`json\n/, '').replace(/\n`$/, '')) `
A simple solution, but it made the workflow 100x more reliable.
Humanizing the Date: Another small but important transformation. The scrapedAt timestamp was in ISO 8601 format (...Z). I used n8n's built-in Luxon library within an expression to format it for the spreadsheet:
`javascript DateTime.fromISO($json.scrapedAt...).toFormat('dd MMMM yyyy, HH:mm') `
This is way cleaner than handling new Date() objects in a full Code node.
Append to Sheet: The final step is a simple Google Sheets "Append" node that maps the flattened JSON object to the correct columns.

This was a great way to see how powerful the new AI nodes in n8n are. The ability to call an LLM as a simple, integrated step in a workflow, just like any other API, is a total game-changer. Next up, I'll be adding nodes to actually send the outreach.

Anyone else building cool stuff with AI agents in their workflows?

Automating My Pinterest Content Pipeline with n8n + AI (Free Setup)

Mohamed El- — Fri, 03 Oct 2025 21:00:14 +0000

Automating My Pinterest Content Pipeline with n8n + AI (Free Setup)

I was spending way too much time digging for content on Pinterest, so I decided to automate the process.

With a bit of tinkering in n8n, I ended up building a workflow that turns viral TikToks into Pinterest-ready pins — completely free to run.

⚡ What the workflow does

I just send a keyword like healthy recipes, 10, and the workflow:

Searches TikTok using Apify
Filters results for high engagement (1M+ views, 1K+ shares, 20–60 sec)
Downloads the top 3 videos (without watermarks — tricky part 😅)
Uploads them to Google Drive
Generates Pinterest titles & descriptions with a free LLM (DeepSeek via OpenRouter)
Logs everything in a Google Sheet with status = Pending for review

💡 Why it matters

Saves hours of manual searching
Runs on free tiers:
- n8n (self-hosted)
- Apify free credits
- OpenRouter free tier
- Google Drive + Sheets

And because I still review before posting, Pinterest doesn’t flag low-quality content.

🛠️ Challenges I ran into

Getting AI to output clean JSON (regex gymnastics to strip markdown)
TikTok CDN requires Referer headers or it throws 403 errors
Deduplication to avoid grabbing the same video twice

✅ Final thoughts

This workflow is lightweight, flexible, and basically zero-cost.

It also reminded me how powerful tools like n8n can be for automating entire content pipelines with just APIs + logic.

💬 Would you like me to share the full workflow JSON in another post?

8 N8N Fundamentals That Will Make You Build Workflows Like a Pro

Mohamed El- — Sun, 28 Sep 2025 17:27:15 +0000

6 Months of Client Work Condensed into Essential Principles

After six months of building AI automation workflows for paying clients, I’ve learned some hard truths about what separates beginners from pros.

Most tutorials teach you what individual nodes do. They show you where to click. But they never talk about the mindset and principles that allow you to build complex, reliable automations independently.

I’ve condensed my most valuable lessons — the ones that stop workflows from turning into “spaghetti monsters” and save you hundreds of dollars in testing fees — into 8 core fundamentals.

Part I: The Pre-Build Phase (Foundation First)

A professional workflow is planned, not stumbled upon. Master these two principles before you ever open the n8n canvas.

1. Use Case First, Workflow Second

This is the biggest mistake I see beginners make.

What Amateurs Do:

Open n8n, stare at a blank canvas, get overwhelmed by the node options, and give up.

What Pros Do:

Start with the problem, not the tool. The workflow must bend to fit your use case, not the other way around.

✅ My 4-Step Professional Process:

Write the business problem in plain English.
Define the exact input (e.g. new row in Google Sheet) and desired output (e.g. formatted Slack message).
Break the process into 3–5 high-level logical steps.
Then worry about which nodes to use.

💡 Real Example:

Instead of “I want to build an AI workflow,” try:

“I need to automatically categorize incoming customer support emails and route urgent, high-value ones to my phone via SMS.”

2. Don’t Reinvent the Wheel (Template Hunting is a Core Skill)

Starting from scratch each time is slow and error-prone.

What Amateurs Do:

Start from scratch every single time.

What Pros Do:

Always search for existing templates first.

🔍 My Template Hunting Process:

Search n8n’s community templates (official library)
Browse Reddit (r/n8n, r/automation, r/aiagents)
Watch YouTube use-case videos
Search X / Twitter with #n8n

This helps you:

Build faster starting from reliable bases
Discover powerful nodes you didn’t know
Learn from other people’s mistakes

Part II: The Build Phase (The Core Skills)

This is where you execute the plan. Professional builders have a streamlined process for data handling and testing.

3. Master the Data Flow Principle

Every n8n workflow essentially follows:

Input → Transform → Output

If you can track data through these three stages, you can build anything.

🔑 Primary Data Sources (used ≈ 90%):

Your own databases (Airtable, Google Sheets, Supabase)
Public APIs (HTTP Request node or dedicated nodes)

Where many beginners struggle: the HTTP Request node.

💡 The Secret Weapon: Postman

Most advanced users use Postman—even though it’s external to n8n.

🚀 My API Testing Process:

Copy the cURL from API docs.
Import into Postman; test with real parameters.
Ensure it works perfectly.
Only then port the working request into your n8n HTTP Request node.

This ensures your workflow logic isn’t blocked by an incorrect request.

4. The 6 Nodes That Handle 80% of Your Work

After over 100 client workflows, I found that mastery of a few nodes covers most needs:

Data Shaping → Set / Edit Fields — extract, rename, convert data types
Data Cleaning → Filter — drop invalid rows (nulls, duplicates, empties)
Data Integration → Merge — combine datasets or enrich with extra fields
Logic → IF — basic conditional branching
The Emergency Button → Code — for very specific transformations
AI Processing → Basic LLM Chain / AI Agent — handles ~90% of AI tasks

💡 Code Node Hack:

Don’t code it yourself—describe input & output to ChatGPT. This trick carried me through my first three months of client work.

5. Pin Your Node Output (Save Real Money & Time)

This is a pro technique that separates novices from efficient builders.

What Beginners Do:

Re-run the whole, expensive workflow every time they change one node.

What Pros Do:

Run once, pin the output, and reuse it for downstream testing.

✅ How to Pin Like a Pro:

Run the workflow once to get real data in every node.
Click the “pin” icon on an upstream node’s output (e.g. HTTP or AI nodes).
Edit pinned data to simulate edge cases.
Test downstream nodes without invoking API again.

💸 Why It Matters:

One AI node test can cost $0.10+ if rerun each time. Across projects, that’s real money. Don’t re-pay for what’s already computed.

Part III: The Post-Build Phase (Professional Polish)

The difference between a hobbyist and production-grade system is how you handle complexity, errors, and cost.

6. Create Sub-Workflows (Keep It Clean)

Before, my workflows turned into spaghetti with 50+ nodes. Debugging was a nightmare.

Now: Main workflows stay simple (4–6 nodes). Everything else is abstracted into sub-workflows.

🔧 Puzzle Piece Principle:

Each sub-workflow is a reusable, isolated component.

Create a Components folder in n8n
Build reusable sub-workflows (error handling, notifications, data cleaning)
Invoke them from your main workflow

✅ Debugging Benefit:

If something breaks, you immediately isolate which component failed.

7. Implement Error Logging (Be the First to Know)

Amateurs wait for complaints. Professionals get alerted with full context before users notice.

What Amateurs Do:

Hope workflows never fail.

What Pros Do:

Log failures (and successes), and notify immediately.

📊 What My Error System Logs:

What went wrong (error message)
Where it failed (node name, execution ID)
Input data that triggered the error
Automatic retry attempts

💡 Pro Tip:

Also log successful runs. Clients like seeing:

“Your automation processed 47 new leads today.”

8. Track Your AI Costs (Avoid Bill Shock)

Worst case: your AI agent runs wild and charges $500 overnight. Trust evaporates.

✅ Solution: Use n8n’s built-in cost tracking in every AI node.

📊 I Always Track:

Tokens used per run
Cost per execution
Daily/monthly spending limits
Model performance metrics

In proposals, I include a cost breakdown. Surprises kill trust. Own the budget from day one.

Final Thoughts

Mastering these eight fundamentals will put you ahead of 90% of people trying to piece things together by trial and error.

The secret to building like a pro isn’t a flashy node—it’s planning, discipline, and smart testing.

Now, go build something great. 🚀