n8n

Overview

n8n is a workflow automation platform, self-hosted on-prem, that handles roughly 95% of TCR’s automation. It’s the connective tissue between most of TCR’s other systems rather than a system anyone interacts with directly.

Technology

Runs in Docker on an Ubuntu VM named Perdix, on a Hyper-V host — migrated off WSL. This is a separate host from Daedalus (the Windows Server running SQL Server and the Transcript App); n8n reaches Daedalus’s SQL Server over the LAN, since cross-host hostname resolution doesn’t work here (see TCR Transcript App for the connection details).

There are two on-prem servers available in total; Perdix (this Hyper-V host) is one of them. The second is a candidate host for this documentation platform itself.

Not yet documented: VM specs, how n8n itself is kept updated/patched, whether workflows are version-controlled.

Background & why

TCR used Zapier for about a year first, then moved to n8n. The switch was deliberate: n8n offers far more granularity than Zapier, and being self-hosted, it keeps TCR’s data fully under TCR’s own control rather than routed through a third-party SaaS. Combined with Populi’s expansive API library (and other systems’ APIs), n8n was chosen specifically to let TCR build a genuine interconnected ecosystem — securely, on infrastructure TCR controls — rather than stitching together point-to-point SaaS integrations.

It’s proven to be a powerhouse for that role, and TCR hasn’t come close to exhausting what it can do — most of what’s documented on this site so far (the nightly Populi sync, the applicant email lifecycle, website chatbot/form routing) is what’s been built with it to date, not the ceiling of what it’s capable of.

What it automates

Nightly Populi → SQL Server sync

Every night, n8n pulls students, terms, and term enrollments from the Populi API into TCR_StudentRecords on Daedalus, feeding the custom transcript app. See Populi for the API constraints and incidents that shaped this workflow, and TCR Transcript App for what it feeds.

Applicant email lifecycle

Manages applicant communication through staged status changes:

1. Submission
2. Pending
3. Provisional — letter of intent, time-gated via Cloudflare
4. Confirmed

Each stage change triggers both an applicant-facing email and an internal notification to the relevant department.

Website chatbot & form routing

The TCR website’s chatbot and forms hand off to a Tally form when human help is needed. n8n routes those submissions to the correct internal inbox by category: maintenance requests, attendance alerts, IT help desk, and general questions.

Integrations

• Populi API (source of the nightly data pull and likely the applicant-status trigger, though the exact trigger mechanism isn’t yet documented)
• SQL Server on Daedalus (nightly sync target, reached over the LAN across hosts)
• Tally (form submissions from the website)
• Email (Google Workspace, for both applicant-facing and internal notification emails)
• Cloudflare (time-gating on the letter-of-intent step)

Access

Not yet documented: who has admin access to n8n, where workflows are reviewed/edited, whether there’s a staging environment before changes go live.

Dependencies

Given how much routes through n8n, an n8n outage would affect: the nightly transcript data sync, the entire applicant email lifecycle, and website chatbot/form routing. Worth treating as a high-priority system for uptime/backup purposes even though it’s “just” automation glue.

Backup & recovery

Not yet documented — since this is self-hosted, backup here is TCR’s own responsibility, not a vendor’s. Worth prioritizing given how much depends on it.

Notes

n8n is the single point where the most different systems intersect. If anything on this ecosystem overview page is wrong, this page is the one most likely to need corrections first.

The host VM’s name, Perdix, isn’t arbitrary — see Naming Conventions for the mythology behind it and Daedalus.