It’s the most common question we hear from business owners. Not “how do I set up n8n” or “which LLM should I run” — those are the fun problems. The hard part is figuring out which of the hundred things your team does every day is worth automating first. Pick the wrong process and you’ll spend weeks building something that saves nine minutes a month. Pick the right one and you’ll free up a full role’s worth of capacity.

The answer isn’t to buy a tool and look for problems to solve with it. The answer is to audit your processes first, then automate what actually matters. Here’s how to do that systematically, without consultants, without software, and without any prior technical knowledge.

Why You Need an Audit Before You Need Tools

Most automation projects fail for the same reason: someone picks a tool, finds a process that seems automatable, builds a workflow, and discovers three months later that nobody is using it. The workflow works technically, but it solved a problem that wasn’t really a problem — or it created new problems that were worse than the original.

An audit prevents this. It forces you to:

• See your actual workflows — not what you think happens, but what actually happens when your team does the work
• Rank by impact — so you automate the process that saves the most hours first, not the one that’s most technically interesting
• Understand the exceptions — every process has edge cases that make automation tricky, and you need to know those before you build
• Get team buy-in — when people see their work being analyzed respectfully (not judged), they participate honestly and support the changes

The audit takes one to two weeks of part-time effort. It costs nothing. And it determines whether your automation initiative succeeds or becomes shelfware.

Step 1: Inventory What Your Team Actually Does

Start by listing every recurring task your team performs. Not job descriptions — actual tasks. The granular things people do during a typical week.

Send a simple spreadsheet to each team member with four columns:

Ask them to be honest and specific. “Manage customers” is not a task. “Copy customer info from email intake form into CRM and send welcome email” is a task. The more granular, the more useful the audit.

Give them one week. Don’t rush it. You want the real list, not the list people think you want to see.

Tip: Ask people to log tasks as they do them rather than trying to remember everything at the end of the week. Memory is unreliable — people forget the small, frequent tasks that are often the best automation candidates.

Step 2: Score Each Task on Three Dimensions

Once you have the inventory, score every task on three factors. Use a simple 1–5 scale for each.

Frequency (1–5)

How often does this task happen?

• 1 = Once a month or less
• 2 = A few times a month
• 3 = Weekly
• 4 = Daily
• 5 = Multiple times per day

Frequency matters because automation pays off through repetition. A task that takes 10 minutes but happens 20 times a day costs 33 hours per week. Automating it saves more than an entire full-time role. A task that takes 2 hours but happens once a month saves 24 hours per year — nice, but not a priority.

Time Per Occurrence (1–5)

How long does each instance take?

• 1 = Under 5 minutes
• 2 = 5–15 minutes
• 3 = 15–30 minutes
• 4 = 30–60 minutes
• 5 = Over 1 hour

This is straightforward: longer tasks mean more time saved per automation.

Automatability (1–5)

This is the one that requires judgment. How feasible is it to automate this task with current tools? Score it based on these signals:

• 5 — Highly automatable: The task follows the same steps every time, moves data between software systems, requires no human judgment, and has clear inputs and outputs. Example: copying data from an email attachment into a spreadsheet and emailing it to three people.
• 4 — Mostly automatable: The task is mostly rule-based but has a small judgment component that could be handled by an AI model. Example: sorting incoming emails into categories and drafting a response for human review.
• 3 — Partially automatable: Parts of the task can be automated, but a human needs to stay involved for key decisions. Example: reviewing expense reports — AI can flag anomalies and pre-fill categories, but a human approves.
• 2 — Mostly manual: The task requires significant human judgment, creativity, or relationship-building. Automation could help with peripheral tasks but not the core. Example: negotiating a vendor contract.
• 1 — Not automatable: The task is inherently human. Example: delivering bad news to an employee, building trust with a new client.

Be honest about this score. The temptation is to mark everything as a 4 or 5 because you want to automate it. But tasks that involve nuanced judgment, emotional intelligence, or complex physical interaction are poor automation candidates — and trying to force them will waste your time and frustrate your team.

Calculate the Priority Score

Multiply the three scores together:

Priority Score = Frequency × Time × Automatability

The maximum possible score is 125 (5 × 5 × 5). The minimum is 1. Sort your task list by priority score, highest to lowest.

Here’s what your scored list might look like:

The scores tell a clear story. Customer intake processing and inventory reports are your top priorities. Vendor negotiation and board presentations are at the bottom — and they should be. No amount of AI automation replaces the human judgment in negotiating a contract or presenting to your board.

Step 3: Map the Top 5 Processes in Detail

Take the five highest-scoring tasks and map them step by step. For each one, document:

1. Trigger — What starts this process? An email arriving? A time of day? A form submission?
2. Inputs — What data or materials does the process need? Where do they come from?
3. Steps — Every individual action, in order. “Open email. Download attachment. Open spreadsheet. Copy column A into column B. Save. Email to Sarah.”
4. Decision points — Where does the person make a judgment call? What are they deciding?
5. Outputs — What does the process produce? Where does it go?
6. Exceptions — What happens when something doesn’t fit the normal flow? How often do exceptions occur?
7. Time breakdown — How long does each step take? (This often reveals that one step dominates the total time.)

Do this by sitting with the person who actually does the work. Watch them do it. Ask questions. Take notes. Don’t rely on documentation — if written procedures exist, they’re almost certainly outdated or incomplete compared to what people actually do.

The goal here is to understand the process well enough to answer one question: Could a software workflow handle steps 1–7 without human intervention, or with minimal human review?

You’ll often discover that what seemed like a single task is actually three tasks bundled together — some automatable, some not. Unbundling them lets you automate the automatable parts and leave the rest to humans.

Step 4: Identify the Exceptions (and Decide Whether They Matter)

Exceptions are where automation projects die. Here’s why: you build a workflow that handles 90% of cases perfectly. Then an unusual case comes in, the workflow fails, and someone has to clean up the mess. If exceptions happen often enough, the cleanup time exceeds the time the automation saved — and you’re worse off than before.

During your process mapping, pay close attention to how often exceptions occur and how they’re handled. Ask:

• What percentage of cases are “normal” vs. exceptional?
• How much extra time does an exception take compared to a normal case?
• Could the exceptions be caught automatically and routed to a human, while the normal cases flow through automation?

A practical rule: if exceptions are less than 10% of cases, you can automate the normal flow and route exceptions to a human. If exceptions are 30% or more, the process isn’t ready for automation — fix the process first (standardize the inputs, create templates, remove the conditions that cause exceptions) and then revisit automation.

This is important enough to repeat: automating a broken process just makes it break faster. If your intake form has 15 different formats because there’s no standardization, automation won’t fix that. Standardize first, automate second.

Step 5: Estimate the Time Savings

For each of your top 5 processes, calculate the weekly time your team spends on it:

Weekly hours = (frequency per week) × (time per occurrence in hours)

Then estimate what percentage of that time automation could realistically save. Be conservative:

• 90–100% saved — Fully automatable process with rare exceptions. The automation handles the entire task; humans only review edge cases.
• 60–80% saved — Mostly automatable. The workflow does the heavy lifting; a human spends a few minutes reviewing or approving.
• 30–50% saved — Partially automatable. The workflow handles data movement and initial processing; a human does the judgment-heavy parts.

Total estimated savings in this example: about 13.7 hours per week. Over a year, that’s 712 hours — roughly a third of a full-time role. That’s real, measurable capacity returned to your team without hiring anyone.

These are estimates, not promises. But they’re grounded in actual observation of actual work, which is more than most automation ROI calculations can say.

Step 6: Prioritize Your First Automation Project

You now have everything you need to pick your first project. The criteria are:

1. High priority score — frequent, time-consuming, and automatable
2. Low exception rate — the process is predictable enough that automation won’t constantly break
3. Clear inputs and outputs — data comes from a defined source and goes to a defined destination
4. Low complexity — the workflow involves 2–4 systems, not 10
5. Visible impact — the time savings are noticeable to the team, building momentum for future projects

Your first project should be a slam dunk, not a stretch goal. The goal of the first automation is to prove the concept, build confidence, and create a template for future work. Pick the process that scores highest on all five criteria — not the one that’s most technically ambitious.

In the example above, customer intake processing is the clear first choice: it happens multiple times daily, takes 45 minutes per occurrence, is highly automatable (copy data from email, enter into CRM, send templated email), has clear inputs and outputs, and would save nearly 7 hours per week.

The inventory report is a strong second choice — fully automatable, predictable, and easy to build.

Common Audit Mistakes to Avoid

Don’t skip the audit because you “already know” what to automate. You probably know some of what to automate. You’re almost certainly missing tasks that happen frequently but invisibly — the small things people do without thinking about them, like checking a dashboard every morning or copying data between systems “just to be sure.” The audit surfaces these.

Don’t let the audit become an excuse to delay. The audit should take one to two weeks, not three months. Set a deadline. If you’re still gathering data after two weeks, you’re overthinking it. Use what you have — a 90% complete audit is infinitely more useful than a 100% complete audit you never finish.

Don’t score automatability based on what you’ve seen in marketing demos. A demo shows a tool doing something impressive under controlled conditions. Your real processes have messy data, unusual edge cases, and human quirks. Score based on what your team actually does, not what a sales deck suggests is possible.

Don’t forget to ask the people doing the work. Managers often have a different view of a process than the person who executes it daily. The person doing the work knows where the friction is, which steps take the longest, and which parts they’d most like to hand off. Their input is the most valuable data in the audit.

Don’t automate processes that should be eliminated. Sometimes the best automation is no automation. If a report nobody reads takes 90 minutes a week to produce, the answer isn’t to automate the report — it’s to stop making the report. Before automating anything, ask: does this process need to exist at all?

What to Do After the Audit

Once you’ve completed the audit and selected your first project, the path forward is clear:

1. Choose your tools. For most small businesses, a self-hosted automation platform like n8n combined with a local LLM via Ollama covers the majority of use cases. Both are open source, run on your own infrastructure, and keep your data private.

2. Build the first workflow. Start simple. Automate the happy path first — the 90% of cases that follow the normal flow. Handle exceptions later by routing them to a human for review.

3. Measure the actual savings. After the workflow has been running for two weeks, compare the time spent before and after. Your audit estimates gave you a target — now see how close reality came.

4. Move to the next project on your list. Use the same framework. Each automation builds on the last, and your team gets more comfortable with the process each time.

The audit gives you a roadmap. The roadmap gives you confidence that you’re automating the right things in the right order. And confidence is what separates an automation initiative that transforms your operations from one that collects dust.

The Bottom Line

An audit isn’t a glamorous step. There’s no new software to install, no demo to watch, no “aha” moment where AI does something surprising. It’s a spreadsheet, a series of conversations, and a few hours of observation.

But it’s the single highest-leverage thing you can do before starting any automation project. It ensures you build the right thing, in the right order, for the right reasons — and that the result actually saves time instead of creating new work.

If you want help running a process audit for your business, we can guide you through it — from the initial inventory to selecting your first automation project and building it with open-source tools. No sales pitch, no proprietary lock-in, just practical guidance based on what your team actually does every day.

Talk to us about your automation audit

ARDOT Consulting helps small and mid-size businesses identify, prioritize, and implement AI automation using open-source tools. We believe in practical automation — the kind that saves real hours and doesn’t create new problems. Get in touch to start the conversation.

There is. Mattermost is an open source team messaging platform that does most of what Slack does, runs on your own infrastructure, and costs nothing in licensing for teams using the free Team Edition. You own the data, you control the access, and you never get a per-seat invoice.

In this guide, we’ll walk through what Mattermost actually offers, how it compares to Slack, and how to get it running with Docker in under an hour.

What Mattermost Actually Does

Mattermost is a real-time messaging platform designed for teams. If you’ve used Slack, the interface will feel immediately familiar — channels on the left, messages in the center, threads, direct messages, file attachments, emoji reactions. But under the hood, it’s a fundamentally different model.

Core features:

• Channels — Public, private, and direct message channels organized by team
• Threads — Reply in threads to keep conversations organized
• File sharing — Drag-and-drop file uploads with preview support
• Search — Full-text search across all messages and files you have access to
• Integrations — Incoming webhooks, outgoing webhooks, slash commands, and bot accounts
• Mobile apps — Native iOS and Android apps that connect to your self-hosted server
• Desktop apps — Native apps for Windows, Mac, and Linux
• Message history — No limit on message history (Slack’s free plan caps you at 10,000 messages)

The key difference from Slack isn’t the feature list — it’s the architecture. Mattermost runs on a server you control. Your messages, files, and metadata never touch a third-party SaaS provider.

Mattermost vs Slack: The Honest Comparison

Let’s not pretend Mattermost is a drop-in replacement for every Slack feature. It’s not. But for most small-to-mid-size businesses, the trade-offs favor self-hosting. Here’s an honest comparison:

The trade-off is clear: Slack is zero-effort but you pay per seat and hand over your data. Mattermost requires some upfront setup and ongoing maintenance, but you keep your data and eliminate per-seat costs.

When Slack makes more sense: You have fewer than 10 people, no compliance requirements, and you’d rather not manage infrastructure. The convenience is worth the cost.

When Mattermost makes more sense: You have 15+ people, you care about data sovereignty, you have compliance requirements, or you already run your own servers for other things.

What You’ll Need

Before we start, here’s the infrastructure you’ll need:

• A server — A VPS with 2 GB RAM and 20 GB disk (a $5–$10/month VPS from Hetzner, OVH, or DigitalOcean works fine). If you already have a server running other services, Mattermost can share it.
• Docker and Docker Compose — We’ll use Docker to keep the installation clean and portable.
• A domain name — Something like chat.yourcompany.com with an SSL certificate (we’ll use Let’s Encrypt, which is free).
• Basic comfort with the command line — You don’t need to be a sysadmin, but you should be comfortable running commands and editing configuration files.

Step 1: Set Up the Directory Structure

On your server, create a directory for the Mattermost deployment:

mkdir -p /opt/mattermost/{config,data,logs,plugins}
cd /opt/mattermost

The data directory is where uploaded files and the database will live, so make sure the disk it’s on has enough space. For a 25-person team, 20–50 GB is plenty to start.

Step 2: Create the Docker Compose File

Create a docker-compose.yml file in /opt/mattermost/:

version: "3.8"

services:
  postgres:
    image: postgres:16-alpine
    container_name: mattermost-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: mattermost
      POSTGRES_PASSWORD: CHANGE_THIS_TO_A_STRONG_PASSWORD
      POSTGRES_DB: mattermost
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    networks:
      - mattermost-net

  mattermost:
    image: mattermost/mattermost-team-edition:latest
    container_name: mattermost
    restart: unless-stopped
    depends_on:
      - postgres
    ports:
      - "127.0.0.1:8065:8065"
    environment:
      MM_SQLSETTINGS_DRIVERNAME: postgres
      MM_SQLSETTINGS_DATASOURCE: "postgres://mattermost:CHANGE_THIS_TO_A_STRONG_PASSWORD@postgres:5432/mattermost?sslmode=disable&connect_timeout=10"
      MM_SERVICESETTINGS_SITEURL: "https://chat.yourcompany.com"
      MM_SERVICESETTINGS_ENABLELOCALMODE: "true"
      MM_FILESETTINGS_DIRECTORY: "/mattermost/data"
      MM_LOGSETTINGS_CONSOLELEVEL: INFO
    volumes:
      - ./config:/mattermost/config
      - ./data:/mattermost/data
      - ./logs:/mattermost/logs
      - ./plugins:/mattermost/plugins
    networks:
      - mattermost-net

networks:
  mattermost-net:
    driver: bridge

A few things to note:

• Change the password — Replace CHANGE_THIS_TO_A_STRONG_PASSWORD with a real, strong password. Use the same one in both places.
• The database password — Use the same value in the POSTGRES_PASSWORD and the DATASOURCE connection string.
• The SiteURL — Change chat.yourcompany.com to your actual domain.
• Port binding — We bind to 127.0.0.1:8065 so Mattermost is only accessible locally. We’ll put a reverse proxy in front for SSL.

Step 3: Start the Services

cd /opt/mattermost
docker compose up -d

This downloads the images and starts both PostgreSQL and Mattermost. The first startup takes 1–2 minutes. Check that both containers are running:

