Make (formerly Integromat) is a cloud-based visual automation platform — similar to Zapier but with more powerful data transformation capabilities and a better visual workflow builder. While Make runs in the cloud and its scenarios execute on Make’s servers, it can call local services via webhooks, and with a bit of network configuration it can reach your local Ollama instance. This guide covers how to connect Make to Ollama, what workflows make sense for this combination, and the practical considerations around calling a local model from a cloud automation tool.
The Architecture: Cloud Automation Meets Local AI
Make’s scenarios run on Make’s servers, which means they can’t reach localhost:11434 directly — your Ollama instance isn’t publicly accessible. To connect them, you have two options: expose Ollama via a tunneling tool like ngrok or Cloudflare Tunnel, or deploy Ollama on a server with a public IP (a VPS, cloud VM, or home server with port forwarding). Each approach has different trade-offs.
ngrok tunnel (easiest for development): Install ngrok, run ngrok http 11434, and you get a public HTTPS URL that forwards to your local Ollama. Make can call this URL. The free tier of ngrok changes the URL each time you restart the tunnel — use a paid ngrok plan or a static tunnel for production.
Cloudflare Tunnel (better for persistent use): Cloudflare Tunnel (formerly Argo Tunnel) creates a persistent, secure tunnel from your local machine to Cloudflare’s network without opening ports. More setup but gives you a stable URL and better security than ngrok’s free tier.
VPS deployment: Run Ollama on a cloud VM (Hetzner, DigitalOcean, Linode) with a public IP and configure Make to call it directly. Cleaner architecture, more reliable, but costs money and requires managing a server. Good for production workflows where reliability matters.
For personal experimentation, ngrok is the fastest way to get started. For anything production, either Cloudflare Tunnel or a VPS deployment is more appropriate.
Calling Ollama from Make: The HTTP Module
Make’s HTTP module makes arbitrary HTTP requests — this is how you call Ollama’s REST API. Add an HTTP Make a request module to your scenario and configure it:
- URL:
https://your-ngrok-url.ngrok.io/api/chat(or your Cloudflare/VPS URL) - Method: POST
- Headers: Content-Type: application/json
- Body type: Raw
- Content type: JSON (application/json)
The request body for a chat call:
{
"model": "llama3.2",
"messages": [
{
"role": "system",
"content": "You are a helpful assistant. Be concise."
},
{
"role": "user",
"content": "{{1.text}}"
}
],
"stream": false
}The {{1.text}} is Make’s expression syntax — replace this with whatever field from your trigger or previous module contains your prompt content. Set stream: false so Make gets the complete response rather than a stream of chunks it can’t handle natively.
Map the response: the Ollama API returns a JSON object where the generated text is at message.content. In Make’s output mapping, use {{http.data.message.content}} to extract the text from the response.
Practical Make + Ollama Scenarios
Email summarisation: Trigger on new Gmail/Outlook email, extract the body, call Ollama to summarise and classify (urgent/not urgent, action required/FYI), and add a label or save to a Notion database. All email content stays on your machine (via the Ollama call); only the summary touches Make’s servers.
Content repurposing: Trigger when a new blog post or article is added to an Airtable or Google Sheet, call Ollama to generate social media variations (Twitter thread, LinkedIn post, newsletter snippet), and save outputs back to the sheet or post directly via social media integrations.
Customer feedback analysis: When a new form submission arrives (Typeform, Google Forms), call Ollama to extract sentiment, key themes, and suggested response, then route to appropriate team members or ticket systems based on the classification.
Document processing: When a PDF is uploaded to Google Drive, extract text with Make’s built-in parsers, send to Ollama for summarisation or data extraction, and save structured output to a database.
Figure 1 — Make + Ollama: Connection Architecture
Setting Up Secure Access with ngrok
For development and testing, ngrok is the fastest path. Install ngrok (available at ngrok.com), authenticate with your account key, then expose your Ollama port:
ngrok http 11434ngrok prints a public HTTPS URL like https://abc123.ngrok.io. Use this as your base URL in Make’s HTTP module: https://abc123.ngrok.io/api/chat. The tunnel stays active as long as the ngrok process runs.
One important security consideration: a public ngrok URL is accessible to anyone who knows it. Don’t expose an Ollama instance with ngrok without authentication, especially on a shared or work network. Add a simple header-based auth to your Ollama endpoint, or use ngrok’s IP allowlist feature (paid plan) to restrict access to Make’s IP ranges only. Alternatively, use the ngrok webhook verification to confirm requests come from Make before passing them to Ollama.
For Cloudflare Tunnel, install cloudflared, authenticate with your Cloudflare account, and create a tunnel pointing to localhost:11434. You get a stable URL under your own domain that persists across restarts — much better than ngrok’s free tier for anything you plan to use regularly.
Error Handling in Make Scenarios
Make’s error handling system is more powerful than most users realise, and it’s important to use it for Ollama calls since the model can timeout, the tunnel can drop, or Ollama can return errors. Add an error handler route to your HTTP module (right-click the module → Add error handler). For transient errors (timeouts, 503 responses), use the Retry directive to retry up to 3 times with a delay. For persistent failures, route to an error logging module (save to a Google Sheet or send a Slack message) so you know when the integration breaks.
Also set a generous timeout on your HTTP module — Ollama generation can take 10–30 seconds for longer responses on slower hardware. Make’s default HTTP timeout may be shorter than this; check the module’s Advanced settings and increase the timeout to at least 60 seconds to avoid premature failures on longer generations.
Make vs n8n for Ollama Workflows
The direct comparison: Make is polished, has 1,500+ pre-built integrations with cloud services, and requires no self-hosting or infrastructure management. n8n is self-hosted (so all data stays on your infrastructure), open source, and integrates with Ollama natively without the tunnel complexity. For workflows involving sensitive data, n8n is clearly better — the data never leaves your control. For workflows where data sensitivity isn’t a concern and you want access to Make’s broad integration library (Airtable, Monday.com, HubSpot, Salesforce, hundreds of others), Make is more practical. The tunnel requirement is the main friction point for Make + Ollama — if you find yourself fighting with ngrok reliability or Cloudflare Tunnel configuration, switching to n8n + Ollama (where both run locally) eliminates that complexity entirely while gaining native Ollama support. Many users start with Make + Ollama because they already use Make, then migrate specific AI-heavy workflows to n8n as the local-first approach proves its value. Both are valid; the choice depends on your existing tooling and data requirements.
Figure 2 — Make vs n8n for Local AI Workflows
Getting the Most from Make + Ollama
A few practices make Make + Ollama workflows more reliable and useful. Keep your prompts focused and specific — Make scenarios often process many items in a loop, and vague prompts produce inconsistent outputs that are hard to use downstream. Include output format instructions in your system prompt: “Return your response as JSON with fields: summary (string), sentiment (positive/negative/neutral), action_required (boolean).” This makes the model’s output directly parsable by Make’s JSON parsing modules without additional transformation steps. Test your scenario thoroughly with edge cases before enabling it for production data — email bodies, form submissions, and document content vary enormously, and a prompt that works for 90% of inputs can fail badly on the remaining 10%. Build in a fallback path (save the original content alongside the AI output, or flag outputs below a confidence threshold for human review) so failures are visible and recoverable. With these patterns in place, Make + Ollama becomes a powerful combination for AI-augmented automation even with the tunnel overhead it requires.
Choosing the Right Model for Make Workflows
Since Make scenarios run asynchronously and the user isn’t waiting in real time, you can afford to use a larger, slower model than you might for interactive use. A 13–14B model that takes 20 seconds to generate a thorough analysis is perfectly acceptable in an automation workflow that runs in the background — the extra quality is worth the extra latency when no human is watching a loading spinner. Qwen 2.5 14B, Mistral Small 3 24B, or Phi-4 are all good choices for Make workflows where quality matters more than speed. Reserve smaller, faster models for workflows processing very high volumes where per-item latency multiplied across thousands of items makes the total runtime impractical. The structured output discipline is also worth reinforcing here: asking a 14B model to return clean JSON reliably is much easier than asking a 3B model to do the same, and structured output is what makes automation workflows actually useful — the difference between output you can parse and route programmatically versus text you have to handle manually is the difference between a working automation and one that requires constant human intervention.