n8n for Founders: The 5 Workflows We Install in Every Client's VPS

Every founder who hears about n8n has roughly the same first week. They spin up a cloud trial, import four templates from the community library, watch two of them fail silently because a credential expired, and then bounce back to Zapier because at least Zapier sends an email when something breaks. The problem is not n8n. The problem is that the template library is a catalogue, not an opinion. You get a thousand single-node graphs and no guidance on which five are worth the sixty minutes each takes to wire up properly.

This is the opinionated list. Five workflows that pay for the VPS the day you turn them on, with the non-obvious details that the public templates skip. A six-dollar droplet running self-hosted n8n handles all five comfortably, the executions are free and unmetered, and by the end of the afternoon the tasks that eat a founder's Monday morning no longer exist.

Why A Self-Hosted VPS Beats Zapier Before The Month Ends

Before the workflows, the math. Zapier's Starter plan is forty-nine dollars a month and caps at seven hundred and fifty tasks. A single active lead-capture workflow with enrichment and a Slack notification burns three to four tasks per lead. Two hundred leads a month is already over the cap and Zapier starts throttling or charging overage. Make is cheaper but the same shape, metered tasks that push you up tiers the moment you wire a real business through it.

A self-hosted n8n on a Hetzner CX22 or a DigitalOcean six-dollar droplet has no execution limit. The workflow can fire a thousand times a day and the bill does not change. The only real cost is the hour of setup, and clients bring us in precisely because that hour turns into a weekend when they discover that reverse proxy configuration, the encryption key backup, and persistent credential storage are not in the quick-start guide. Once it is running, the marginal cost of the sixth, seventh, and twentieth workflow is zero, and that is what makes the five below worth the effort. You are amortizing a fixed cost across an unlimited number of automations.

Workflow One: Lead Capture To CRM With Deduplication And Enrichment

The template everyone imports is a three-node graph. Webhook receives a form submission, HTTP Request posts to the CRM, Slack sends a notification. It works for about a week, and then the founder notices that the same prospect filling the form twice creates two records in the CRM, the second one without the source notes the first one had, and now the sales ops spreadsheet has duplicates that pollute reporting.

The version we actually ship has five nodes between the webhook and the CRM write. First, a normalization function that lowercases the email, strips plus-aliases from Gmail addresses, and canonicalizes the company domain. Second, a CRM search node that queries the existing contacts for a match on the normalized email and, if that misses, on the company domain combined with a fuzzy name match. Third, a branch. If a match exists, the workflow updates the existing record with the new form fields and appends a note with the new source rather than creating a duplicate. If no match exists, the workflow moves to the fourth node, an enrichment call to Clearbit, Apollo, or a cheaper alternative like Hunter that returns company size, industry, and the LinkedIn URL of the person. The fifth node writes the enriched record to the CRM with a lead score calculated from ICP fit, and only then does the workflow fire the Slack notification, which now carries enough context that the founder can triage it in four seconds instead of opening three tabs.

The non-obvious detail is the deduplication key. Email alone is not enough because real humans submit forms from work and personal addresses on different days. The pair we use is normalized email plus company domain, and a match on either triggers an update rather than a create. The other detail is that the Slack notification only fires above a lead score threshold. Low-score leads still land in the CRM but do not interrupt the founder's Monday. That single rule is the reason clients keep the Slack notifications on instead of muting the channel in week three.

Workflow Two: Inbox Triage With Claude Classification And Auto-Label

The founder's inbox is the workflow that justifies the VPS on its own. Every template you find uses Gmail plus OpenAI with a generic "classify this email" prompt and dumps the result into a label. It works badly because the prompt is vague, the label taxonomy has fifteen buckets, and the model hedges on everything it is unsure about.

The version we install uses Claude via the HTTP Request node with a three-class taxonomy that is intentionally small. Every incoming email is classified as reply needed, FYI, or newsletter. Reply needed means a human has written expecting a response within two working days. FYI covers notifications, receipts, CI failures, and calendar confirmations that a founder should glance at but does not need to act on. Newsletter covers everything signed up for and not yet unsubscribed from. That is it. Three buckets, three Gmail labels, and a trigger node that runs every five minutes on new unread mail.

The prompt matters more than the model choice. We give Claude the sender domain, the subject, the first five hundred characters of the body, and a short definition of each class with two canonical examples. The prompt ends with an instruction to respond in JSON containing the class and a one-sentence reasoning field. The reasoning field is the secret. It forces the model to justify its call, which dramatically cuts hedging, and when a label is wrong the founder can paste the reasoning back into the prompt as a corrective example. After two weeks of occasional corrections the classifier runs above ninety-five percent accuracy for a single inbox's patterns.

The label strategy is the other piece templates miss. The newsletter label is archived automatically on label apply, using the Gmail API's removeLabelIds: ['INBOX'] alongside the add. The founder's inbox only shows reply needed and FYI, and the morning triage drops from forty-five minutes of scanning to ten minutes of actual replying. Newsletters are searchable when the founder wants them but invisible by default. That one behavioral change is the workflow's real output.

Workflow Three: Invoice Reminders That Read Stripe, Not A Spreadsheet

Founders who invoice through Stripe have a silent problem. Stripe sends one automated reminder on the due date and then goes quiet. Accounts receivable drifts. The founder intends to chase overdue invoices on Friday, forgets, and three weeks later notices that eighteen thousand dollars is sitting in an "open" state that nobody is following up on.