docker compose ps

You should see both services with a status of “running.” If Mattermost keeps restarting, check the logs:

docker compose logs mattermost

The most common issue is a mismatch between the database password in the POSTGRES_PASSWORD environment variable and the DATASOURCE connection string. Double-check they’re identical.

Step 4: Set Up the Reverse Proxy with SSL

Mattermost listens on port 8065 locally, but you need HTTPS for browser security and for the Mattermost desktop and mobile apps to connect properly. We’ll use Caddy as a reverse proxy because it automatically handles Let’s Encrypt certificates — no manual cert management.

Create a Caddyfile:

chat.yourcompany.com {
    reverse_proxy localhost:8065
}

Install and start Caddy (on Ubuntu/Debian):

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Caddy will start automatically, read the Caddyfile, obtain a Let’s Encrypt certificate, and proxy traffic to Mattermost. Within a minute, https://chat.yourcompany.com should show the Mattermost setup screen.

If you prefer nginx, you can use nginx with certbot — the setup is a bit more involved but equally valid. Caddy is simpler because the SSL certificate management is fully automatic.

Step 5: Create Your Admin Account

Visit https://chat.yourcompany.com in your browser. You’ll see the initial setup screen:

1. Create the first user — Enter your email, username, and password. This becomes the admin account.
2. Create your first team — Give it a name (e.g., “YourCompany” or “Engineering”). This becomes the primary workspace.
3. Create your first channels — Mattermost creates default channels like “Town Square” (the general channel) and “Off-Topic.” Add channels for your teams or projects.

That’s it. Your Mattermost instance is live and accessible to your team. Share the URL with your team members and they can create accounts from the sign-up page.

Step 6: Configure Key Settings

Once you’re logged in as admin, go to System Console (the gear icon → System Console) and review these important settings:

Email Notifications

Without email notifications, your team won’t know when they have messages. Go to Environment → SMTP and configure your SMTP server. If you don’t have an SMTP server, you can use a service like Postmark or run your own with Postal.

Test the connection from the System Console before moving on.

File Upload Size

By default, Mattermost allows file uploads up to 100 MB. Adjust this in Site Configuration → File Storage if you need more or less. Keep in mind that files are stored on your server’s disk, so set a reasonable limit based on available space.

Data Retention

If your industry requires data retention policies (or the opposite — auto-deletion of old messages), configure this in Data Retention Policy. You can set rules to keep messages indefinitely, delete after N days, or delete based on channel type.

Session Length

In Security → Sessions, you can control how long users stay logged in. For sensitive environments, set shorter session lengths and require re-authentication.

Step 7: Invite Your Team and Create Channels

With the server configured, set up your team structure:

Channel suggestions for a small business:

To invite people, go to the team menu → Get Team Invite Link. Share the link with your team. They’ll create their own accounts and join automatically.

For larger organizations, you can connect Mattermost to LDAP or Active Directory for centralized authentication. This is available in the free Team Edition — no enterprise license needed.

Step 8: Set Up Integrations

Mattermost supports the same integration patterns as Slack: incoming webhooks, outgoing webhooks, slash commands, and bot accounts. Here’s a practical example.

Example: Post a Notification from n8n

If you use n8n for automation (see our n8n guide), you can send notifications to a Mattermost channel when a workflow completes.

1. In Mattermost, go to the channel where you want notifications → Channel Settings → Integrations → Incoming Webhook.
2. Create a webhook and copy the URL.
3. In n8n, add an HTTP Request node:

{
  "method": "POST",
  "url": "https://chat.yourcompany.com/hooks/XXXXXXXXXX",
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "text": "✅ Workflow completed:  at "
  }
}

Now every time your n8n workflow runs, you get a notification in Mattermost. This works for any system that can make an HTTP POST — Odoo, Metabase, your CI/CD pipeline, custom scripts, anything.

Slash Commands

You can create custom slash commands that trigger external actions. For example, /lookup ACME Corp could query your CRM and return the company’s details in the channel. This is configured in Integrations → Slash Commands with a callback URL that receives the command and returns a Mattermost-formatted response.

Step 9: Back Up Your Data

This is the most important step. Since you’re self-hosting, you’re responsible for backups. Here’s a simple backup strategy:

What to back up:

• The PostgreSQL database (contains all messages, users, and settings)
• The data directory (contains uploaded files)

Simple backup script:

#!/bin/bash
BACKUP_DIR="/backups/mattermost"
DATE=$(date +%Y%m%d_%H%M%S)

# Create backup directory
mkdir -p $BACKUP_DIR

# Back up the database
docker exec mattermost-postgres pg_dump -U mattermost mattermost | gzip > $BACKUP_DIR/db_$DATE.sql.gz

# Back up uploaded files
tar czf $BACKUP_DIR/files_$DATE.tar.gz -C /opt/mattermost data/

# Keep only the last 7 days of backups
find $BACKUP_DIR -mtime +7 -delete

Schedule this with a cron job:

# Run backup daily at 2 AM
0 2 * * * /opt/mattermost/backup.sh

For offsite backups, sync the backup directory to an S3-compatible storage service like MinIO (which you can also self-host) or a remote server using rsync.

Step 10: Keep It Updated

Mattermost releases updates regularly. To update:

cd /opt/mattermost
docker compose pull
docker compose up -d

This pulls the latest image and restarts the containers. The database schema is migrated automatically. The whole process takes less than a minute.

Update best practices:

• Check the release notes before upgrading to a major version
• Back up your database before upgrading (run the backup script above)
• Test on a staging instance if you have critical workflows

The Real Cost Comparison

Let’s put real numbers on this. Assume a 25-person team:

For a 25-person team, Mattermost saves roughly $2,200–$2,300 per year even after accounting for server costs. For a 50-person team, the savings double. The larger your team, the more dramatic the savings.

The hidden cost is your time. Budget 2–4 hours for initial setup and 1–2 hours per quarter for updates and maintenance. If you value your time at $100/hour, that’s $200–$400/year in labor — still a fraction of the Slack licensing cost.

What About the Desktop and Mobile Apps?

Mattermost provides native apps for all platforms:

• Desktop: Windows, macOS, Linux — available from mattermost.com/apps or your package manager
• Mobile: iOS (App Store) and Android (Play Store/F-Droid)

The apps connect to your self-hosted server by entering the server URL. They support push notifications (Mattermost runs its own push notification service — the HPNS — which is free for the Team Edition).

If you’ve used the Slack desktop app, the Mattermost desktop app feels nearly identical: multiple teams in a sidebar, unread badges, notification preferences, dark mode.

When Self-Hosting Chat Makes Sense

Self-hosting your team chat isn’t for everyone. But it makes particular sense if:

1. You’re already self-hosting other tools — If you run Odoo, n8n, or Plausible on your own server, adding Mattermost is a natural extension. You already have the skills and infrastructure.

2. You have compliance requirements — HIPAA, GDPR, or industry-specific data handling rules are much easier to satisfy when your data stays on servers you control.

3. You have a growing team — The per-seat cost of Slack scales linearly with headcount. Mattermost doesn’t. At 30+ people, the savings become significant.

4. You want unlimited message history — Slack’s free and low-tier plans cap your message history. Mattermost keeps everything, forever, at no extra cost.

5. You want deeper integrations — Self-hosted Mattermost gives you full access to the database and API. You can build custom integrations, run analytics on message patterns, or connect it to your data warehouse.

Common Gotchas

A few things catch people off guard when setting up Mattermost for the first time:

Email notifications don’t work out of the box. Mattermost needs an SMTP server to send emails. If you skip this, your team won’t get email notifications for mentions or direct messages. Configure SMTP in the System Console before inviting your team.

Push notifications need the internet. Even though Mattermost is self-hosted, mobile push notifications go through Mattermost’s notification relay service (HPNS). This is free but does require outbound internet access from your server. If you’re on a fully air-gapped network, push notifications won’t work without additional configuration.

File uploads can fill your disk. Unlike Slack, where file storage is someone else’s problem, Mattermost stores files on your server. Monitor disk usage and set upload size limits. A 25-person team uploading documents and screenshots will generate 5–20 GB of files per year.

Upgrades occasionally require database migration. Major version upgrades may run database migrations that can take several minutes. Schedule upgrades during off-hours and always back up first.

Next Steps

Mattermost is just one piece of a self-hosted communication stack. Once your team chat is running, consider:

• Connect it to your automation — Use n8n to send automated alerts to Mattermost channels when things happen (new leads, completed tasks, system alerts)
• Add Mattermost to your backup strategy — Include the database and file storage in your regular backup routine
• Set up monitoring — Use a tool like Uptime Kuma to alert you if your Mattermost instance goes down
• Create a guest access policy — If you work with external contractors, configure guest accounts with limited channel access

Self-hosting your team chat is one of the highest-impact, lowest-cost moves a small business can make. You get enterprise-grade messaging, unlimited history, full data control, and per-seat costs that stay at zero no matter how much your team grows.

Want help setting up Mattermost or migrating from Slack? Get in touch — ARDOT Consulting specializes in open source infrastructure for small businesses. We’ll handle the setup, migration, and training so your team can start chatting on day one.

For a 15-person team on the Business Standard plan at $12/user/month, that’s $2,160 per year. Not catastrophic, but not trivial either. The real cost isn’t the subscription fee, though. It’s the dependency. Your files, your calendar history, your contacts, your shared documents — all of it lives in a system you can’t self-audit, can’t back up to your own metal without proprietary tooling, and can’t run offline if your internet drops or Google has an outage.

There’s a better way. Nextcloud is a free, open-source platform that does most of what Google Workspace does — file sync, calendar, contacts, document editing, video chat, task management — and runs entirely on your own server. No per-user fees. No data leaving your network. No vendor making decisions about your workflow.

This guide walks through setting up Nextcloud with Docker, migrating your data off Google, and configuring the features your team actually uses day-to-day.

What Nextcloud Replaces

Before we get into setup, let’s be honest about what Nextcloud does well and where it falls short. No tool is perfect, and Nextcloud has trade-offs you should understand before committing.

The file sync, calendar, and contacts replacements are genuinely excellent. Nextcloud uses industry standards (WebDAV, CalDAV, CardDAV) that work with every operating system and mobile app. You’re not locked into Nextcloud’s client — you can use any CalDAV-compatible calendar app.

Document collaboration is good but not as seamless as Google Docs. Nextcloud integrates with Collabora (a LibreOffice-based online editor) or OnlyOffice for real-time document editing. It works, but the interface is a bit more utilitarian. For most business documents — proposals, internal memos, meeting notes — it’s more than sufficient.

Email is the one area where Nextcloud isn’t a full replacement. While it has a mail app, running a full mail server (with spam filtering, DKIM, DMARC, deliverability management) is a specialized skill that most small businesses should outsource. We recommend keeping a dedicated email provider — we use and recommend Mailcow (open source, self-hosted) or a privacy-focused provider like Posteo or Migadu for email, and using Nextcloud for everything else.

What You Need

• A server: A VPS with at least 2GB RAM and 40GB storage (Hetzner, OVH, or any provider you trust). For a team of 15 with moderate file storage, 4GB RAM and 100GB+ storage is more comfortable. You can also run it on a dedicated office machine.
• Docker and Docker Compose: Installed on your server.
• A domain name: Something like files.yourcompany.com. You can get one from any registrar — we use and recommend Porkbun or Namecheap.
• 30 minutes: The actual setup is fast. Migration takes longer depending on how much data you have.

Step 1: Set Up Nextcloud with Docker

Create a directory for your Nextcloud deployment and make a docker-compose.yml file:

version: "3.8"

services:
  db:
    image: postgres:16
    container_name: nextcloud_db
    restart: unless-stopped
    volumes:
      - ./db_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=nextcloud
      - POSTGRES_USER=nextcloud
      - POSTGRES_PASSWORD=CHANGE_THIS_TO_A_STRONG_PASSWORD
    networks:
      - nextcloud_net

  nextcloud:
    image: nextcloud:apache
    container_name: nextcloud_app
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8080:80"
    volumes:
      - ./nextcloud_data:/var/www/html
    environment:
      - POSTGRES_HOST=db
      - POSTGRES_DB=nextcloud
      - POSTGRES_USER=nextcloud
      - POSTGRES_PASSWORD=CHANGE_THIS_TO_A_STRONG_PASSWORD
      - NEXTCLOUD_ADMIN_USER=admin
      - NEXTCLOUD_ADMIN_PASSWORD=CHANGE_THIS_TOO
      - NEXTCLOUD_TRUSTED_DOMAINS=files.yourcompany.com
    networks:
      - nextcloud_net

  cron:
    image: nextcloud:apache
    container_name: nextcloud_cron
    restart: unless-stopped
    depends_on:
      - nextcloud
    volumes:
      - ./nextcloud_data:/var/www/html
    entrypoint: |
      /bin/sh -c "echo '*/5 * * * * php /var/www/html/occ cron:run' > /var/spool/cron/crontabs/www-data && crond -f"
    networks:
      - nextcloud_net

networks:
  nextcloud_net:
    driver: bridge

A few things to note about this setup:

• PostgreSQL is used instead of the default SQLite. For any team larger than 2-3 people, you want a real database. SQLite works for testing but will slow down under concurrent use.
• The cron container runs Nextcloud’s background jobs every 5 minutes. This handles things like file scanning, notification delivery, and calendar reminders. Without it, some features silently stop working.
• Trusted domains are set to your actual domain. Nextcloud blocks requests from unknown domains as a security measure.

Change the passwords, then start it up:

docker compose up -d

Wait about 30 seconds for the containers to initialize, then check that it’s running:

docker compose ps

You should see all three containers (db, app, cron) running. Nextcloud is now accessible on port 8080 of your server.

Step 2: Put It Behind a Reverse Proxy with HTTPS

Running Nextcloud on port 8080 without encryption is fine for testing, but you need HTTPS before anyone actually uses it. We’ll use Caddy as a reverse proxy because it automatically handles Let’s Encrypt certificates — no manual certbot renewals, no certificate expiry surprises.

Add Caddy to your docker-compose setup:

  caddy:
    image: caddy:2
    container_name: nextcloud_caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - nextcloud
    networks:
      - nextcloud_net

volumes:
  caddy_data:
  caddy_config:

Create a Caddyfile in the same directory:

files.yourcompany.com {
    reverse_proxy nextcloud:80
    
    header {
        Strict-Transport-Security "max-age=31536000; includeSubdomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "no-referrer"
    }
}

Point your domain’s DNS A record to your server’s IP address, restart the stack, and Caddy will automatically obtain and install a Let’s Encrypt TLS certificate:

docker compose up -d

Visit https://files.yourcompany.com and you’ll see the Nextcloud login screen with a valid HTTPS certificate. No manual cert management required.

Step 3: Configure the Apps Your Team Actually Uses

Nextcloud starts with just file storage enabled. The real value comes from installing the apps that replace specific Google Workspace features. After logging in as admin, go to Apps in the top-right menu and install these:

Calendar

Install the Calendar app from the Nextcloud App Store (built-in, one click). Each user gets a personal calendar, and you can create shared calendars for the team — “Company Events,” “Project Deadlines,” “Meeting Room Booking.”

Because Nextcloud Calendar uses CalDAV, it works with every calendar app out there:

• macOS Calendar: Add a CalDAV account with the URL https://files.yourcompany.com/remote.php/dav
• Thunderbird: Built-in CalDAV support, works natively
• Mobile: Use DAVx⁵ (Android) or the built-in CalDAV support on iOS

No proprietary sync protocols. No “Google Calendar Sync” tool. Just the standard that every calendar app already understands.

Contacts

Install the Contacts app. Same story as calendar — it uses CardDAV, so it syncs with macOS Contacts, Thunderbird, iOS, and Android (via DAVx⁵). Your team’s contact list lives on your server, not in Google’s address book.

Collaborative Document Editing

Install Nextcloud Office (which integrates Collabora) or the OnlyOffice app. Both give you real-time collaborative editing of text documents and spreadsheets directly in the browser. Multiple people can edit the same document simultaneously, see each other’s cursors, and leave comments.

