I Built a Local AI Content Automation System Without OpenAI APIs (Part -1)

Over the past year, AI workflow automation has exploded in popularity. Everywhere I looked, developers were building AI agents that could summarize content, generate social media posts, automate customer support, or orchestrate entire business workflows using tools like LangChain, OpenAI APIs, Zapier, and Make.com.

But almost every implementation I came across had three common characteristics:

  • It depended heavily on cloud-hosted AI APIs
  • It introduced recurring API costs
  • It sent all inference requests to third-party services

That made me curious:

Could I build a fully local AI-powered automation pipeline capable of generating social media content without relying on OpenAI APIs?

I decided to attempt exactly that.

The goal was surprisingly practical:

  • Read content automatically from RSS feeds
  • Generate AI-based Instagram captions and X (Twitter) posts
  • Review the generated drafts manually before posting
  • Run everything locally on my Windows laptop
  • Avoid cloud inference costs entirely

Instead of building a simple chatbot, I wanted to explore something much closer to a real-world AI orchestration workflow — combining:

  • local LLM inference
  • workflow automation
  • containerization
  • human approval systems
  • messaging integrations
  • lightweight DevOps concepts

The final result became a surprisingly capable AI-powered social media automation system running entirely on my local machine using:

  • Ollama
  • n8n
  • Docker
  • WSL Ubuntu
  • Telegram Bots
  • RSS feeds
  • local LLM inference

Most importantly, the system introduced a “human-in-the-loop” approval model instead of blindly auto-posting AI-generated content directly to social media platforms.

That architectural decision ended up becoming one of the most important lessons of the project.

What the Final System Does

At a high level, the workflow looks like this:

RSS Feed --> n8n Workflow --> Ollama Local LLM --> AI-generated Instagram + X content --> Telegram approval message  --> Manual social media posting
  	 	 	 	  
The workflow periodically reads content from RSS feeds, extracts article summaries, sends them to a locally running Large Language Model through Ollama, generates platform-specific social media drafts, and then sends the generated output directly to Telegram for human review.
The Telegram step is extremely important.
	 	  
Instead of allowing the AI to auto-post directly to Instagram or X, the workflow intentionally pauses at the approval stage. This ensures: 	
  • hallucinated content can be caught
    •  	
  • hashtags can be refined
    •  	
  • brand tone can be reviewed
    •  	
  • sensitive topics can be moderated manually
    •  
    In other words, the AI assists the workflow — but does not fully control it.

Why I Chose Local AI Instead of OpenAI APIs

One of the biggest motivations behind this project was understanding whether modern AI workflows could run locally on commodity hardware without becoming impractical.

There were several reasons I wanted to avoid cloud APIs initially:

1. Cost Control

Even relatively small AI workflows can become expensive once:

  • requests scale
  • automation frequency increases
  • multiple agents are introduced

Local inference removes per-request pricing completely.

2. Privacy

Using local models means:

  • prompts stay on-device
  • article processing remains private
  • no third-party inference provider receives workflow data

This becomes especially important for:

  • internal automation
  • enterprise workflows
  • educational environments
  • research systems

3. Educational Value

I specifically wanted to understand:

  • local LLM deployment
  • inference pipelines
  • orchestration challenges
  • AI infrastructure concepts

Working with local AI forces you to think about:

  • memory constraints
  • networking
  • streaming responses
  • deployment architecture
  • workflow stability

Those are extremely valuable engineering lessons.

The Core Technologies Behind the Workflow

The entire MVP was built using open-source or free technologies.

Ollama

Ollama was used to run Large Language Models locally on Windows. It exposes a lightweight REST API that made integration with n8n surprisingly clean.

For this project, I eventually settled on:

qwen2.5:3b
after experimenting with larger models that exhausted available RAM.
  	 	 	 	  
n8n
n8n became the orchestration engine of the entire system.
It handled:	
  • RSS ingestion
    •  	
  • HTTP API calls
    •  	
  • workflow sequencing
    •  	
  • scheduling
    •  	
  • Telegram integration
What makes n8n particularly interesting is how approachable it makes AI orchestration for beginners while still being powerful enough for production-style workflows.

Docker + WSL Ubuntu 
Instead of deploying everything directly on Windows, I used:    
  • Docker Desktop  	 
  • WSL Ubuntu  	 
  • containerized n8n deployment   
This introduced several DevOps concepts into the project:	  
  • containerization  	 
  • Linux environments  	 
  • networking  	 
  • volume management  	 
  • service orchestration 
Ironically, some of the most valuable lessons from the project came not from AI itself, but from debugging infrastructure and networking issues between Windows and Linux environments.
Telegram Bots
Initially, I attempted an SMTP/Gmail approval workflow.  
That quickly became painful due to:    	 
  • Gmail App Password restrictions  	 
  • STARTTLS issues  	 
  • SMTP inconsistencies   
Eventually, I replaced email approvals entirely with Telegram Bots. That decision dramatically simplified the architecture and improved reliability. In retrospect, Telegram was probably the ideal approval layer for this kind of workflow from the beginning.

The Most Interesting Part Wasn’t the AI

Ironically, the hardest part of the project wasn’t generating AI content.

It was making all the components work together reliably.

The project introduced challenges involving:

  • Docker permissions
  • WSL networking
  • Ollama API streaming
  • JSON parsing
  • model memory limits
  • workflow stability
  • infrastructure troubleshooting

At one point, even a simple localhost connection became a debugging rabbit hole because Ollama was running on Windows while n8n lived inside WSL Ubuntu.

That separation created subtle networking behavior that many beginner tutorials never discuss.

And honestly, that made the project far more educational.

The Final MVP

After multiple iterations, architecture changes, and debugging sessions, the final MVP successfully achieved:

  • RSS-based content ingestion
  • Local AI-generated social media drafts
  • Telegram-based approval workflow
  • Human moderation before publishing
  • Fully local AI inference
  • Dockerized deployment
  • Zero OpenAI API dependency

And perhaps most importantly:

The entire system runs on a standard Windows laptop.

In the next section, I’ll walk through the infrastructure setup process — including WSL Ubuntu, Docker Desktop, Ollama installation, and deploying n8n inside containers.

Code Verse

© Copyright 2025 Code Verse

 Terms & Condition | Refund Policy 

Privacy Policy