Systems Overview
Summary
Section titled “Summary”A map of TCR’s core systems and how they connect, before drilling into any one system’s own page. Most of the connective tissue between systems runs through n8n, which handles roughly 95% of TCR’s automation.
TCR’s entire IT infrastructure was built from scratch, solo, by the current IT owner (Wade). That context matters for how this site should be used: the “why” behind a lot of these systems is “there was no existing infrastructure to build on,” not “we migrated from X.”
Core servers & hosting
Section titled “Core servers & hosting”| Host | Purpose |
|---|---|
| Daedalus (Windows Server) | Runs the Transcript App stack; SQL Server instance DAEDALUS\SQLABYRINTH |
| Perdix (Ubuntu VM on Hyper-V) | Runs n8n in Docker (migrated off WSL) |
| 2× on-prem servers | Available capacity — one already runs n8n (above); the second is a candidate host for this documentation platform |
| SiteGround | Hosts the TCR website (Astro/React/Tailwind) |
| Cloudflare | Workers + D1 + KV backend for the website; Access/Tunnel in front of Daedalus; R2 hosts printer driver files |
Daedalus and Perdix aren’t arbitrary hostnames — TCR’s on-prem infrastructure follows a Greek mythology naming tradition. See Naming Conventions for the reasoning (and a name suggestion for that still-unnamed second server).
Identity & directory
Section titled “Identity & directory”| System | Role | Notes |
|---|---|---|
| Google Workspace | Primary identity provider, email, docs | Google Vault available for retention/legal hold |
| District AD (on-prem) | Windows workstation identity | Aging Windows Server 2008 box, tied to DCSD district infrastructure |
| DCSD DNS | Controls tcr.edu nameservers |
District-managed, not TCR-managed — see the TCR website page for the blocker this creates |
Student email pattern: firstname.lastname@stu.tcr.edu.
The ecosystem, at a glance
Section titled “The ecosystem, at a glance”- Populi is TCR’s SIS of record going forward, part of the ground-up infrastructure build. It integrates natively with Canvas (LMS) — a vendor-provided integration, not custom-built. Populi is being evaluated as a possible replacement for Canvas around 2027/2028, which would consolidate SIS and LMS under one vendor.
- Every night, an n8n workflow pulls students, terms, and term enrollments from the Populi API into the
TCR_StudentRecordsSQL Server database on Daedalus, so the registrar can generate transcripts on demand through a custom-built app rather than through Populi’s native generator. See TCR Transcript App. External transcript requests come in through Parchment, which the registrar fulfills using this app. - n8n (self-hosted, Docker on an Ubuntu VM on a Hyper-V host) is the automation hub tying most of this together: the nightly Populi sync, the applicant email lifecycle, and routing from the website’s chatbot/forms to the right internal inboxes.
- The TCR website (Astro, Tailwind, React; live at
tcrtek.org, hosted on SiteGround with a Cloudflare Workers/D1/KV backend) has a chatbot scoped to answer only from site content, plus several forms. When a form or chatbot conversation needs a human, it goes through Tally and n8n to reach the right department. - Google Workspace provides email and is the account layer that Populi provisions into on onboarding.
- District AD handles Windows workstation identity, separately from Google Workspace, tied to DCSD’s district infrastructure.
- Atera (Windows RMM) and Mosyle (Apple device management) handle device management for their respective platforms. Atera also drives the printer fleet deployment via PowerShell scripts.
- Cloudflare gates this documentation site via Access, gates Daedalus via Access/Tunnel, time-gates the letter-of-intent step of the applicant flow, and (via R2) hosts printer driver files.
Active/in-progress projects
Section titled “Active/in-progress projects”Beyond the systems above, a few builds are actively in progress and have their own pages once written up:
- Printer fleet deployment — Canon/HP, ~150 workstations, pilot phase.
- Admissions automation
- AI tutor pilot
- Custom student dashboard
Scope note: excluded programs
Section titled “Scope note: excluded programs”Several certification programs — Welding, Phlebotomy, BLS, Heartsaver, CPR, and Nurse Aide — are excluded from the current infrastructure build-out pass system-wide (Populi rollout, site build, SQL/transcript work, and the printer fleet rollout all currently exclude these programs). They’re deferred to a later phase rather than covered by what’s documented here.
Data flows
Section titled “Data flows”Nightly sync: Populi → SQL Server → transcripts
Section titled “Nightly sync: Populi → SQL Server → transcripts”Every night, n8n pulls students, terms, and term enrollments from the Populi API into TCR_StudentRecords on Daedalus. This feed exists specifically to drive the registrar’s transcript-generation system, which merges this data with legacy Jenzabar records. See TCR Transcript App for full detail, including the API constraints and incidents that shaped how this sync is built.
Applicant email lifecycle (via n8n)
Section titled “Applicant email lifecycle (via n8n)”n8n manages applicant communication through a staged lifecycle:
- Submission
- Pending
- Provisional — letter of intent, time-gated via Cloudflare
- Confirmed
At every stage, n8n sends both an applicant-facing email and an internal notification email to the relevant department, so no stage change happens silently. See Admissions Automation.
Website chatbot, forms, and routing
Section titled “Website chatbot, forms, and routing”The website’s chatbot is scoped to answer only from the site’s own content. When a visitor needs a human, or fills out a form, the request is captured in Tally and routed by n8n to the correct internal inbox by category:
- Maintenance requests
- Attendance alerts
- IT help desk
- General questions
Not yet documented
Section titled “Not yet documented”- Exact routing rules per category (which department/inbox each one lands in).
- A real network diagram (VLANs, Core-3 switch, Daedalus, Hyper-V host, printer segment).
- A secrets/credentials index (1Password vault references only, no actual values) — planned once this platform has real access tiers.
- Whether Payfactory/Meevo/Adyen (payment processing, already covered in the PCI DSS policy) get their own system pages.
- This platform’s own planned capabilities (admin/read-only tiers, open API, vendor contract storage) are tracked in the repo’s README rather than as a system page, since it describes this site rather than a system TCR uses.
Built from working notes and a working session with Wade (2026-08-18/19) rather than a single source document — flag anything here that’s inaccurate or incomplete and it’ll get corrected.