Collabora is the more popular choice and integrates more tightly with Nextcloud. It’s based on LibreOffice, so the interface will feel familiar to anyone who’s used LibreOffice or OpenOffice. It’s not as polished as Google Docs — the formatting tools are a bit clunkier, and some advanced features (like pivot tables in spreadsheets) are less capable. But for 90% of business documents, it does the job.

If your team creates a lot of documents with complex formatting, you can also use Nextcloud Text — a lightweight Markdown editor built into Nextcloud that’s excellent for meeting notes, internal documentation, and quick drafts. It’s faster and simpler than a full word processor.

File Sharing

File sharing is Nextcloud’s strongest feature. You can:

• Share files with internal users — with read-only or edit permissions, optional expiration dates
• Share via public link — password-protected, expiration-dated, with optional upload-only mode (great for collecting files from clients)
• Share entire folders — with fine-grained permissions per user

This replaces Google Drive’s sharing model completely. The advantage is that shared links point to your domain (files.yourcompany.com/s/abc123) rather than Google’s, which looks more professional in client communications.

Nextcloud Talk (Chat and Video)

Install Nextcloud Talk for internal chat and video calls. It’s not a Slack replacement — it’s more like a simplified version of Google Meet plus basic chat. For a small team that needs occasional video calls and a persistent chat channel, it works. For larger teams or external collaboration, you’d want a dedicated tool (we like Mattermost for self-hosted team chat).

Step 4: Migrate Your Data Off Google

This is the part that intimidates people, but it’s more tedious than difficult. Here’s the migration path for each type of data:

Files (Google Drive)

1. Export from Google: Use Google Takeout (takeout.google.com) to download all your Drive files as a zip archive. Select Drive, choose your export format, and wait for Google to prepare the download.
2. Upload to Nextcloud: Unzip the archive, then either drag-and-drop files through the Nextcloud web interface (good for small amounts) or use the Nextcloud Desktop Client (better for large migrations). The sync client is available for Windows, macOS, and Linux.
3. Reorganize: Take this opportunity to clean up your folder structure. You’re moving to a new system — might as well organize it properly.

Calendar (Google Calendar)

1. Export from Google Calendar: Go to calendar settings → Import & Export → Export. You’ll get an .ics file per calendar.
2. Import to Nextcloud: In Nextcloud Calendar, click “Import calendar” and upload the .ics files.

Contacts (Google Contacts)

1. Export from Google Contacts: Go to contacts.google.com → Export → choose vCard format.
2. Import to Nextcloud: In Nextcloud Contacts, click “Import” and upload the vCard file.

Documents (Google Docs/Sheets)

This is the trickiest part. Google Docs documents aren’t real files — they’re web app documents stored in Google’s proprietary format. To migrate:

1. Export each document: In Google Docs, File → Download → choose Microsoft Word (.docx) format. For spreadsheets, choose Excel (.xlsx). You can also export multiple documents at once through Google Drive (select all → right-click → Download).
2. Upload to Nextcloud: Upload the .docx/.xlsx files to Nextcloud. If you’ve installed Collabora or OnlyOffice, you can open and edit them directly in the browser with full collaborative editing.

This is manual but only needs to happen once. For a team with 50-100 active documents, it’s a few hours of work. Spread across the team, each person handles their own documents.

Step 5: Set Up Backups

This is the most important section in this guide. When your data was on Google’s servers, Google handled backups. Now that it’s on your server, you handle backups. This is the trade-off of self-hosting: you gain control, but you also gain responsibility.

At minimum, set up automated backups of two things:

1. The database: docker exec nextcloud_db pg_dump -U nextcloud nextcloud > backup_$(date +%Y%m%d).sql
2. The file storage: The ./nextcloud_data directory

Here’s a simple backup script that runs daily, keeps 7 days of backups, and syncs them to a remote location:

#!/bin/bash
# Nextcloud daily backup script

BACKUP_DIR="/backups/nextcloud"
NEXTCLOUD_DIR="/opt/nextcloud"
DATE=$(date +%Y%m%d)
RETENTION_DAYS=7

mkdir -p $BACKUP_DIR

# Backup database
docker exec nextcloud_db pg_dump -U nextcloud nextcloud > "$BACKUP_DIR/db_$DATE.sql"

# Backup files (exclude cache and temp)
tar czf "$BACKUP_DIR/files_$DATE.tar.gz" \
  --exclude="$NEXTCLOUD_DIR/nextcloud_data/data/*/cache" \
  --exclude="$NEXTCLOUD_DIR/nextcloud_data/data/*/uploads" \
  "$NEXTCLOUD_DIR/nextcloud_data"

# Clean old backups
find $BACKUP_DIR -name "*.sql" -mtime +$RETENTION_DAYS -delete
find $BACKUP_DIR -name "*.tar.gz" -mtime +$RETENTION_DAYS -delete

# Sync to remote storage (optional — use rclone with any S3-compatible provider)
# rclone sync $BACKUP_DIR remote:nextcloud-backups/

Set this up as a daily cron job on your server. If you want off-site backups (and you should), install rclone and sync the backup directory to an S3-compatible storage provider — we recommend Backblaze B2 or Wasabi for affordable object storage. Both work with rclone out of the box.

Test your backups by restoring them at least once. An untested backup is not a backup — it’s a hope.

The Real Cost Comparison

Let’s talk numbers for a 15-person team.

The savings are real: roughly $2,000 per year for a 15-person team, scaling linearly as you add people. The trade-off is that someone needs to maintain the server — updates, backups, the occasional troubleshooting. If you have a part-time IT person or work with a consultant (we know one), this is maybe an hour per month.

The maintenance burden is genuinely low once it’s set up. Nextcloud updates are a single command (docker compose pull && docker compose up -d), and the platform is mature enough that major issues are rare. The biggest risk is neglecting backups — which is why Step 5 exists.

When Nextcloud Is NOT the Right Choice

Being honest: Nextcloud isn’t for everyone. Here’s when you should stick with a hosted solution:

• You have no one to maintain a server. If your team is entirely non-technical and you don’t have an IT consultant, the self-hosting model adds risk. A managed Nextcloud provider (like Nextcloud’s official hosting partners) is a middle ground — you get the open source platform without the server management.
• You rely heavily on Google Docs’ advanced features. If your team builds complex spreadsheets with pivot tables, apps script, and heavy formatting, Collabora/OnlyOffice will feel limiting. For most business documents it’s fine, but power users will notice the difference.
• You need deep integration with third-party apps that assume Google Workspace. Some tools only offer “Sign in with Google” and Google Drive integration. If your workflow depends on these, switching requires finding alternatives or accepting manual workarounds.

For most small businesses — especially those whose file and calendar needs are straightforward — Nextcloud is a genuinely good replacement that saves money and gives you ownership of your data.

Making the Switch Gradually

You don’t have to migrate everything in one weekend. A phased approach works well:

1. Week 1: Set up Nextcloud, configure HTTPS, create user accounts. Migrate calendar and contacts (fast, low-risk).
2. Week 2-3: Migrate files. Start with the current active project files, then archive older files in batches.
3. Week 4: Set up Collabora for document editing. Migrate active documents.
4. Week 5+: Stop creating new content in Google Workspace. Keep Google Workspace active for a month as a safety net, then cancel.

This gives your team time to adjust and ensures nothing critical gets lost in the transition. By the end of the second month, you’re fully on Nextcloud and saving ~$180/month.

Wrapping Up

Google Workspace is convenient, but convenience isn’t the same as control. Every file you store in Google Drive is a file you’re renting access to rather than owning. Every calendar event in Google Calendar is data that lives on Google’s terms, not yours. Nextcloud gives you the same core capabilities — file sync, calendar, contacts, collaborative editing — on infrastructure you control, for a fraction of the cost.

The setup takes an afternoon. The migration takes a few weeks of gradual transition. The payoff is permanent: your company’s knowledge stays on your server, under your rules, with no per-user tax and no vendor deciding to change the deal next quarter.

If you want help setting up Nextcloud for your business — from server configuration to data migration to team training — get in touch. We specialize in helping small businesses move to self-hosted open source tools without the headaches.

The fix isn’t another SaaS subscription. It’s a self-hosted knowledge base paired with AI-powered search that understands what your team is actually asking — not just keyword matching, but semantic search that finds “how do I process a refund” when the document is titled “Customer Return Policy.”

In this guide, we’ll set up BookStack, an open-source wiki platform, and pair it with Ollama for AI-powered semantic search. Everything runs on your own infrastructure. No per-seat fees, no data leaving your network, no vendor deciding to double their pricing next quarter.

Why BookStack?

BookStack is a free, open-source documentation platform that sits somewhere between a wiki and a structured documentation site. It’s built in PHP/Laravel, runs in Docker, and has a clean, approachable interface that doesn’t scare non-technical staff.

Here’s why it works for small businesses:

• Organized by default: Content is structured into Books → Chapters → Pages, so your team isn’t dumping everything into one flat list
• WYSIWYG editor: No Markdown required (though it’s supported). Your operations manager can actually use it
• Role-based permissions: Control who can view, edit, or administer different books
• Search built in: Full-text search out of the box — we’ll make it smarter with AI
• Self-hosted: Runs on a $5/month VPS or an old office desktop

How BookStack Compares to SaaS Alternatives

For a 15-person team, that’s $1,440–$3,240 per year in SaaS fees you’re not paying. Plus, your company knowledge stays on your server.

Step 1: Set Up BookStack with Docker

You’ll need a server with Docker installed. This can be a VPS from Hetzner, OVH, or any provider you trust — or a spare machine in your office. We’ll use the official BookStack Docker image.

Create a docker-compose.yml file:

version: "3.8"

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:latest
    container_name: bookstack
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
      - DB_HOST=bookstack_db
      - DB_USER=bookstack
      - DB_PASS=change_this_password
      - DB_DATABASE=bookstack
    volumes:
      - ./bookstack_data:/config
    ports:
      - 6875:80
    restart: unless-stopped
    depends_on:
      - bookstack_db

  bookstack_db:
    image: lscr.io/linuxserver/mariadb:latest
    container_name: bookstack_db
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
      - MYSQL_ROOT_PASSWORD=change_this_root_password
      - MYSQL_DATABASE=bookstack
      - MYSQL_USER=bookstack
      - MYSQL_PASSWORD=change_this_password
    volumes:
      - ./db_data:/config
    restart: unless-stopped

Start it up:

docker compose up -d

Wait about 30 seconds for the database to initialize, then open http://your-server-ip:6875 in your browser. The default login is admin@admin.com / password. Change this immediately on first login.

Secure It with a Reverse Proxy

For production, don’t expose port 6875 directly. Use Caddy as a reverse proxy with automatic HTTPS:

# Add to your docker-compose.yml
  caddy:
    image: caddy:latest
    container_name: caddy
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
    restart: unless-stopped
    depends_on:
      - bookstack

volumes:
  caddy_data:

And a minimal Caddyfile:

wiki.yourcompany.com {
    reverse_proxy bookstack:80
}

Point your DNS to the server, restart with docker compose up -d, and Caddy handles the TLS certificate automatically. Your team now accesses the wiki at https://wiki.yourcompany.com.

Step 2: Organize Your Knowledge

Before adding AI search, you need content worth searching. The biggest reason internal wikis fail is that nobody structures them. BookStack’s hierarchy helps, but you still need a plan.

Here’s a structure that works for most small businesses:

Book 1: Company Operations

• Chapter: Onboarding → Pages: Day 1 Checklist, Tools Setup, Key Contacts
• Chapter: Daily Procedures → Pages: Opening/Closing, Cash Handling, End-of-Day Reports
• Chapter: Emergency Procedures → Pages: System Outage, Customer Incident, Evacuation

Book 2: Customer Guide

• Chapter: Common Questions → Pages: Return Policy, Warranty Claims, Pricing Tiers
• Chapter: Account Management → Pages: How to Create Accounts, Reset Passwords, Update Billing

Book 3: Internal Tools

• Chapter: Systems → Pages: CRM Login, Email Setup, VPN Access
• Chapter: Troubleshooting → Pages: Printer Issues, Email Problems, VPN Won’t Connect

The key principle: every page should answer one question. Not “Everything About Customer Service” but “How to Process a Refund.” This makes both human search and AI search more effective.

Step 3: Add AI-Powered Semantic Search with Ollama

BookStack’s built-in search is decent — it does full-text matching. But it has the same limitation as every keyword search: if a user types “how do I handle a customer who wants their money back,” it won’t find a page titled “Refund Processing Procedure” unless those exact words appear.

Semantic search fixes this. Instead of matching keywords, it matches meaning. We’ll use Ollama to generate embeddings (numerical representations of text meaning) for every page in your wiki, then search against those embeddings.

Install Ollama

If you followed our Ollama guide, you already have it. If not:

curl -fsSL https://ollama.com/install.sh | sh

Pull an embedding model — these are small and fast:

ollama pull nomic-embed-text

This model is about 270MB and runs on any machine with 4GB RAM. It doesn’t need a GPU for embedding generation.

Build a Search Index

We’ll write a Python script that:

1. Pulls all pages from BookStack’s REST API
2. Generates an embedding for each page
3. Stores embeddings in a simple SQLite database
4. Provides a search endpoint that compares query embeddings against stored ones

First, get an API token from BookStack: Settings → API Tokens → Create Token. Save the ID and secret.

Here’s the indexing script, build_index.py:

import requests
import json
import sqlite3
import os
import subprocess

# BookStack API config
BOOKSTACK_URL = os.environ.get("BOOKSTACK_URL", "http://localhost:6875")
API_TOKEN_ID = os.environ.get("BS_API_ID", "your_token_id")
API_TOKEN_SECRET = os.environ.get("BS_API_SECRET", "your_token_secret")

# Ollama config
OLLAMA_URL = "http://localhost:11434"
EMBED_MODEL = "nomic-embed-text"

def get_all_pages():
    """Fetch all pages from BookStack API."""
    headers = {"Authorization": f"Token {API_TOKEN_ID}:{API_TOKEN_SECRET}"}
    pages = []
    offset = 0
    while True:
        resp = requests.get(
            f"{BOOKSTACK_URL}/api/pages",
            headers=headers,
            params={"count": 100, "offset": offset}
        )
        resp.raise_for_status()
        data = resp.json().get("data", [])
        if not data:
            break
        pages.extend(data)
        offset += 100
    return pages

def get_embedding(text):
    """Generate embedding for text using Ollama."""
    resp = requests.post(
        f"{OLLAMA_URL}/api/embeddings",
        json={"model": EMBED_MODEL, "prompt": text[:8000]}
    )
    resp.raise_for_status()
    return resp.json()["embedding"]

