Building an AI Support Triage Pipeline With n8n and Flowise, Entirely Inside One PaaS Environment Group

The support team at a developer-tools company we will call Quillon had a familiar backlog: 400 tickets a week, a third of them answerable from the documentation, and a rule that customer messages could not be pasted into third-party AI tools. A backend developer took two days to build a triage pipeline that classifies each ticket, drafts a reply grounded in the docs, and hands the draft to a human. It runs on three marketplace packages on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic), inside one isolated environment group. This is how it fits together.

Division of labour: n8n orchestrates, Flowise reasons

It is tempting to build everything in one tool. Both n8n and Flowise have AI nodes, and both can call a helpdesk API. The developer split them by strength. n8n owns the plumbing: the helpdesk webhook, deduplication, the decision about which tickets go to the model, writing the draft back, and the Slack notification. Flowise owns the reasoning: a retrieval-augmented generation (RAG) chain over the product documentation with a classification step in front of it, exposed as a REST endpoint that n8n calls. PostgreSQL with the pgvector extension stores the document embeddings and Flowise's own state.

The split keeps each flow small enough to read. It also means the model provider can be swapped in Flowise, from a hosted API to a self-hosted model on a GPU server, without touching the n8n workflow at all.

Laying out the environments

Each package is its own environment, all three placed in one environment group called support-ai with network isolation switched on. Inside the group, containers talk over the platform's internal network by hostname, with no traffic charge and no public exposure. Outside the group, nothing on the account can open a connection in.

• n8n (Node.js plus PostgreSQL, from the marketplace package). This is the only environment with a public IP, because the helpdesk has to reach the webhook. The Let's Encrypt add-on gives it a trusted certificate on hooks.quillon.example, and the container firewall allows inbound 443 from the helpdesk vendor's published IP ranges only.
• Flowise (Node.js, from the marketplace package). No public IP. Shared-load-balancer access is disabled for the layer, so its platform domain answers nothing from outside. n8n calls it at http://node<id>-flowise.<env>.<platform domain>:3000 over the internal network, with Flowise's API key in an n8n credential.
• PostgreSQL with pgvector (the PostgreSQL cluster package, with the pgvector extension enabled). Also internal only. The SSL/TLS add-on enforces encrypted connections even inside the group, which the security review appreciated more than the developer expected.

The developer's diagram therefore had one arrow crossing the boundary: helpdesk to n8n webhook over HTTPS. Every other arrow was internal.

The Flowise chain

In Flowise the developer built two flows. The first is a classifier: a prompt template with the ticket subject and body, asking the model for one of five categories (billing, bug, how-to, feature request, spam) and a confidence score, with structured output parsing so n8n receives JSON. The second is the RAG answerer: a document loader pointed at the documentation repository's Markdown export, a text splitter, an embeddings node writing to pgvector, and a conversational retrieval chain that produces a draft reply citing the pages it used.

Both flows are published as API endpoints with keys. Flowise stores the model provider's API key as a credential inside its own database in the Flowise environment, so the key exists in exactly one place, on disk in a container in the Frankfurt region, rather than in a SaaS automation tool's vault.

Re-indexing the documentation is a third, tiny n8n workflow: on a nightly schedule it calls the Flowise upsert endpoint for the documents that changed in Git that day. Because the documentation is the ground truth for replies, the developer also added a check that refuses to publish a draft whose retrieved sources are all older than the product version mentioned in the ticket.

The n8n workflow, step by step

1. Webhook. The helpdesk posts each new ticket to n8n. A Postgres node checks a small dedup table so retries do not produce two drafts.
2. Classify. An HTTP Request node calls the Flowise classifier. Billing and spam are routed immediately: billing to the finance queue, spam closed with a note.
3. Answer how-to and bug tickets. An HTTP Request node calls the RAG endpoint with the ticket text and the customer's product version, and receives a draft plus source URLs.
4. Guardrail. A Code node rejects drafts with confidence under 0.7 or with no sources, and marks the ticket for a human without a draft.
5. Write back. The draft is added to the ticket as an internal note with its sources, the ticket is tagged ai-drafted, and the assigned agent gets a Slack message with a one-line summary.
6. Feedback. When an agent sends, edits or discards the draft, the helpdesk fires a second webhook and n8n records the outcome in PostgreSQL. That table is the dashboard the support lead actually looks at.

Nothing here is exotic n8n. The point is where it runs: each HTTP Request node talks to a hostname on the same private network, and the whole pipeline's external surface is one webhook.

Scaling, cost and what changed for the team

Ticket volume is bursty (Monday mornings, release days), and the platform handles that with vertical scaling: each node grows in cloudlets, 128 MiB of RAM plus 400 MHz of CPU, up to the ceiling the developer set, and shrinks afterwards. Flowise, which does the heavy lifting while an embedding or a chain runs, has the highest ceiling. Between bursts the three environments idle at a handful of cloudlets each, and at MassiveGRID's published rate of $0.003372 per cloudlet-hour the whole pipeline costs a few tens of dollars a month plus the model provider's usage, which the developer can now attribute per ticket from the outcomes table.

After six weeks the support lead reported that 38% of how-to tickets were being sent with the AI draft unchanged or lightly edited, first-response time for those had dropped from hours to minutes, and no customer text had been sent anywhere except the model provider chosen and disclosed in the privacy notice. The developer's own note was shorter: the hard part was not the AI, it was making sure the AI could only be reached from one place, and the platform made that a group setting rather than a project.

Frequently Asked Questions

Could this run in a single environment instead of three?

Yes. n8n, Flowise and PostgreSQL can be layers in one environment, which is simpler for a small deployment. Separate environments were chosen so each can be scaled, stopped, cloned and backed up independently, and so the public IP and firewall rules apply only to n8n. The isolated group gives the same private network either way.

How do the containers find each other without public IPs?

Every node on MassiveGRID PaaS has an internal hostname and address reachable from other containers on the same account (and, with network isolation on, only from the same group). Use the node hostname shown in the dashboard as the host in n8n's HTTP Request node or Flowise's database settings. Internal traffic is not charged.

Can the model run privately as well?

Flowise supports self-hosted models through Ollama and OpenAI-compatible endpoints. Running an open model with acceptable latency needs a GPU, which is outside the PaaS containers; MassiveGRID's GPU dedicated servers can host the model and be reached from the Flowise environment over a firewalled connection, keeping the entire pipeline on MassiveGRID infrastructure.