The workflow we install queries the Stripe API on a schedule, typically daily at nine in the morning the founder's timezone, using the invoices.list endpoint with status=open and a filter on due_date. It pulls every open invoice, subtracts the due date from today, and branches on the age. At three days overdue the customer receives a gentle reminder email that reads as if the founder sent it personally, referencing the invoice number and the service delivered. At fourteen days overdue the tone shifts to firm, the email is still from the founder's address but mentions that continued access may be affected. At thirty days overdue the workflow escalates internally, posting a Slack message to the founder asking whether to pause the client's account or hand the invoice to a collections partner.

The detail that makes this work without embarrassing the founder is the pause check. Before sending any reminder, the workflow re-queries the specific invoice to confirm it is still open. Stripe's list endpoint caches on a timescale that can send a reminder for an invoice that was paid six minutes ago, and nothing damages a client relationship faster than chasing them for money they already sent. The re-query adds fifty milliseconds and eliminates the false positive entirely. The other detail is that every reminder updates a metadata field on the Stripe invoice itself, so the reminder history lives on the record and the founder can audit what was sent without opening n8n.

Workflow Four: Content Publishing Across LinkedIn, X, And Bluesky From One Notion Row

Founders who take content seriously write in one place and publish in three. The naive solution is Buffer or Hootsuite at fifteen to twenty dollars a month per seat, which is fine until the founder wants to publish in different formats per channel. A LinkedIn post benefits from line breaks and a hook, an X thread needs to be sliced into sub-280-character beats, and a Bluesky post sits somewhere between the two. Buffer publishes the same text everywhere and loses the native feel of each platform.

Our n8n workflow runs off a single Notion database where each row has the full long-form draft, a status field, and a scheduled time. When the status flips to approved, the workflow triggers. An LLM node, again Claude, reformats the source draft three times with three different prompts, one per channel. The LinkedIn prompt asks for a first-line hook, two-line paragraphs, and no hashtag stuffing. The X prompt slices the draft into a numbered thread with each tweet under two hundred and seventy characters. The Bluesky prompt aims for a single rich paragraph under three hundred characters with one link preview. Each output is written back to the Notion row for the founder to tweak before publish time.

At the scheduled moment a second workflow fires, reads the three pre-formatted versions, and posts each via the respective platform's API. LinkedIn uses the ugcPosts endpoint with the founder's personal or company token. X uses the v2 tweets endpoint with the reply chain for threads. Bluesky uses the atproto POST to com.atproto.repo.createRecord. All three post within the same minute and the status field in Notion flips to published with the three URLs appended.

The design choice worth naming is keeping the reformatting step separate from the publishing step. Founders want to edit the machine-formatted LinkedIn version before it ships. If reformatting happens at publish time, there is no window to edit. Splitting the two steps gives the founder a day or an hour to catch anything awkward and also means that if the LinkedIn API fails at publish time, the X and Bluesky posts still ship.

Workflow Five: Uptime Monitoring With A Real Escalation Chain

Every founder with a production app signs up for UptimeRobot, wires it to Slack, and within a month mutes the channel because a single flaky region in us-east-1 pages them twice a week at three in the morning. Then a real outage happens, the alert fires into a muted channel, and the founder finds out about it from a customer email.

The workflow we install treats a single failed ping as noise, not a signal. A scheduled n8n job pings the critical endpoints every sixty seconds. A failure triggers a retry chain. The same endpoint is re-pinged at ten seconds, thirty seconds, and ninety seconds. Only if three of the four pings fail does the workflow consider the service down. That single rule kills about ninety percent of false alerts because transient network hiccups almost never span three retries ninety seconds apart.

When the workflow does decide the service is down, the escalation chain matters. The first action is a Slack message to the on-call channel with the failing endpoint, the response code or timeout, and the last known good timestamp. If the service is still down five minutes later, the workflow fires a Twilio SMS to the founder's phone. If fifteen minutes pass with the service still down, the workflow places a Twilio voice call that reads the incident aloud, which wakes the founder up in a way no push notification does. Recovery at any stage cancels the chain and posts a resolution message to Slack with the total downtime.

The detail that prevents this from being annoying is the auto-resolve behavior. The workflow maintains an internal incident state so that a flap, down for two minutes and back up, does not send a recovery message for every oscillation. It waits for three consecutive successful pings before declaring the incident resolved, and the Slack message summarizes the whole window with start time, end time, and total duration. Founders keep this alert channel unmuted because it only fires on real incidents and it carries enough context to act on without opening a laptop.

How We Install All Five On A Client's VPS In One Afternoon

The sequencing matters. We provision the droplet first, set up n8n behind a Caddy or Traefik reverse proxy with an auto-renewing SSL cert, and encrypt the credentials store with a key that is backed up separately from the database. We load the five workflows as JSON exports, wire up the credentials, and run each one end-to-end with test payloads before handing over. The final step is a backup job, typically a nightly pg_dump to an S3-compatible bucket, because the thing that kills founder n8n installations is not the setup but the moment the VPS reboots, the SQLite database is corrupt, and three months of automations are gone.

If the VPS setup stalls on SSL, the encryption key gets misplaced, or the credentials store ends up in plaintext in a Git repo somewhere, that is usually when clients bring WitsCode in. We hand over a hardened n8n instance with these five workflows pre-built, documentation on how to edit each one, and a runbook for the two or three things that actually go wrong in month three. The workflows are the product, the VPS is the foundation, and the handover is where most DIY setups never quite finish.