def init_db(db_path="search_index.db"):
    """Initialize SQLite database for embeddings."""
    conn = sqlite3.connect(db_path)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS page_embeddings (
            page_id INTEGER PRIMARY KEY,
            title TEXT,
            url TEXT,
            content_preview TEXT,
            embedding TEXT
        )
    """)
    conn.commit()
    return conn

def build_index():
    """Build the search index from all BookStack pages."""
    conn = init_db()
    pages = get_all_pages()
    print(f"Found {len(pages)} pages to index")

    for page in pages:
        # Combine title and text content for richer embeddings
        text = f"{page.get('name', '')}\n{page.get('text', '')}"
        embedding = get_embedding(text)

        url = f"{BOOKSTACK_URL}/books/{page.get('book_slug', '')}/page/{page.get('slug', '')}"

        conn.execute(
            "INSERT OR REPLACE INTO page_embeddings VALUES (?, ?, ?, ?, ?)",
            (
                page["id"],
                page.get("name", ""),
                url,
                text[:200],
                json.dumps(embedding)
            )
        )
        conn.commit()
        print(f"  Indexed: {page.get('name', '')}")

    conn.close()
    print("Index build complete")

if __name__ == "__main__":
    build_index()

Run it:

pip install requests
export BS_API_ID="your_token_id"
export BS_API_SECRET="your_token_secret"
python build_index.py

Build the Search Interface

Now create a small Flask app that takes a natural-language query and returns the most relevant pages:

# search_server.py
from flask import Flask, request, jsonify
import requests
import json
import sqlite3
import numpy as np

app = Flask(__name__)
OLLAMA_URL = "http://localhost:11434"
EMBED_MODEL = "nomic-embed-text"

def get_embedding(text):
    resp = requests.post(
        f"{OLLAMA_URL}/api/embeddings",
        json={"model": EMBED_MODEL, "prompt": text}
    )
    resp.raise_for_status()
    return np.array(resp.json()["embedding"])

def cosine_similarity(a, b):
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

@app.route("/search")
def search():
    query = request.args.get("q", "")
    if not query:
        return jsonify({"error": "No query provided"}), 400

    query_embedding = get_embedding(query)

    conn = sqlite3.connect("search_index.db")
    results = []
    for row in conn.execute("SELECT page_id, title, url, content_preview, embedding FROM page_embeddings"):
        stored_embedding = np.array(json.loads(row[4]))
        score = cosine_similarity(query_embedding, stored_embedding)
        results.append({
            "title": row[1],
            "url": row[2],
            "preview": row[3],
            "score": float(score)
        })
    conn.close()

    # Sort by similarity score, return top 5
    results.sort(key=lambda x: x["score"], reverse=True)
    return jsonify({"results": results[:5]})

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Run the search server:

pip install flask numpy
python search_server.py

Now you can search:

curl "http://localhost:5000/search?q=how+do+I+process+a+refund"

And get back the most semantically relevant pages — even if none of them contain the exact word “refund.” The search understands that “process a refund” and “customer return policy” are talking about the same thing.

Rebuild the Index When Content Changes

BookStack content evolves. Set up a cron job to rebuild the index nightly:

# /etc/cron.d/bookstack-search
0 2 * * * root BS_API_ID=your_token_id BS_API_SECRET=your_token_secret /usr/bin/python3 /opt/bookstack-search/build_index.py >> /var/log/bookstack-search.log 2>&1

Or, for real-time updates, use BookStack’s webhook feature to trigger a re-index of a single page whenever content is edited. That’s more work but keeps the index always current.

Step 4: Make It Usable for Your Team

A search API is great for developers but useless for your operations manager. You need a front end. Here are two approaches:

Option A: Simple HTML Page

A single-page HTML form that calls your search API:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Company Knowledge Search</title>
    <style>
        body { font-family: sans-serif; max-width: 700px; margin: 40px auto; padding: 0 20px; }
        .search-box { width: 100%; padding: 12px; font-size: 16px; border: 1px solid #ddd; border-radius: 6px; }
        .result { padding: 16px 0; border-bottom: 1px solid #eee; }
        .result h3 { margin: 0 0 4px; }
        .result h3 a { color: #2196F3; text-decoration: none; }
        .result .preview { color: #666; font-size: 14px; margin-top: 4px; }
        .score { color: #999; font-size: 12px; }
    </style>
</head>
<body>
    <h1>🔍 Knowledge Search</h1>
    <input class="search-box" id="query" placeholder="Ask anything..." onkeyup="search(event)" />
    <div id="results"></div>

    <script>
        async function search(e) {
            if (e.key !== 'Enter') return;
            const q = document.getElementById('query').value;
            if (!q) return;
            const resp = await fetch(`http://your-server:5000/search?q=${encodeURIComponent(q)}`);
            const data = await resp.json();
            const html = (data.results || []).map(r => `
                <div class="result">
                    <h3><a href="${r.url}" target="_blank">${r.title}</a></h3>
                    <div class="preview">${r.preview}</div>
                    <div class="score">Match: ${(r.score * 100).toFixed(0)}%</div>
                </div>
            `).join('');
            document.getElementById('results').innerHTML = html;
        }
    </script>
</body>
</html>

Host this on your Caddy server alongside BookStack, and your team has a simple search bar that understands natural language.

Option B: Integrate with Your Chat Platform

If your team uses Mattermost (open-source Slack alternative), you can create a bot that responds to /search how do I process a refund with the top results directly in chat. This is where the search gets the most use — people are already in chat when they have a question.

The bot is a simple Python script that listens for slash commands and queries your search API:

from mattermost import MattermostAPI
import requests

mm = MattermostAPI("https://chat.yourcompany.com", "your_bot_token")

def handle_search_command(query, channel_id):
    resp = requests.get(
        "http://localhost:5000/search",
        params={"q": query}
    )
    results = resp.json().get("results", [])

    if not results:
        mm.create_post(channel_id, "No results found. Try different wording.")
        return

    message = "**Top results:**\n\n"
    for i, r in enumerate(results[:3], 1):
        message += f"{i}. [{r['title']}]({r['url']})\n   _{r['preview'][:100]}..._\n"

    mm.create_post(channel_id, message)

Real-World Impact

Here’s what this looks like in practice for a small business:

Before: A new hire needs to know how to process a return. They search the shared drive for “return” and get 47 files. They ask three colleagues. One says “check the wiki.” The wiki search returns nothing because the page is called “Customer Refund Workflow.” Twenty minutes lost.

After: The new hire types “how do I handle a customer return” into the knowledge search. The AI matches the semantic meaning to “Customer Refund Workflow” and returns it as the top result with a 94% match score. They click through and have their answer in 30 seconds.

Multiply that by 15 employees asking 5 questions per day, and you’re saving roughly 18 hours of “where do I find…” time per week. That’s nearly half a full-time position redirected from searching to actually working.

Keeping It Alive

The biggest threat to any knowledge base isn’t technology — it’s entropy. Here’s how to keep yours from going stale:

1. Assign ownership: Each Book (Company Operations, Customer Guide, etc.) has one person responsible for reviewing it monthly
2. Page review dates: BookStack doesn’t have this natively, but you can add a “Last Reviewed: [date]” line at the top of each page and set a calendar reminder
3. Tie updates to process changes: When you change a business process, updating the wiki page is part of the change — not a separate task
4. Watch the search logs: If people search for something and get no results, that’s a gap. Create a page for it
5. Re-index regularly: The nightly cron job handles this, but verify it’s running: tail -20 /var/log/bookstack-search.log

What This Setup Costs You

Compare that to Notion at $1,440/year for 15 users, or Confluence at $600–$1,800/year. And your data never leaves your server.

Wrapping Up

A knowledge base only works if people can find what they need. Traditional wikis fail because their search is keyword-based and people don’t think in keywords — they think in questions. By combining BookStack’s clean documentation structure with Ollama’s semantic search, you give your team a system that understands what they’re actually asking for.

The whole setup runs on infrastructure you control, costs less than a single SaaS seat per month, and scales to as many users as you have. The only ongoing work is keeping your content current — and that’s a people problem, not a technology one.

If you want help setting up a self-hosted knowledge base with AI search for your business, reach out through our contact form. We’ll assess your needs, handle the setup, and train your team on keeping it alive — no SaaS subscriptions required.

You know the feeling. You need a specific invoice from eight months ago, and you spend forty-five minutes searching through folders, email threads, and physical binders before finally finding it — or giving up and asking the vendor to resend it. That’s not just annoying. It’s expensive. A study by IDC put the cost of searching for misplaced documents at around $20 per document in lost productivity. For a small business generating hundreds of documents a month, that adds up fast.

The commercial document management market is full of solutions — but they come with per-user pricing, storage limits, and the quiet assumption that you’re comfortable handing your most sensitive business documents to a third-party cloud. Paperless-ngx is the open-source alternative. It’s a self-hosted document management system that automatically ingests documents, runs optical character recognition (OCR) to make them searchable, assigns tags and categories, and stores everything in a clean, queryable archive. No per-user fees. No storage limits beyond your own server’s disk. No vendor seeing your contracts.

In this guide, we’ll cover what Paperless-ngx does, how it compares to commercial alternatives, and how to deploy it with Docker in an afternoon.

What Paperless-ngx Actually Does

Paperless-ngx is a document management system built around a simple idea: documents should be searchable, organized, and stored on infrastructure you control. It was forked from the original Paperless project (which went dormant) and has become the de facto open-source standard for small-business and personal document management, with an active community and regular releases.

Here’s what it does out of the box:

1. Document Ingestion

Paperless-ngx accepts documents from multiple sources:

• Consume folder: Drop a PDF or image into a watched directory, and Paperless picks it up automatically. This is how most scanner integrations work — your multifunction printer scans to a network share, Paperless sees the file, and the rest is automatic.
• Email integration: Point Paperless at an email account (via IMAP), and it will monitor incoming messages, download attachments, and ingest them. Set rules so only messages from specific senders or with specific subjects are processed. This is perfect for vendor invoices that arrive as email attachments.
• Web upload: Drag and drop files directly through the Paperless web interface. Useful for one-off documents or when you’re cleaning out a filing cabinet.
• API: For the technically inclined, Paperless has a REST API. You can push documents programmatically from other systems — an n8n workflow, a script, or another application.

Supported formats include PDF, PNG, JPEG, TIFF, and even HEIC (Apple’s image format). If it’s a document, Paperless can probably handle it.

2. OCR and Full-Text Search

This is where Paperless earns its keep. Every document that enters the system runs through Tesseract OCR — the same open-source OCR engine we’ve recommended in our accounting automation and legal document posts. Tesseract extracts the text from scanned images and PDFs, making everything searchable.

That means you can search for “Acme Corporation” and find every document — invoices, contracts, correspondence — that mentions that name, regardless of whether it was a born-digital PDF or a blurry scan of a faxed purchase order. The OCR supports over 100 languages, and you can configure multiple languages simultaneously if your business deals with multilingual documents.

The search is fast. Paperless uses Whoosh (a Python search library) for full-text indexing, and searches return results in milliseconds across thousands of documents.

3. Automatic Classification

Here’s the feature that surprises people: Paperless can automatically tag, categorize, and assign correspondents to documents based on their content. You define rules — called “matching algorithms” — and Paperless applies them to every new document.

For example:

• Any document containing the words “invoice” and “Acme Corp” gets the tag “Invoice,” the correspondent “Acme Corporation,” and the document type “Invoice.”
• Anything from the email address tax@irs.gov gets the tag “Tax” and is filed under the “Government” document type.
• Documents mentioning “certificate of insurance” are automatically tagged “Insurance” and assigned the storage path “Insurance / 2026.”

Three matching algorithms are available:

You can combine tags, correspondents, document types, and storage paths in a single matching rule. Once you’ve tuned your rules over the first few weeks, most documents are filed correctly without any human intervention.

4. Document Organization

Paperless organizes documents through four main constructs:

• Correspondents: Who sent or is associated with the document (e.g., “Acme Corporation,” “City Water Department,” “Jane Doe”).
• Document Types: What kind of document it is (e.g., “Invoice,” “Contract,” “Receipt,” “Tax Form”).
• Tags: Flexible labels for anything else (e.g., “Urgent,” “Q4 2026,” “Pending Signature”).
• Storage Paths: Where the document’s original file lives on disk (e.g., “Contracts/2026/” or “Tax/2026/”).

Every document can have multiple tags, one correspondent, one document type, and one storage path. The combination gives you powerful filtering: “Show me all invoices from Acme Corporation tagged ‘Q4 2026’” is a two-click query.

5. Retention Policies

For businesses that need to retain documents for specific periods (tax records for seven years, employment records for varying durations depending on jurisdiction), Paperless supports retention policies. You can set rules like “delete receipts after 3 years” or “archive tax forms after 7 years.” The policies apply based on document type and tags, so you can be as specific as you need.

This matters more than people realize. Holding onto documents longer than necessary creates clutter and, in some cases, legal risk (keeping records you were supposed to destroy). Holding them for less time than required creates compliance risk. Paperless lets you set it once and forget it.

Paperless-ngx vs. Commercial Document Management

Let’s be honest about the comparison. Commercial document management systems — things like DocuWare, M-Files, or even the document features baked into SharePoint — have more features. They have workflow engines for approval processes, tighter integration with enterprise identity providers, and dedicated sales teams.

But for a small or medium business, those features often come at a cost that’s hard to justify. Here’s how the comparison actually shakes out:

The tradeoff is clear: Paperless-ngx gives you 80% of what most small businesses need from a document management system at 0% of the licensing cost. What you give up is workflow automation (which you can fill with n8n) and the polish of a commercial product. For a 5-to-50-person business that wants to stop losing documents and start searching their archive, that’s a trade worth making.

Deploying Paperless-ngx with Docker

Paperless-ngx is designed to be self-hosted, and the recommended deployment method is Docker Compose. You’ll need a server (a VPS with 2 vCPU and 4GB RAM is plenty for a small business), Docker, and Docker Compose installed.

Step 1: Create the Project Directory

mkdir -p /opt/paperless-ngx && cd /opt/paperless-ngx

Step 2: Create the Docker Compose File

version: "3.8"

services:
  broker:
    image: docker.io/library/redis:7
    restart: unless-stopped
    volumes:
      - redisdata:/data

  db:
    image: docker.io/library/postgres:16
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: paperless
      POSTGRES_PASSWORD: ${PAPERLESS_DB_PASSWORD}

  paperless:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: unless-stopped
    depends_on:
      - db
      - broker
    ports:
      - "8000:8000"
    volumes:
      - data:/usr/src/paperless/data
      - media:/usr/src/paperless/media
      - export:/usr/src/paperless/export
      - consume:/usr/src/paperless/consume
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBHOST: db
      PAPERLESS_DBNAME: paperless
      PAPERLESS_DBUSER: paperless
      PAPERLESS_DBPASS: ${PAPERLESS_DB_PASSWORD}
      PAPERLESS_SECRET_KEY: ${PAPERLESS_SECRET_KEY}
      PAPERLESS_URL: https://docs.yourbusiness.com
      PAPERLESS_OCR_LANGUAGE: eng
      PAPERLESS_CONSUMER_POLLING: 60
      PAPERLESS_CONSUMER_RECURSIVE: true
      PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS: true
      PAPERLESS_TIME_ZONE: America/New_York

volumes:
  data:
  media:
  pgdata:
  redisdata:
  export:
  consume:

Step 3: Create the Environment File

# .env file — keep this secret, don't commit it
PAPERLESS_DB_PASSWORD=change_this_to_a_strong_password
PAPERLESS_SECRET_KEY=change_this_to_a_random_50_char_string

Generate a strong secret key:

openssl rand -hex 24

Step 4: Start the Services

docker compose up -d

Step 5: Create Your Admin User

docker compose run --rm paperless manage createsuperuser

Follow the prompts to set your admin username and password.

Step 6: Set Up HTTPS with a Reverse Proxy

Paperless-ngx itself runs on port 8000 over HTTP. For production, you should put it behind a reverse proxy with TLS. Caddy is the simplest option — it handles HTTPS certificates automatically:

# Add to your Caddyfile or docker-compose
docs.yourbusiness.com {
    reverse_proxy paperless:8000
}

Caddy will automatically obtain and renew a Let’s Encrypt certificate. No manual cert management required.

Step 7: Start Scanning

Drop a PDF or image into the consume folder (or configure your scanner to save there), and within 60 seconds Paperless will pick it up, OCR it, and add it to your archive. Log into the web interface to review, tag, and organize.

Practical Workflows for Small Business

Here’s how businesses actually use Paperless-ngx day-to-day:

Invoice Processing

Configure Paperless to monitor the email account where vendor invoices arrive. Every PDF attachment gets ingested, OCR’d, and tagged as “Invoice” based on your matching rules. Your bookkeeper logs in once a week, reviews the tagged invoices, and exports them — or better yet, use n8n to push the extracted data into your accounting system.

Contract Management

Every signed contract gets uploaded (via scanner, email, or web interface). Tag by client name, contract type, and renewal date. When you need to review a contract before renewal, search by client name and filter by “Contract” — it’s a five-second lookup instead of a forty-minute dig through filing cabinets.

Tax Document Organization

Create a “Tax 2026” tag. Throughout the year, tag every tax-relevant document — 1099s, receipts for deductible expenses, property tax bills, charitable donation acknowledgments. When tax season arrives, filter by the tag and export everything for your accountant. Set a retention policy to archive the tag after seven years.

Employee Records

Onboarding paperwork, performance reviews, training certificates — all tagged by employee name and document type. Set retention policies based on your legal requirements. When an employee leaves, you know exactly where everything is and when it can be destroyed.

Integrating Paperless-ngx with Your Automation Stack

Paperless-ngx has a REST API, which means it plays well with the automation tools we’ve covered elsewhere on this blog. A few integration patterns:

Paperless + n8n + Ollama: When a new document is ingested, trigger an n8n workflow that sends the OCR’d text to a local LLM (via Ollama) for classification. The LLM can extract structured data — vendor name, invoice number, total amount, due date — and push it to your accounting system. This is a more sophisticated version of the keyword matching that Paperless does natively.

Paperless + n8n + notifications: Set up a webhook so that when a document matching certain criteria is added (e.g., a document tagged “Urgent”), n8n sends a notification to your team chat.

Paperless + Metabase: Export Paperless’s document metadata to a database and connect Metabase to visualize it — how many invoices per month, average processing time, document volume by correspondent. This gives you analytics on your document workflow.

Hardware Requirements and Performance

Paperless-ngx is not a heavy application. For a small business with a few thousand documents:

• CPU: 2 vCPU is sufficient. OCR is the most CPU-intensive task, and it’s parallelized.
• RAM: 4GB minimum. 8GB if you’re processing large batches of scanned documents.
• Storage: Plan for roughly 1–2MB per document (after compression). 10,000 documents = ~15GB. A 100GB disk gives you years of headroom.
• Database: PostgreSQL is recommended for any production deployment. SQLite works for testing but isn’t recommended for multi-user use.

OCR processing time depends on document length and CPU. A typical 5-page scanned invoice takes 10–20 seconds on a 2 vCPU server. Paperless processes documents asynchronously, so this doesn’t block the web interface.

Migration: Getting Your Existing Documents In

If you’re migrating from an existing system (filing cabinet, network drive, Google Drive export), the process is straightforward but takes time:

1. Scan paper documents. A sheet-fed scanner (anything from a $200 desktop scanner to a multifunction printer) can batch-scan years of paper. Save scans as PDF to the consume folder.
2. Batch import digital files. Paperless includes a document_importer management command that can ingest a directory of existing files, preserving creation dates from file metadata.
3. Clean up as you go. The first pass will have classification errors. Spend a week reviewing and correcting tags — your matching rules will improve as a result.

A realistic timeline: a small business with a filing cabinet and a few hundred digital documents can be fully migrated in a weekend. A larger archive (10,000+ documents) is a multi-week project, but you can do it incrementally — start using Paperless for new documents immediately, and backfill the archive over time.

Backups: Non-Negotiable

Paperless-ngx stores your documents on your server. That’s the whole point — your data, your control. But it also means you’re responsible for backups. A single disk failure without a backup means losing your entire document archive.

At minimum:

1. Back up the media volume (where document files are stored) daily. This is the irreplaceable data.
2. Back up the database (PostgreSQL) daily. This stores all metadata, tags, and search indices.
3. Store backups off-site. Use restic or borg to push encrypted backups to a separate location — a different VPS, an S3-compatible storage service like Backblaze B2 or MinIO.
4. Test your restores. A backup you’ve never restored is a hope, not a backup.

Paperless also has a built-in export feature (document_exporter) that creates a complete export of all documents and metadata. Schedule it weekly via cron and include the export in your backup routine.

Common Pitfalls

Underestimating OCR quality. Tesseract is good but not perfect. Handwritten notes, low-resolution scans, and documents with unusual fonts will produce OCR errors. Invest in a decent scanner — 300 DPI is the minimum for reliable OCR, 600 DPI is better for small text.

Over-tagging. It’s tempting to create a tag for every possible categorization. Resist. Start with 5–10 tags and 3–5 document types. You can always add more. Too many tags makes the system harder to use, not easier.

Ignoring the consume folder permissions. If your scanner saves files as one user but Paperless runs as another, file permission issues will silently prevent ingestion. Make sure the consume folder is writable by the Paperless container user.

No retention policy. Without one, your archive grows indefinitely. Set retention policies early, even if they’re conservative (e.g., “archive after 10 years”). You can tighten them later.

The Bottom Line

Paperless-ngx solves a problem that every business has and most businesses handle badly. Document chaos isn’t a technology problem — it’s a process problem that technology can fix. The question isn’t whether you need document management. You do. The question is whether you’ll pay a recurring subscription for a commercial product that holds your most sensitive documents, or whether you’ll spend an afternoon setting up an open-source system that gives you the same core capabilities on your own terms.

For most small and medium businesses, the answer is clear. Paperless-ngx gives you searchable, organized, automatically-classified document storage with no per-user fees, no storage limits, and no vendor looking at your files. Pair it with n8n for workflow automation and Ollama for intelligent classification, and you have a document management stack that rivals commercial systems at a fraction of the cost.

If you’d like help deploying Paperless-ngx or building a document automation workflow for your business, reach out through our contact form. We specialize in open-source automation for small and medium businesses — practical solutions, no vendor lock-in, your data stays yours.

Paperless-ngx is open-source software released under the GPL-3.0 license. It’s community-maintained and free to use. You can find the project documentation and source code at docs.paperless-ngx.com.

Tableau starts at $75 per user per month. Looker requires a conversation with sales before you even see a number. Power BI’s licensing tiers are a spreadsheet unto themselves. For a 10-person team that needs three dashboards, you’re looking at $2,000+ per year before anyone has built a single chart.

Metabase is the open-source alternative. It gives you visual dashboards, a no-code query builder, and native SQL access — all self-hosted, all yours, with zero per-user licensing. In this guide, we’ll walk through what Metabase does well, how to deploy it with Docker, and how to connect it to your existing data sources.

What Metabase Actually Does

Metabase is a business intelligence tool. You connect it to a database (PostgreSQL, MySQL, MongoDB, SQLite, and others), and it gives you two ways to explore that data:

1. A visual query builder — filter, group, and aggregate data without writing SQL. You pick a table, choose columns, apply filters, and Metabase generates the chart. This is what non-technical team members use day-to-day.

2. Native SQL editor — write your own queries, save them as reusable models, and build dashboards from the results. This is what your technical folks use for complex analysis.

The key feature that separates Metabase from a simple charting library is questions and dashboards. A “question” is any saved query — visual or SQL. A “dashboard” is a collection of questions arranged on a grid with filters that affect all questions at once. You build once, and your team interacts without touching the underlying query.

What It Does Not Do

Metabase is not an ETL tool. It reads from your database; it doesn’t transform or move data between systems. If your data lives in five different databases, you’ll need to consolidate it first (or connect Metabase to each one separately). For ETL, look at tools like n8n or Directus — we covered building data pipelines in a previous post.

Metabase also doesn’t do real-time streaming analytics. It queries your database on demand or on a refresh schedule (every hour, daily, etc.). For most small-to-medium businesses, that’s perfectly fine.

Metabase vs Other BI Tools

The Grafana comparison is worth clarifying. Grafana is excellent, but it’s designed for time-series monitoring — server metrics, application performance, IoT sensors. Metabase is designed for business data — sales, inventory, customer behavior. They overlap in capability but serve different primary use cases. Many businesses run both.

Deploying Metabase with Docker

The fastest way to get Metabase running is Docker. You’ll need Docker and Docker Compose installed on a server (a $10/month VPS is plenty for a small team). Here’s a complete docker-compose.yml:

version: "3.8"

services:
  metabase:
    image: metabase/metabase:latest
    container_name: metabase
    hostname: metabase
    ports:
      - "3000:3000"
    environment:
      - MB_DB_TYPE=postgres
      - MB_DB_DBNAME=metabase
      - MB_DB_PORT=5432
      - MB_DB_USER=metabase
      - MB_DB_PASS=change_this_password
      - MB_DB_HOST=metabase-db
    depends_on:
      - metabase-db
    restart: unless-stopped

  metabase-db:
    image: postgres:15-alpine
    container_name: metabase-db
    environment:
      - POSTGRES_USER=metabase
      - POSTGRES_PASSWORD=change_this_password
      - POSTGRES_DB=metabase
    volumes:
      - metabase-db-data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  metabase-db-data:

Save this as docker-compose.yml and run:

docker compose up -d

Metabase uses its own PostgreSQL database to store dashboards, saved questions, and user accounts — that’s the metabase-db service. The app itself runs on port 3000. Open http://your-server-ip:3000 in a browser and you’ll see the setup wizard.

Securing the Deployment

Running Metabase on port 3000 without TLS is fine for testing, but for production you should put it behind a reverse proxy with HTTPS. Here’s a minimal Caddy configuration:

analytics.yourcompany.com {
    reverse_proxy localhost:3000
}

Caddy automatically provisions and renews Let’s Encrypt certificates. Install Caddy, drop this config in /etc/caddy/Caddyfile, and restart. Your Metabase instance is now accessible over HTTPS at analytics.yourcompany.com — no certificate management required.

Authentication and Access Control

Metabase has built-in user management. During setup, you create an admin account. From the admin settings, you can:

• Create user accounts for each team member with email/password login
• Define groups (e.g., “Sales”, “Engineering”, “Leadership”)
• Set permissions per database, per table, or per saved question — control who can view, who can edit, and who sees raw data vs aggregated results
• Enable SSO via LDAP or SAML if you have an identity provider

For a small team, the default email/password auth is fine. For larger organizations, connect Metabase to your existing SSO provider so access is managed centrally.

Connecting Metabase to Your Data

Once Metabase is running, the real work begins: connecting it to your data sources. Here are the most common scenarios for small businesses:

Scenario 1: You Already Have a PostgreSQL Database

If your application (Odoo, Directus, a custom app) already uses PostgreSQL, Metabase can connect directly. In the admin settings:

1. Click Add Database
2. Select PostgreSQL
3. Enter the host, port, database name, username, and password
4. Metabase scans the schema and makes all tables available

That’s it. Your team can immediately start building charts from your production data.

Scenario 2: Your Data Is in a CSV or Spreadsheet

Metabase doesn’t connect directly to CSV files, but you can load them into a SQLite database in seconds:

# Install sqlite3 if needed
sudo apt install sqlite3

# Create a database from a CSV
sqlite3 mydata.db
.mode csv
.import sales_data.csv sales
.import customers.csv customers
.exit

Then run a temporary Metabase container with the SQLite file mounted:

docker run -d -p 3000:3000 \
  -v /path/to/mydata.db:/data/mydata.db \
  metabase/metabase:latest

In the Metabase admin settings, add a new database of type “SQLite” and point it to /data/mydata.db. Your spreadsheet data is now queryable with the full power of Metabase’s visualization engine.

Scenario 3: Multiple Data Sources

If your CRM is in PostgreSQL and your web analytics are in a separate database, connect Metabase to both. You’ll have two databases listed in Metabase, and you can build dashboards that pull from either — though cross-database queries aren’t supported natively. For unified reporting, consolidate your data into a single database using an ETL pipeline (n8n is excellent for this).

Building Your First Dashboard

Let’s walk through a practical example. Say you want a sales overview dashboard with three panels: revenue by month, top 10 customers, and order count by status.

Step 1: Connect Your Database

In the admin panel, add your PostgreSQL database. Metabase auto-detects tables and columns.

Step 2: Create a “Revenue by Month” Question

1. Click + New → Question
2. Select your database and the orders table
3. Choose Sum of total_amount
4. Group by created_at → Month
5. Pick a bar chart visualization
6. Save the question as “Revenue by Month”

Step 3: Create a “Top 10 Customers” Question

1. Click + New → Native Query
2. Write:

   SELECT c.name, SUM(o.total_amount) AS total_spent
   FROM orders o
   JOIN customers c ON o.customer_id = c.id
   GROUP BY c.name
   ORDER BY total_spent DESC
   LIMIT 10
   

3. Choose a horizontal bar chart
4. Save as “Top 10 Customers”

Step 4: Create an “Orders by Status” Question

1. Visual query builder → orders table
2. Count of rows
3. Group by status
4. Choose a pie or donut chart
5. Save as “Orders by Status”

Step 5: Assemble the Dashboard

1. Click + New → Dashboard
2. Name it “Sales Overview”
3. Add your three saved questions
4. Add a date filter that affects the Revenue question
5. Arrange the panels with drag-and-drop

The entire process takes about 15 minutes for a straightforward dashboard. Once saved, any team member with access can view it, and the data refreshes on every page load (or on the schedule you configure).

Automating Metabase with n8n

Metabase has a REST API that lets you programmatically query saved questions, trigger dashboard refreshes, and export results. Combined with n8n, you can build automated workflows like:

• Daily email report — every morning, n8n calls the Metabase API to fetch yesterday’s revenue numbers and emails a summary to the team
• Slack/Mattermost alert — when a saved question returns results below a threshold, n8n posts an alert to a channel
• Scheduled export — every Friday, n8n pulls a dashboard as CSV and uploads it to a shared drive

Here’s an example n8n workflow that sends a weekly Metabase summary via Mattermost:

{
  "trigger": "Every Monday at 8:00 AM",
  "steps": [
    {
      "action": "HTTP Request",
      "method": "GET",
      "url": "http://metabase:3000/api/card/42/query",
      "headers": { "X-Metabase-Session": "" }
    },
    {
      "action": "Set",
      "fields": {
        "revenue": "",
        "orders": ""
      }
    },
    {
      "action": "Mattermost",
      "message": "📊 Weekly Summary: Revenue $ from  orders."
    }
  ]
}

This pattern — Metabase for visualization, n8n for orchestration — gives you a BI platform that rivals commercial tools costing thousands per year, entirely on infrastructure you control.

Realistic Costs

Self-hosting isn’t free — you pay for the server. Here’s a realistic cost breakdown for a 10-person team:

Compare that to Tableau Creator at $75/user/month — for 10 users, that’s $750/month, or $9,000/year. The self-hosted Metabase setup costs under $250/year for the same team.

The trade-off is maintenance. You’re responsible for backups, updates, and security patches. This is real work, but it’s a few hours per quarter, not a full-time job. If that still feels like too much, Metabase also offers a cloud-hosted version starting at $85/month for 5 users — still significantly cheaper than Tableau, and with a clear upgrade path to self-hosting when you’re ready.

When to Choose Metabase (and When Not To)

Choose Metabase if:

• You have a database and want visual dashboards without per-user licensing
• Your team needs both no-code and SQL access to data
• You want to self-host for data sovereignty or compliance reasons
• You’re already using PostgreSQL, MySQL, or MongoDB

Consider alternatives if:

• You need real-time streaming analytics (look at Apache Superset with a columnar database)
• Your team has no one who can manage a Docker deployment (use Metabase Cloud or a managed alternative)
• You need pixel-perfect, branded report exports (Metabase’s exports are functional but not design-grade)
• Your data is primarily in spreadsheets and you don’t want to import it into a database (look at a tool like Grist, which works directly with spreadsheets)

Getting Started Checklist

1. [ ] Provision a VPS with at least 2 vCPU and 4GB RAM
2. [ ] Install Docker and Docker Compose on the server
3. [ ] Copy the docker-compose.yml from above and run docker compose up -d
4. [ ] Set up Caddy (or nginx) as a reverse proxy with HTTPS
5. [ ] Complete the Metabase setup wizard — create your admin account
6. [ ] Connect your first database — start with whatever has the most interesting data
7. [ ] Build your first dashboard — pick a question your team asks every week
8. [ ] Create user accounts for your team and assign them to groups
9. [ ] Set up a backup — at minimum, pg_dump the Metabase database daily
10. [ ] Schedule a review — after 30 days, check what dashboards are actually being used

Wrapping Up

Business intelligence doesn’t have to mean a five-figure annual contract. Metabase gives you the core capabilities — visual queries, SQL access, shared dashboards, user permissions — in a package you can deploy in an afternoon and run for the cost of a cheap server.

The combination of Metabase for analytics, n8n for automation, and tools like Ollama for AI creates a complete open-source business stack that replaces commercial alternatives at a fraction of the cost. You keep your data, you control your costs, and you’re never at the mercy of a pricing page change.

If you’d like help setting up Metabase or building a custom analytics dashboard for your business, reach out through our contact form. We specialize in open-source automation for small and medium businesses — no vendor lock-in, no surprise bills.

Want to see Metabase in action with your own data? ARDOT Consulting can help you deploy, configure, and connect your business systems. Contact us to schedule a free consultation.

The result is a daily ritual of manual data movement. You export a CSV from one system, clean it up in a spreadsheet, import it into another, and hope nothing changed in between. Your team spends hours every week acting as human data pipelines — copying, pasting, reformatting, and reconciling information between systems that should have been connected from the start.

This isn’t a technology problem. It’s a plumbing problem. And like most plumbing problems, the fix isn’t glamorous, but it changes everything once it works. This post is about building data pipelines with open source tools that connect your business systems automatically — no code, no per-connector SaaS fees, no data flowing through third-party clouds you don’t control.

What a Data Pipeline Actually Does

A data pipeline is a series of automated steps that move data from one place to another, optionally transforming it along the way. That’s it. The term sounds technical, but the concept is simple:

1. Extract — Pull data from a source (a CRM, a database, a spreadsheet, an API)
2. Transform — Change the data’s format, filter it, enrich it, or combine it with other data
3. Load — Put the data somewhere useful (another database, a dashboard, a report, a notification)

You might see this called ETL (Extract, Transform, Load) in enterprise contexts. The business version is simpler: “when something happens in System A, make sure System B knows about it.”

Here are some concrete examples of what this looks like in practice:

• New customer in CRM → invoice created in accounting — When a lead converts to a customer in your CRM, a draft invoice is automatically created in your accounting system with the correct billing details.
• Order placed on website → inventory updated in ERP — When an order comes through your e-commerce site, stock levels are decremented in your inventory management system and a reorder alert fires if stock drops below threshold.
• Support ticket closed → metrics updated on dashboard — When a support ticket is resolved, the resolution time is logged to a metrics database and a weekly performance dashboard updates automatically.
• Form submission → lead scored and routed — When someone fills out a contact form, their data is enriched with company information, scored against your ideal customer profile, and routed to the right salesperson.

Each of these pipelines replaces a manual process. Each one eliminates a class of errors — the wrong customer ID, the missed reorder, the forgotten follow-up. And each one can be built without writing a single line of code.

The Tool Stack

For data pipelines in a small business context, you need three components:

n8n is the backbone here. We’ve covered it extensively in previous posts, but the short version: it’s a self-hosted workflow automation tool with a visual builder. You drag nodes onto a canvas, connect them, and configure each one. It has built-in connectors for hundreds of tools — CRMs, accounting software, databases, email platforms, messaging apps — and supports custom HTTP requests for anything it doesn’t cover natively.

The key advantage over SaaS alternatives like Zapier is that n8n runs on your own server. There are no per-task fees (Zapier charges $0.01–$0.06 per task on paid plans, which adds up fast for high-volume pipelines). There are no limits on the number of active workflows. And your data flows through infrastructure you control, not through a third-party cloud that could change its pricing, terms, or data handling policies at any time.

A Real Pipeline: CRM to Accounting

Let’s build a real pipeline step by step. This is one of the most common integration needs: syncing customer data from a CRM to an accounting system so that invoices are created with correct billing information. We’ll use Odoo (self-hosted CRM) as the source and a generic accounting API as the destination, but the pattern works with any pair of systems.

Step 1: Set Up the Trigger

In n8n, create a new workflow. The first node is the trigger — the event that starts the pipeline. For a CRM-to-accounting sync, you want the pipeline to fire whenever a new customer is created:

Trigger: Webhook from Odoo
- Listen for: contact.created event
- Authentication: API key (stored in n8n credentials)
- Output: JSON with customer name, email, address, tax ID

Odoo’s webhook system sends a POST request to your n8n instance whenever a new contact is created. n8n receives the payload and passes it to the next node.

If your source system doesn’t support webhooks, you can use a scheduled trigger instead — n8n checks for new records every 15 minutes and processes any that haven’t been synced yet. The tradeoff: webhooks are real-time but require the source system to support them; polling is slower but works with any system that has an API.

Step 2: Transform the Data

The customer record from Odoo probably doesn’t match the format your accounting system expects. Field names differ, address components are structured differently, and some fields need to be calculated. This is the transform step.

In n8n, add a Set node (for field mapping) and a Function node (for any logic):

Set Node: Map Fields
- company_name → customer_name
- email → billing_email
- street + city + zip → billing_address (combined)
- vat_number → tax_id

Function Node: Validate
- Check that customer_name is not empty
- Check that billing_email is a valid format
- Check that tax_id matches expected pattern
- If any check fails, route to error handling node

This is where most pipelines spend their complexity. Data transformation is unglamorous but critical — garbage in, garbage out applies at every stage. The validation step is especially important: if a customer record is missing a required field, you want to catch it here and alert a human, not create a broken invoice downstream.

Step 3: Check for Duplicates

Before creating a new record in the accounting system, check whether one already exists. This prevents duplicate customers and invoices — a common problem when pipelines run on schedules and process the same records multiple times:

HTTP Request Node: Search Existing Customer
- Method: GET
- URL: https://accounting.example.com/api/customers?email={billing_email}
- If response contains a customer → skip creation, optionally update
- If response is empty → proceed to creation

Step 4: Load the Data

Now create the customer record in the accounting system:

HTTP Request Node: Create Customer
- Method: POST
- URL: https://accounting.example.com/api/customers
- Body: {
    "customer_name": "",
    "billing_email": "",
    "billing_address": "",
    "tax_id": ""
  }
- Headers: Authorization: Bearer {api_key}

Step 5: Log and Notify

The final step is logging and notification. You want a record of what the pipeline did, and you want to know if something went wrong:

PostgreSQL Node: Log Sync
- INSERT INTO sync_log (source, destination, record_id, status, timestamp)
- VALUES ('odoo', 'accounting', '', 'success', NOW())

IF Node: Check for Errors
- If error → Mattermost notification to #ops channel
- If success → no notification (silent on success)

The full pipeline looks like this:

[Odoo Webhook] → [Map Fields] → [Validate] → [Search Existing] → [Create Customer] → [Log Sync]
                                                                         ↓
                                                                  [Error Handler] → [Mattermost Alert]

That’s a complete data pipeline. It runs automatically, retries on failure, logs every action, and alerts a human only when something goes wrong. Once it’s built, you never think about it again — which is the whole point.

When to Add AI to the Pipeline

Not every pipeline needs AI. The CRM-to-accounting sync above is pure rule-based logic — no AI required. But some transformations benefit from intelligence:

• Categorizing free-text data — A support ticket’s subject line needs to be mapped to a product category. Rules can’t handle the variety; an LLM can.
• Enriching incomplete records — A customer gives you a company name but no industry code. An LLM can infer the industry from the name and public data.
• Sentiment analysis — You want to route customer feedback to different teams based on whether it’s positive, negative, or neutral.
• Entity extraction — You need to pull names, dates, and amounts from unstructured email bodies and turn them into structured fields.

For these cases, add an Ollama node to the pipeline. Ollama runs a local LLM on your server, processes the data in memory, and returns structured output — without sending anything to an external API:

Ollama Node: Categorize Ticket
- Model: qwen2.5:7b
- Prompt: "Categorize this support ticket into one of: Billing, Technical, 
  General Inquiry, Complaint. Ticket subject: . 
  Respond with only the category name."
- Output: category field added to the record

The key principle: use AI where judgment is needed, use rules where logic is sufficient. Most pipelines are 90% rules and 10% AI. Don’t reach for an LLM when a simple if-statement will do.

Pipeline Patterns That Work

Over many implementations, a few patterns consistently deliver value. Here are the ones worth building first:

The Sync Pipeline

Keep two systems in sync so that a change in one propagates to the other. This is the most common pattern. Example: customer contact details updated in CRM → updated in accounting → updated in mailing list. The pipeline runs on a webhook trigger (real-time) or a schedule (every 15 minutes).

The Aggregation Pipeline

Pull data from multiple sources, combine it, and load it into a single dashboard or report. Example: daily sales from your e-commerce platform, daily expenses from your accounting system, and daily website traffic from your analytics tool → combined into a single daily business summary delivered to your inbox every morning at 7 AM.

The Alerting Pipeline

Monitor a data source for specific conditions and notify a human when they’re met. Example: inventory levels checked every hour → if any product drops below reorder threshold → notification sent to purchasing team with a draft purchase order. The pipeline doesn’t replace human decision-making; it surfaces the information that needs a decision.

The Onboarding Pipeline

When a new customer, employee, or project is created, trigger a series of steps across multiple systems. Example: new employee in HR system → account created in email platform → access granted to project management tool → welcome email sent → equipment request submitted to IT. One trigger, many downstream actions.

Common Pitfalls

A few things tend to go wrong when businesses first start building data pipelines:

Not handling failures gracefully. A pipeline that fails silently is worse than no pipeline at all — you think the data is synced, but it isn’t. Every pipeline needs error handling: retry logic, logging, and human notification on persistent failure. n8n handles retries natively, but you need to configure the notification step yourself.

Over-transforming data. It’s tempting to clean, enrich, and restructure data at every step. But each transformation adds complexity and potential failure points. Transform only what’s necessary to make the data usable at the destination. If the destination system can handle the raw data, let it.

Ignoring data volume. A pipeline that processes 10 records a day works fine with a simple sequential flow. A pipeline that processes 10,000 records a day needs batching, parallel processing, and rate limiting. Build for your current volume, but know where the breaking point is.

No monitoring. Pipelines degrade over time. APIs change, data formats drift, rate limits shift. Set up a simple dashboard that shows pipeline run counts, success rates, and processing times. If a pipeline that usually runs 50 times a day suddenly runs 3, you want to know immediately.

The Cost Question

A self-hosted data pipeline stack costs roughly:

The equivalent SaaS setup — Zapier for workflow automation, a cloud CRM, a cloud accounting tool with API access — typically runs $200–$500/month for a small team, with per-task fees that scale with usage. The open source stack costs a fraction of that, runs on infrastructure you control, and has no per-task limits.

Where to Start

Don’t try to connect everything at once. Pick the single most painful manual data transfer in your business — the one that someone does every day, takes 20+ minutes, and is error-prone. Build that pipeline first. Get it running reliably for two weeks. Then pick the next one.

The first pipeline is the hardest because you’re learning the tools. The second is easier. By the fifth, you have patterns to copy and the whole process takes an afternoon instead of a week. This is how automation compounds — not in one dramatic transformation, but in a series of pipelines that each remove a small piece of manual work until one day you realize your team hasn’t exported a CSV in months.

Your business data shouldn’t require human beings to copy and paste it between systems. ARDOT Consulting designs and builds self-hosted data pipelines using open-source tools — connecting your CRM, accounting, inventory, and analytics without per-task fees or vendor lock-in. Get in touch and we’ll map out the pipelines that would save your team the most time.

If you’ve ever posted a job opening and watched 300 resumes flood your inbox within 48 hours, you know the problem. Someone has to read every single one. Someone has to schedule phone screens with the promising candidates. Someone has to chase down offer letters, tax forms, and policy acknowledgments. And that someone is usually you — or an HR team already drowning in other work.

Human resources is one of the most automation-friendly functions in any business. The processes are repetitive, document-heavy, and rule-based. But HR is also where data privacy matters most. Resumes contain personal information. Onboarding involves tax documents and identification. Sending all of that to a third-party AI service isn’t just expensive — it’s a compliance risk.

That’s where open source AI tools change the equation. You can run the entire pipeline on your own infrastructure: resume parsing with local AI models, automated screening with custom criteria, interview scheduling that syncs with your calendar, and onboarding workflows that generate and track paperwork automatically. No data leaves your servers.

This guide walks through how to build that pipeline using tools you can self-host today.

The HR Automation Landscape

Before diving into implementation, let’s map the territory. A typical hiring process has five stages, and each one has automation potential:

The goal isn’t to remove humans from hiring. It’s to remove the paperwork and scheduling friction so your team can focus on the parts that actually require judgment — interviews, culture fit, and final decisions.

Tool Stack Overview

Here’s what we’ll use and why:

All five can run on a single server with 16GB RAM. Ollama is the heaviest component — it needs a GPU for fast inference, but CPU-only mode works fine for the batch processing that resume screening involves.

Stage 1: Resume Screening with Ollama

The first bottleneck in any hiring process is resume triage. When you get 200 applications for one role, reading them all is a full day’s work. Here’s how to automate it.

Setting Up the Parser

First, install Ollama and pull a model suitable for text analysis:

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a model — Qwen2.5 works well for structured extraction
ollama pull qwen2.5:7b

Next, write a prompt that extracts structured data from each resume. The key is to ask for JSON output with consistent fields:

import json
import subprocess

def screen_resume(resume_text, job_description):
    prompt = f"""
