Autoblog writer
A hands-off blog engine for Next.js apps
I just shipped Agentic Workflows inside AutoBlogWriter.
This feels like a pretty important shift for the product.
AutoBlogWriter started as AI that writes blog posts. But I realized the real bottleneck was never the writing. It was everything around it.
Research. Structuring. Metadata. Images. Formatting. Publishing. Distribution.
That is not a single prompt. That is a workflow.
So now you can define actual content workflows that:
Research and generate long-form posts
Extract and structure metadata like title, description, OG tags, schema
Generate images
Format for Next.js, Shopify, or WordPress
Publish through authenticated endpoints
Trigger follow-up actions
Each workspace acts like its own site, with its own API key and webhook secret. Workflows run in isolation and operate independently.
The goal here is not to help you write slightly faster.
It is to remove the operational drag behind publishing altogether.
This moves AutoBlogWriter from being a writing tool to being a programmable content engine.
Still early. Still iterating. But this is the direction I am most excited about.
If you are experimenting with agentic systems or building autonomous workflows, I would genuinely love to hear how you are thinking about it.
AutoBlogWriter is a content engine for SaaS founders who are tired of duct-taping AI, workflows, and SEO together.
I built it because my own content setup kept breaking. I was using AI tools for writing, something else for images, n8n for automation, and manually wiring everything into my Next.js app. It worked, but it was fragile and needed constant babysitting.
AutoBlogWriter is my attempt to make content operational instead of chaotic.
You can:
Generate structured, publish-ready blog posts
Automatically create titles, meta descriptions, Open Graph fields, and sitemap-ready metadata
Schedule posts so publishing stays consistent
Use ready-made React components to render posts directly inside your Next.js app
Run multiple workspaces if you manage more than one product
The focus is not “AI writes blogs.”
It is about building a predictable content system that compounds over time and is actually hands off.
Still very early. Looking for founders who care about SEO and want something more structured than just another AI text box.
-
1Hi — your "content engine" post hit home: manually wiring AI writing + images + n8n + Next.js is exactly the friction that kills velocity. I build the "content multiplier" pattern: 1 input (topic/URL) → n8n orchestrator → 12+ formats (blog, LinkedIn, Twitter, newsletter, Reels, Shorts) → auto-post via APIs. Client went from 8h/post to 15 min. Live demo (BANT agent shows the orchestrator pattern): https://miguelabarca.app.n8n.cloud/webhook/bant-qualification 2-min Loom of the content pipeline: https://github.com/miguelangelabarcavaldivia/n8n-demo-assets/releases/download/loom-demo-v2/loom_final_auto.mp4 If you want to eliminate the manual wiring, I can send you the orchestrator workflow JSON + API integration docs via email. Reply here . Async only.
-
1
Strong angle! Moving from “AI text box” to an operational content system is a real shift.
A few security and integrity questions come to mind:
• When generating and storing posts across multiple workspaces, how are you enforcing isolation at the database level? Are you using strict workspace scoping with row-level policies so one tenant can never access another tenant’s drafts or metadata?
• Since posts are auto-generated with metadata and potentially auto-published, are you validating and sanitizing HTML output to prevent script injection or unsafe markup before rendering inside a Next.js app?
• For scheduling and automation, are publishing endpoints authenticated and rate-limited to prevent abuse?
If this becomes the content backbone for SaaS companies, integrity and isolation will be just as important as SEO performance. Making your data and rendering model explicit could increase trust significantly.
-
1
Really appreciate you raising this. If this is going to be the content backbone for SaaS teams, isolation and integrity can’t be an afterthought.
On workspace isolation:
Workspaces are effectively “websites” in the system. Every post, draft, image, and metadata object is strictly tied to a
workspaceId. All queries are scoped to that workspace, so there’s no cross-tenant access path at the application level.On top of that:
Each workspace has its own API key
Each workspace has its own webhook URL and secret
Publishing and automation always require workspace-scoped credentials
There’s no shared publishing surface across tenants.
On HTML validation and rendering:
We sanitize all HTML before it’s ever rendered. Even before that, we guard at the generation layer:
Strict output formatting requirements
Prompt-injection safeguards to prevent malicious instructions from being followed
Constrained response structures for metadata and content blocks
So we’re not just cleaning output after the fact, we’re reducing the risk during generation itself.
On publishing endpoints and abuse:
Publishing endpoints require both:
A valid API key
The correct webhook secret
Right now, rate limiting is focused primarily on AI endpoint abuse, but publishing is credential-gated per workspace. As the platform scales, more explicit rate limiting at the publishing layer is something I plan to formalize.
Totally agree with your broader point though: if this becomes core infrastructure, making the data model and isolation guarantees explicit will only increase trust. That’s a fair callout and something worth documenting publicly.
Appreciate the thoughtful push here.
-
1
Workspace scoped queries, separate API keys, and per workspace webhook secrets are strong controls at the application layer.
As you scale, a few things become important:
• Enforce isolation at the database level with row level security where possible
• Add explicit rate limiting on publishing endpoints, not only AI usage
• Monitor and alert on unusual cross workspace access attempts
• Rotate API keys and webhook secrets on a defined scheduleOn HTML handling, combining structured generation constraints with strict sanitization before rendering inside Next.js is the right approach. Reducing risk at generation time lowers exposure later.
As a security team building Nautillo Pro, we focus on the same principles. Clear isolation. Strict boundaries. Continuous validation from an external attacker perspective.
If you want to see how your own platform behaves under black box testing, Nautillo Pro has a free version available.
-
-
1
Congratulations on your launch. It looks impressive! What channels are you exploring to attract early users?
Comment