You are an HR assistant. Evaluate this resume against the job description.
Return a JSON object with these fields:
- name: candidate name
- email: contact email
- years_experience: estimated years of relevant experience
- skills_matched: list of required skills found
- skills_missing: list of required skills not found
- score: 0-100, how well the resume matches the job
- summary: 2-3 sentence assessment
- recommendation: "interview", "maybe", or "reject"

Job Description:
{job_description}

Resume:
{resume_text}
"""
    result = subprocess.run(
        ["ollama", "run", "qwen2.5:7b", prompt],
        capture_output=True, text=True, timeout=60
    )
    return json.loads(result.stdout.strip())

# Example usage
resume = open("candidate_resume.txt").read()
job = open("job_description.txt").read()
evaluation = screen_resume(resume, job)
print(f"{evaluation['name']}: Score {evaluation['score']} — {evaluation['recommendation']}")

Batch Processing with n8n

Running this one resume at a time is fine for testing, but for production you want a workflow. Here’s how to build it in n8n:

1. Trigger node: Watch an email inbox (or a shared drive folder) for new resume attachments
2. PDF extraction node: Use a function node with pdfplumber to extract text from PDF resumes
3. Ollama node: Send the extracted text to your local Ollama instance via HTTP request
4. Directus node: Store the parsed candidate data in your Directus database
5. Filter node: Route candidates based on score — above 80 goes to “interview,” 60-80 goes to “maybe,” below 60 gets a polite rejection
6. Mattermost node: Post high-scoring candidates to a #hiring channel for the team to review

Here’s the HTTP request configuration for the Ollama node:

{
  "method": "POST",
  "url": "http://localhost:11434/api/generate",
  "headers": { "Content-Type": "application/json" },
  "body": {
    "model": "qwen2.5:7b",
    "prompt": "=",
    "format": "json",
    "stream": false
  }
}

The format: "json" parameter tells Ollama to return valid JSON, which makes parsing reliable. No more guessing where the model’s output starts and ends.

Handling Bias and Fairness

This is where you need to be careful. An LLM can inherit biases from its training data — it might score resumes from certain universities higher, or penalize career gaps. Here are practical mitigations:

• Strip identifying information before scoring. Remove name, address, and university names from the resume text before sending it to Ollama. This forces the model to evaluate skills and experience only.
• Use the model as a triage tool, not a final decision-maker. Have it sort candidates into buckets (strong match, possible match, likely not a fit) but always have a human review the “maybe” pile.
• Audit periodically. Every few weeks, manually review 20 randomly selected resumes that the model scored. Check whether the scoring aligns with your actual hiring outcomes.

def anonymize_resume(text):
    """Remove identifying info before AI screening."""
    import re
    # Remove email addresses
    text = re.sub(r'\S+@\S+', '[EMAIL]', text)
    # Remove phone numbers
    text = re.sub(r'\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}', '[PHONE]', text)
    # Remove names (common patterns at top of resume)
    text = re.sub(r'^[A-Z][a-z]+ [A-Z][a-z]+', '[NAME]', text)
    return text

Stage 2: Automated Interview Scheduling

Once you’ve identified candidates worth interviewing, the scheduling dance begins. “Are you available Tuesday at 2?” “No, how about Wednesday morning?” “I have a meeting then…” — this back-and-forth wastes hours.

Cal.com Integration

Cal.com is an open-source scheduling tool you can self-host. It lets candidates book time slots directly, eliminating the email tennis match.

Here’s the setup:

1. Install Cal.com via Docker: ```yaml

   docker-compose.yml (simplified)

   version: “3.8” services: calcom: image: calcom/cal.com:latest ports:

   • “3000:3000” environment:
   • DATABASE_URL=postgresql://calcom:password@db:5432/calcom
   • NEXTAUTH_SECRET=your-secret-here depends_on:
   • db db: image: postgres:16 environment:
   • POSTGRES_USER=calcom
   • POSTGRES_PASSWORD=password
   • POSTGRES_DB=calcom ```

2. Create event types for different interview stages: 15-minute phone screen, 45-minute technical interview, 30-minute culture fit call.

3. Connect to n8n: When Cal.com receives a booking, it sends a webhook to n8n. The workflow then:
   • Creates a candidate record in Directus (or updates an existing one)
   • Sends a confirmation email to the candidate
   • Notifies the interviewer via Mattermost
   • Generates a interview prep sheet by pulling the candidate’s parsed resume data
4. Automated reminders: n8n sends a reminder 24 hours before the interview to both the candidate and the interviewer, with the video link and the candidate’s summary.

The n8n Workflow for Scheduling

Here’s what the webhook-triggered workflow looks like:

Cal.com Webhook → 
  Filter (event_type = "phone_screen") → 
    Directus (update candidate status to "scheduled") →
      Email (send confirmation to candidate) →
        Mattermost (notify interviewer with prep sheet) →
          Schedule (set reminder for 24h before)

The interview prep sheet is generated by sending the candidate’s parsed resume data back to Ollama with a prompt like: “Generate 5 interview questions tailored to this candidate’s background and the job requirements.”

Stage 3: Onboarding Automation

Onboarding is where automation delivers the most time savings. A new hire requires 15-30 administrative tasks across different systems — and missing one can mean compliance issues or a poor first-day experience.

Building the Onboarding Workflow

Here’s a comprehensive n8n workflow that triggers when a candidate is marked as “hired” in Directus:

Directus (status = "hired") →
  ┌─ Email (welcome email with first-day instructions)
  ├─ Directus (create employee record)
  ├─ Document Generation (offer letter, NDA, tax forms)
  ├─ Cal.com (schedule orientation sessions)
  ├─ Mattermost (create #welcome-[name] channel, notify team)
  ├─ Odoo (create HR record, assign to department)
  └─ Schedule (day-1, day-7, day-30 check-in reminders)

Document Generation

Onboarding paperwork is a perfect candidate for automation. Most offer letters, NDAs, and policy acknowledgments are template documents with variable fields (name, start date, salary, role). Here’s how to generate them automatically:

from docx import Document
from datetime import datetime

def generate_offer_letter(candidate_data, template_path="templates/offer_letter.docx"):
    doc = Document(template_path)
    
    replacements = {
        "": candidate_data["name"],
        "": candidate_data["position"],
        "": f"${candidate_data['salary']:,}",
        "": candidate_data["start_date"],
        "": datetime.now().strftime("%B %d, %Y"),
    }
    
    for paragraph in doc.paragraphs:
        for key, value in replacements.items():
            if key in paragraph.text:
                paragraph.text = paragraph.text.replace(key, value)
    
    output_path = f"output/offer_letter_{candidate_data['name'].replace(' ', '_')}.docx"
    doc.save(output_path)
    return output_path

# Example
candidate = {
    "name": "Jane Smith",
    "position": "Operations Manager",
    "salary": 75000,
    "start_date": "October 15, 2026"
}
path = generate_offer_letter(candidate)
print(f"Offer letter generated: {path}")

In n8n, this runs as a function node. The generated document gets stored in Directus and emailed to the candidate for e-signature.

The 30-60-90 Day Check-In

Onboarding doesn’t end on day one. A good process includes check-ins at 30, 60, and 90 days. n8n can automate these:

• Day 30: Send a structured feedback form to the new hire and their manager. Use Ollama to summarize the responses and flag any concerns.
• Day 60: Schedule a one-on-one via Cal.com. Send the manager a summary of the 30-day feedback.
• Day 90: Generate a probationary review document. If both the manager and employee responses are positive, trigger the “confirm permanent role” workflow. If concerns are flagged, alert HR for a manual review.

Schedule (30 days after start) →
  Email (send feedback form to employee) →
  Email (send feedback form to manager) →
  Wait (7 days) →
  Ollama (summarize responses, flag concerns) →
  Directus (store review) →
  Mattermost (notify HR if concerns flagged)

Measuring the Impact

How much time does this actually save? Let’s break it down with realistic numbers for a company hiring 2-3 people per month:

27 hours per month — that’s more than three full work days reclaimed. For a solo HR person or a business owner handling hiring themselves, that’s the difference between drowning and staying afloat.

And that’s before counting the qualitative improvements: faster response times to candidates (better hiring outcomes), no missed onboarding steps (better retention), and consistent processes (easier compliance).

Getting Started: A Minimal Viable Pipeline

You don’t need to build everything at once. Here’s a pragmatic rollout:

Week 1: Install Ollama and test resume screening with 10 sample resumes. Tune the prompt until the scoring matches your judgment.

Week 2: Set up n8n and connect it to your email inbox. Automate resume intake — even if you just use it to sort candidates into folders, that alone saves hours.

Week 3: Install Cal.com and create interview slots. Replace email-based scheduling with self-serve booking.

Week 4: Build the onboarding workflow. Start with just the welcome email and document generation. Add the 30-60-90 day check-ins in week 5.

The beauty of this stack is that each piece works independently. You can adopt them one at a time and still see immediate benefits.

Common Pitfalls

Over-automating rejection emails. Candidates talk. If every rejection is an obviously automated template, your employer brand suffers. Use Ollama to draft personalized rejection emails that reference something specific from the candidate’s resume, and have a human review them before sending — or at least the ones for candidates who made it to the interview stage.

Ignoring data retention. Resumes contain personal data. In many jurisdictions, you’re legally required to delete candidate data after a certain period (6-24 months depending on your location). Build a n8n workflow that automatically purges rejected candidate records from Directus after your retention period expires.

Treating AI scores as gospel. The Ollama model will occasionally score a great candidate low because their resume uses different terminology than the job description. Always have a human skim the top 20% of the “maybe” pile. The model is a filter, not an oracle.

Forgetting the candidate experience. Automation should make things faster for candidates too, not just for you. Automated confirmations, clear next steps, and timely updates (even automated ones) make candidates feel respected. Ghosting — even automated ghosting — damages your reputation.

Conclusion

HR automation isn’t about replacing human judgment in hiring. It’s about removing the administrative weight that makes hiring painful. When your team spends 27 fewer hours per month on paperwork and scheduling, they can spend that time actually talking to candidates, evaluating culture fit, and making better hiring decisions.

The open source stack — n8n, Ollama, Cal.com, Directus, Mattermost — gives you enterprise-grade automation without sending sensitive employee data to third-party servers. You own the infrastructure. You control the data. You set the rules.

Start small. Automate resume screening first. Then scheduling. Then onboarding. Each step compounds, and within a month you’ll have a hiring process that feels less like administrative drudgery and more like what HR is supposed to be: finding the right people and helping them succeed.

Want help setting up an automated HR pipeline for your business? ARDOT Consulting specializes in open source AI automation for small and mid-size businesses. Contact us to schedule a free consultation — we’ll map your current hiring process and show you exactly where automation can save you time.

The standard advice is “use a smart inbox” — Superhuman, SaneBox, one of the dozens of AI email tools that charge $15–$30 per user per month and, critically, require you to pipe your entire email history through their servers. For a solo operator that’s an annoying cost. For a law firm, a financial advisory, a healthcare practice, or any business that handles sensitive client communications, it’s a non-starter. Your email contains contracts, client data, financial documents. Sending it to a third-party SaaS to be categorized is a privacy decision dressed up as a productivity one.

This guide walks through a different approach: a self-hosted email triage system built with Ollama (for local AI) and n8n (for workflow automation) that reads your inbox, categorizes each message, prioritizes what matters, and drafts replies — all on your own server. No API fees. No data leaving your infrastructure. No per-seat pricing. You can run it on a $40/month VPS for the whole company.

What We’re Building

The goal isn’t to replace your email client. It’s to add a layer on top of it that does the triage work for you. Specifically, the system will:

1. Check your inbox on a schedule (every 10–15 minutes via IMAP)
2. Read each new message and classify it into a category — Support Request, Client Communication, Invoice/Payment, Internal, Newsletter/Promotional, or Urgent
3. Assign a priority (High, Medium, Low) based on the sender, content, and urgency signals
4. Move or tag the email in your mailbox so your inbox only shows what actually needs your attention
5. Draft a suggested reply for messages that need a response, stored alongside the email for your review

The AI processing happens locally via Ollama. The workflow orchestration happens in n8n. Your email stays on your mail server and your VPS — it never touches a third-party API.

Prerequisites

You’ll need:

• A VPS or local server with at least 8GB RAM (16GB recommended if you’re running a larger model). A basic Hetzner or OVH cloud server works fine. No GPU required — we’ll use a smaller, efficient model.
• Docker and Docker Compose installed
• An email account with IMAP access — this works with self-hosted mail servers (Mailcow, Poste.io, Postal) as well as standard IMAP providers
• About an hour to set everything up

Step 1: Set Up Ollama

If you followed our Ollama guide, you already have this. If not, the quick version:

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a model suitable for classification and short text tasks
ollama pull llama3.2:3b

# Verify it's running
ollama run llama3.2:3b "Say hello in one sentence."

We’re using Llama 3.2 3B here because email triage is a classification task, not a creative writing task. You don’t need a 70-billion-parameter model to figure out whether an email is an invoice or a newsletter. The 3B model runs comfortably on CPU, responds in under 2 seconds per email, and costs nothing per inference. If you have a GPU or more RAM, qwen2.5:7b will give you slightly better accuracy on ambiguous messages.

Step 2: Set Up n8n

Again, if you already have n8n running, skip ahead. For a fresh install via Docker Compose:

# docker-compose.yml
version: "3.8"
services:
  n8n:
    image: n8nio/n8n:latest
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=0.0.0.0
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=your-strong-password
    volumes:
      - n8n_data:/home/node/.n8n
    restart: unless-stopped

volumes:
  n8n_data:

docker compose up -d

Navigate to https://n8n.yourdomain.com/ (behind a reverse proxy with TLS — we recommend Caddy for automatic HTTPS) and log in.

Step 3: Build the Triage Workflow

This is the core of the system. In n8n, create a new workflow with these nodes:

Node 1: IMAP Trigger (Schedule)

Use the Email Read IMAP node (or the IMAP trigger in newer n8n versions):

• Host: imap.yourmailserver.com
• Port: 993
• SSL: enabled
• Username / Password: your email credentials
• Mailbox: INBOX
• Post Process: Mark as read — but don’t move or delete yet
• Schedule: every 15 minutes

This node polls your inbox at the interval you set and outputs one item per new unread message. Each item contains the subject, sender, body text, and date.

Node 2: HTTP Request → Ollama

Add an HTTP Request node that sends each email to your local Ollama instance for classification. Ollama exposes a simple REST API at http://localhost:11434/api/generate.

Configure it as a POST request:

• URL: http://host.docker.internal:11434/api/generate (or your Ollama server’s IP)
• Method: POST
• Body (JSON):

{
  "model": "llama3.2:3b",
  "prompt": "You are an email triage assistant. Read the email below and respond with ONLY a JSON object, no markdown, no explanation.\n\nEmail Subject: \nEmail Sender: \nEmail Body: \n\nRespond in this exact format:\n{\"category\": \"<one of: Support Request, Client Communication, Invoice/Payment, Internal, Newsletter/Promotional, Urgent>\", \"priority\": \"<one of: High, Medium, Low>\", \"needs_reply\": <true or false>, \"suggested_reply\": \"<a brief professional reply if needs_reply is true, otherwise empty string>\", \"summary\": \"<one sentence summary>\"}",
  "stream": false,
  "options": {
    "temperature": 0.3
  }
}

A few notes on the prompt:

• Temperature 0.3 keeps the model’s output consistent. You don’t want creative variation in a classification task — you want the same email to get the same category every time.
• Truncating the body to 2000 characters keeps inference fast and avoids context limits. For 95% of emails, the first paragraph plus the subject is enough to classify correctly.
• The strict JSON-only instruction is important. Llama 3.2 will sometimes wrap output in markdown code fences. Adding “no markdown, no explanation” and parsing defensively (stripping ```json fences if present) handles the edge cases.

Node 3: Parse the JSON Response

Add a Code node (JavaScript) to parse Ollama’s response and handle any formatting quirks:

let rawResponse = $input.first().json.response;
let parsed;

try {
  // Strip markdown code fences if the model added them
  let cleaned = rawResponse.replace(/```json\n?/g, '').replace(/```/g, '').trim();
  parsed = JSON.parse(cleaned);
} catch (e) {
  // Fallback: treat as uncategorized
  parsed = {
    category: 'Uncategorized',
    priority: 'Medium',
    needs_reply: false,
    suggested_reply: '',
    summary: 'Could not parse AI response'
  };
}

return {
  json: {
    ...parsed,
    original_subject: $items('Email Read IMAP')[0].json.subject,
    original_from: $items('Email Read IMAP')[0].json.from.value[0].address,
    message_id: $items('Email Read IMAP')[0].json.messageId
  }
};

Node 4: Route Based on Category

Add an IF node (or Switch node) to route each email based on its category. Here’s where you decide what actually happens:

The “move” action uses the Email Move node (or IMAP Move) in n8n. The notifications use the Slack or Matrix node — we recommend Matrix if you want to keep your internal messaging self-hosted too.

Node 5: Save Draft Replies (Optional)

For emails where needs_reply is true, you can store the suggested reply rather than sending it automatically. We recommend never auto-sending — the AI draft should go into a review queue. You can:

• Save the draft to a Directus collection (a self-hosted headless CMS) for a simple review dashboard
• Append it to a shared Nextcloud Notes or Markdown file
• Send it to a dedicated Drafts mailbox folder for review in your email client

The point is that the AI does the first draft — the slow part — and you do the final review and send. This is the right division of labor. The AI saves you 80% of the effort; you keep 100% of the accountability.

Step 4: Test and Tune

Before turning this loose on your real inbox, test it. Create a test mailbox, forward a sampling of real emails into it, and run the workflow manually. Check:

• Classification accuracy: Are invoices going to Finance? Are newsletters getting filtered out? Watch for false positives — a client email that gets categorized as “Newsletter” because it contains the word “update.”
• Reply quality: Read the suggested replies. If they’re too generic or too confident, adjust the prompt. Adding “If unsure whether a reply is needed, set needs_reply to false” reduces over-eager drafting.
• Speed: With Llama 3.2 3B on CPU, each email takes 1–3 seconds to process. If you get 50 emails overnight, that’s under 2 minutes of processing — well within a 15-minute polling interval.

A common tuning issue: the model may misclassify transactional emails (order confirmations, shipping notifications) as “Support Request.” Fix this by adding to the prompt: "Transaction confirmations and shipping notifications are NOT support requests — categorize them as Newsletter/Promotional unless there's a problem indicated." Prompt refinement is an iterative process. Budget an hour for it.

What This Costs

Let’s be concrete:

Compare that to a SaaS email tool at $20/user/month. For a 10-person team, that’s $200/month versus $15. And the SaaS version reads every email you send it. The self-hosted version never lets a message leave your network.

What This System Does — and Doesn’t — Do

It does:

• Sort your inbox automatically so you only see what needs a human
• Flag urgent messages so they don’t get lost
• Draft first-pass replies to save you the blank-page problem
• Keep all processing on infrastructure you control

It doesn’t:

• Send replies on your behalf (and it shouldn’t — that’s a trust boundary you don’t want to cross)
• Handle complex multi-thread negotiations (those still need a human reading the full context)
• Replace your email client (it works alongside it, organizing what’s already there)
• Work without a mail server that supports IMAP (most do, but check yours)

The system is a triage layer, not an autoresponder. Think of it as a really fast assistant who pre-sorts your mail and writes draft responses on a notepad for you to review. The assistant never sends anything. You stay in control.

When to Use Cloud AI Instead

There’s one honest caveat: if you’re processing thousands of emails per day (a large customer service operation, for example), local inference on CPU may be too slow. At that volume, a GPU server or a cloud inference provider makes economic sense. But for a small business handling 50–200 emails a day — which is most of you reading this — a $10/month VPS with Ollama handles it comfortably.

The other scenario where cloud APIs make sense is if you need a very large model for nuanced classification (legal correspondence, for instance, where the difference between “this is a standard update” and “this is a deadline notice” matters a lot). In that case, running a 70B model locally requires serious hardware. But for standard business email — invoices, support, newsletters, client check-ins — a 3B model is more than enough.

A Note on Privacy

This is the part that matters most and gets talked about least. Every email you send to a SaaS email tool is stored on their servers, often used to train or improve their models, and covered by their privacy policy — which can change. You have no audit trail. You can’t inspect what they do with your data.

When you self-host with Ollama, your emails are processed in memory on a server you control and then discarded. There’s no training data retention. There’s no third party with a copy. For businesses in regulated industries — legal, healthcare, finance — this isn’t a nice-to-have. It’s the difference between a defensible compliance posture and a liability.

Getting Started

If you already have n8n and Ollama running from our previous guides, this workflow takes about 45 minutes to build. If you’re starting from scratch, budget an afternoon for the full stack setup. Either way, the payoff is immediate: the first morning after you turn it on, you’ll open your inbox to find it already sorted, with draft replies waiting for the messages that need them.

Email triage is one of the highest-ROI automations a small business can build. It touches every employee, every day, and the manual version of it is pure overhead — work that has to happen but creates no value. Automating it doesn’t just save time. It removes a daily source of friction that makes people dread opening their inbox.

Want help setting up an email triage system tailored to your business? ARDOT Consulting builds self-hosted automation workflows using open-source tools — no vendor lock-in, no per-seat fees, your data stays on your infrastructure. Get in touch and we’ll map out what’s possible for your team.

You don’t need a team of agents to handle these. You don’t need to pay $200/month for a SaaS chatbot platform that sends your customer conversations to a third-party server. And you don’t need to write a single line of Python.

In this guide, we’ll build a customer support chatbot using two open source tools — Ollama for the AI brain and n8n for the workflow glue — that runs entirely on your own server. No API fees. No data leaving your infrastructure. No vendor lock-in.

What We’re Building

Here’s the architecture at a glance:

Customer Message (Web/Email)
        │
        ▼
   ┌─────────┐
   │   n8n   │  ← Webhook receives message
   │ Workflow │
   └────┬────┘
        │
        ▼
   ┌─────────┐
   │ Ollama  │  ← Local LLM generates response
   │ (Llama  │    using your knowledge base
   │  3.2)   │
   └────┬────┘
        │
        ▼
   ┌─────────┐
   │   n8n   │  ← Sends response back to
   │ Workflow │    customer via web/email
   └─────────┘

The chatbot will:

1. Accept messages from a web widget or email
2. Check a knowledge base of your FAQ documents
3. Generate a helpful response using a local LLM
4. Escalate to a human when it’s not confident

Why Open Source for Customer Support?

Before we dive in, let’s address the elephant in the room. There are dozens of SaaS chatbot platforms — Intercom, Zendesk AI, Drift, Tidio. Why build your own?

The tradeoff is clear: a bit more setup work in exchange for lower costs, full data ownership, and no dependency on a vendor’s pricing decisions. For businesses handling sensitive customer information — healthcare, legal, finance — keeping data on your own server isn’t just cheaper. It’s often the legally safer option.

Prerequisites

You’ll need:

• A Linux server (VPS) with at least 8GB RAM and 4 CPU cores — a $20/month VPS from Hetzner, OVH, or DigitalOcean works fine
• Docker and Docker Compose installed
• Basic comfort with the terminal (copy-paste level)
• About 30 minutes of your FAQ and policy documents in text form

If you’ve never used Docker before, don’t worry — we’ll use docker-compose files that just work.

Step 1: Set Up Ollama

Ollama runs large language models locally. Think of it as a lightweight, self-hosted alternative to the OpenAI API — except there’s no API key, no per-token billing, and no data leaving your server.

Create a directory for your chatbot stack:

mkdir -p ~/support-bot && cd ~/support-bot

Create docker-compose.yml:

version: "3.8"

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped

volumes:
  ollama_data:

Start Ollama:

docker compose up -d

Now pull a model. For customer support, Llama 3.2 (3B parameter) is an excellent choice — it’s fast, capable enough for FAQ-style responses, and runs comfortably on 8GB RAM:

docker exec -it ollama ollama pull llama3.2

This downloads about 2GB and takes a few minutes. Once it’s done, verify the model works:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "What are your business hours?",
  "stream": false
}'

You should get a JSON response with a generated answer. Ollama is running.

Choosing the Right Model

Llama 3.2 (3B) is our default recommendation, but here’s how to decide if you need something bigger:

For most small business support bots, the 3B model is more than enough. You can always upgrade later by pulling a bigger model — no need to change your workflow.

Step 2: Set Up n8n

n8n is the workflow automation tool that ties everything together. It receives customer messages, sends them to Ollama, and returns the response.

Add n8n to your docker-compose.yml:

version: "3.8"

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped

  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    ports:
      - "5678:5678"
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=ChangeThisPassword123
      - WEBHOOK_URL=https://support.yourdomain.com/
    volumes:
      - n8n_data:/home/node/.n8n
    restart: unless-stopped

volumes:
  ollama_data:
  n8n_data:

Important: Change the password before deploying. Use a strong, unique password.

Restart the stack:

docker compose up -d

Open http://YOUR_SERVER_IP:5678 in your browser. Log in with the credentials you set. You’re now in the n8n workflow editor.

Securing the Setup

Before going live, put n8n behind a reverse proxy with HTTPS. Using Caddy (the simplest option):

# Add Caddy to docker-compose.yml
  caddy:
    image: caddy:latest
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
    restart: unless-stopped

Create a Caddyfile:

support.yourdomain.com {
    reverse_proxy n8n:5678
}

Caddy automatically provisions and renews Let’s Encrypt TLS certificates. Now your webhook URLs are HTTPS-encrypted end to end.

Step 3: Build the Knowledge Base

The chatbot is only as good as the information you give it. We’ll create a system prompt that contains your business knowledge.

Create a text file with your FAQs, policies, and common questions. Here’s a template — replace with your own information:

BUSINESS: Acme Widgets Inc.
HOURS: Monday–Friday, 9 AM – 5 PM EST. Closed weekends and holidays.
SHIPPING: Free shipping on orders over $50. Standard delivery 3–5 business days. Express delivery 1–2 business days ($15 extra). We ship to US and Canada only.
RETURNS: 30-day return policy. Items must be unused and in original packaging. Contact support@acmewidgets.com for a return label.
PASSWORD RESET: Go to acmewidgets.com/reset, enter your email, click the link in the email. If you don't receive the email within 5 minutes, check spam folder.
ORDER STATUS: Go to acmewidgets.com/track and enter your order number. Order numbers start with "AW" followed by 6 digits.
REFUNDS: Refunds processed within 5–7 business days to the original payment method.
CONTACT: support@acmewidgets.com or call 1-800-555-0100 during business hours.
ESCALATION: If the customer is angry, mentions legal action, or asks something not covered above, tell them you'll connect them with a human agent.

This is your knowledge base document. Keep it concise — under 2,000 words works best with smaller models. Every few weeks, review what questions the bot couldn’t answer and add those to this document.

Step 4: Build the n8n Workflow

Now for the fun part. In the n8n editor, create a new workflow.

Node 1: Webhook Trigger

Add a Webhook node:

• HTTP Method: POST
• Path: chat
• Response Mode: Using ‘Respond to Webhook’ node

This creates a URL like https://support.yourdomain.com/webhook/chat. When a customer sends a message, it hits this endpoint.

Node 2: Build the Prompt

Add a Set node (now called “Edit Fields”) to construct the prompt for Ollama:

{
  "system_prompt": "You are a customer support agent for Acme Widgets Inc. Use ONLY the information below to answer questions. Be friendly, concise, and helpful. If you don't know the answer, say you'll connect them with a human agent. Never make up information.\n\nKNOWLEDGE BASE:\n",
  "user_message": ""
}

In practice, you’ll store the knowledge base text in a separate file or n8n variable and reference it here. This keeps the prompt manageable.

Node 3: Call Ollama

Add an HTTP Request node:

• Method: POST
• URL: http://ollama:11434/api/chat
• Body Type: JSON

{
  "model": "llama3.2",
  "stream": false,
  "messages": [
    {
      "role": "system",
      "content": ""
    },
    {
      "role": "user",
      "content": ""
    }
  ],
  "options": {
    "temperature": 0.3,
    "num_predict": 300
  }
}

Why temperature 0.3? Low temperature means the model produces more consistent, factual responses — exactly what you want for customer support. Higher temperatures produce more creative but less reliable answers.

Why num_predict 300? This limits the response to roughly 300 tokens (about 200 words). Support responses should be concise. Nobody wants a chatbot that writes essays.

Node 4: Check for Escalation

Add an If node to check whether the response mentions escalation:

{
  "conditions": {
    "string": [
      {
        "value1": "",
        "operation": "contains",
        "value2": "human agent"
      }
    ]
  }
}

If the condition is true (the bot wants to escalate), route to a node that:

• Sends an email or Mattermost notification to your support team
• Tells the customer a human will follow up shortly

If false, route directly to the response node.

Node 5: Respond to Webhook

Add a Respond to Webhook node:

• Respond With: JSON

{
  "reply": "",
  "status": "ok"
}

This sends the chatbot’s response back to whoever called the webhook.

The Complete Workflow

Here’s what the final workflow looks like:

Webhook (POST /chat)
    │
    ▼
Set Node (build prompt with knowledge base)
    │
    ▼
HTTP Request (call Ollama API)
    │
    ▼
If Node (contains "human agent"?)
    ├── YES → Email Notification → Respond with "escalating" message
    └── NO  → Respond to Webhook with bot reply

Save and activate the workflow. Your chatbot endpoint is now live.

Step 5: Connect a Web Widget

The easiest way to add a chat widget to your website is with a small HTML snippet. You don’t need a fancy framework — just a simple form that posts to your webhook:

<div id="chat-widget">
  <div id="chat-messages"></div>
  <input type="text" id="chat-input" placeholder="Ask a question..." />
  <button onclick="sendMessage()">Send</button>
</div>

<script>
async function sendMessage() {
  const input = document.getElementById('chat-input');
  const messages = document.getElementById('chat-messages');

  const message = input.value.trim();
  if (!message) return;

  // Show user message
  messages.innerHTML += `<p><strong>You:</strong> ${message}</p>`;
  input.value = '';

  // Call the n8n webhook
  const response = await fetch('https://support.yourdomain.com/webhook/chat', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ message: message })
  });

  const data = await response.json();

  // Show bot response
  messages.innerHTML += `<p><strong>Bot:</strong> ${data.reply}</p>`;
  messages.scrollTop = messages.scrollHeight;
}
</script>

Add some CSS to style it, and you have a functional chat widget. No JavaScript framework. No npm packages. Just a form that talks to your self-hosted AI.

Connecting via Email Instead

If you’d rather handle email-based support, add an IMAP Trigger node in n8n that monitors your support inbox. When a new email arrives, the same workflow runs — Ollama generates a response, and an Send Email node replies to the customer. This turns your support@ inbox into an AI-assisted auto-responder.

Step 6: Test and Tune

Before going live, test with real customer questions. Here’s a quick test script:

# Test 1: Basic FAQ
curl -X POST https://support.yourdomain.com/webhook/chat \
  -H "Content-Type: application/json" \
  -d '{"message": "What are your business hours?"}'

# Test 2: Policy question
curl -X POST https://support.yourdomain.com/webhook/chat \
  -H "Content-Type: application/json" \
  -d '{"message": "Can I return a product after 40 days?"}'

# Test 3: Escalation trigger
curl -X POST https://support.yourdomain.com/webhook/chat \
  -H "Content-Type: application/json" \
  -d '{"message": "I want to speak to your manager about a lawsuit"}'

Expected behavior:

• Test 1: Responds with your business hours from the knowledge base
• Test 2: Explains the 30-day return policy and suggests contacting support
• Test 3: Escalates to a human agent

If the bot gives wrong answers, the fix is almost always in the knowledge base document, not the model. Add the missing information and test again. This is the iterative improvement loop:

Bot gives wrong answer
    │
    ▼
Identify what information was missing
    │
    ▼
Add it to the knowledge base document
    │
    ▼
Test the same question again
    │
    ▼
Repeat until accurate

Monitoring and Maintenance

Track What the Bot Can’t Answer

Add a Postgres or SQLite node to log every conversation where the bot escalated to a human. Review these weekly — they’re your roadmap for what to add to the knowledge base next.

CREATE TABLE escalation_log (
    id SERIAL PRIMARY KEY,
    timestamp TIMESTAMP DEFAULT NOW(),
    customer_message TEXT,
    bot_response TEXT,
    resolved BOOLEAN DEFAULT FALSE
);

Watch Server Resources

Ollama uses CPU and RAM when generating responses. Monitor with:

docker stats ollama

If responses are slow (more than 5–8 seconds), consider:

• Upgrading to a VPS with more CPU cores
• Switching to a smaller model (if accuracy allows)
• Adding a GPU (Ollama supports NVIDIA GPUs natively)

Update Regularly

# Update Ollama
docker compose pull ollama && docker compose up -d ollama

# Update n8n
docker compose pull n8n && docker compose up -d n8n

# Pull a newer model if available
docker exec -it ollama ollama pull llama3.2

Set a calendar reminder to do this monthly. Updates take about 5 minutes.

Cost Breakdown

Here’s what this setup actually costs per month:

Compare that to Intercom’s cheapest plan at $74/month (with limited AI features) or Zendesk Suite at $55/month per agent. Even factoring in the one-time 3–4 hour setup, you break even within the first month.

Limitations (Be Honest About These)

This setup is powerful, but it’s not magic. Here’s what it can’t do:

• Access your database in real-time. It can’t look up a specific customer’s order. For that, you’d need to add a database query node in n8n that fetches order data and includes it in the prompt.
• Handle complex multi-turn conversations. Llama 3.2 (3B) is good for single-question responses but loses context in long back-and-forth chats. For multi-turn support, consider Llama 3.1 (8B) and add conversation history to the prompt.
• Understand images or attachments. The 3B model is text-only. If you need image understanding (e.g., customers sending photos of damaged products), use Llama 3.2 Vision or a multimodal model like LLaVA.
• Be 100% accurate. All LLMs hallucinate occasionally. The escalation trigger catches most issues, but you should review logs weekly and refine the knowledge base.

Going Further

Once the basic chatbot is working, here are incremental upgrades you can add:

1. Database integration: Add a Postgres node in n8n to look up customer orders and include real data in the prompt. This transforms the bot from a FAQ responder to a personalized support agent.

2. Conversation logging: Store every conversation in a database for quality review. Use Metabase (open source) to build dashboards showing common questions, escalation rates, and response times.

3. Multi-channel: Connect the same n8n workflow to Telegram, Mattermost, or Signal using their respective n8n trigger nodes. One bot, multiple channels.

4. RAG (Retrieval-Augmented Generation): For larger knowledge bases (100+ documents), set up a vector database like Qdrant or ChromaDB alongside Ollama. This lets the bot search your documents semantically rather than stuffing everything into the system prompt.

5. Sentiment detection: Add a second LLM call that classifies sentiment (happy, neutral, frustrated, angry). Route angry customers to humans immediately, before the support bot even tries to respond.

Wrapping Up

A self-hosted customer support chatbot is one of the highest-ROI automation projects a small business can undertake. The setup takes an afternoon, the monthly cost is negligible, and the payoff — hours saved on repetitive questions — is immediate.

The key insight is this: you don’t need a $500/month AI platform to handle “what are your hours?” You need a lightweight model, a workflow tool, and a well-maintained knowledge base. The open source tools exist. The hosting is cheap. The only thing standing between you and an automated support bot is a few hours of setup.

And unlike a SaaS platform, this one is yours. No vendor can raise prices on you. No one can shut off your API access. Your customer conversations stay on your server, under your control.

Ready to automate your customer support without the SaaS price tag? Contact ARDOT Consulting — we help small businesses design, deploy, and maintain open source AI automation that fits their needs and their budget.