Resurrection Drive

Resurrection Drive · Kitchener-Waterloo, Ontario

Infrastructure, automation, and private AI. Built by the person who answers the email.

Resurrection Drive is the technology practice of Nick Nghiem: twenty years in enterprise networks, servers, and security, and now a self-built AI chief of staff running my own operations around the clock. I take on fixed-scope projects, stubborn problems, and automation for teams that need senior hands without a full-time hire.

  • 20 yearsenterprise IT
  • 6,000+logged agent tasks
  • 125-personproduction network
  • 180+tests on the latest app

What I take on

Named work, not “anything technical.” Every line below runs in production today, with one exception that says so on its face.

Networks and firewalls

Firewall work on live production networks. Right now I’m leading a migration from Cisco ASA to pfSense at a 125-person company: a high-availability pair and a staged cutover, with the new edge carrying live traffic today. Also VLAN segmentation, switching (Cisco Catalyst, Dell, HPE), flow-level traffic visibility, and network diagrams.

Servers and fleets

Linux fleets under Ansible configuration management, so builds are repeatable instead of hand-edited and undocumented. Production migrations off end-of-life CentOS onto supported Ubuntu with the applications intact. Windows Server and Active Directory work, including domain controller repair. VMware, Veeam, storage.

Automation and private AI

Approval-first AI agents and document pipelines on hardware you control. Email triage, document intake and filing, reporting, meeting transcription that never uploads audio. Where client confidentiality or PIPEDA/PHIPA obligations rule out cloud AI, the sensitive path runs local. I operate this pattern daily for myself.

Security posture review

For small businesses: a firewall and edge configuration review, an email and Microsoft 365 security baseline, and an external vulnerability assessment, delivered as a fixed-price written report with a prioritized fix list. Scoped and authorized in writing before anything runs. Two things this is not: penetration testing, and a compliance certificate. It is findings and fixes, in plain language, and it is the newest line on this page, the one offer here that is not yet a track record.

Dashboards and monitoring

The state of your systems on one screen, served from your own hardware: tasks, jobs, spending, health, and what the automation did overnight. Deliberately boring engineering that survives a reboot: one page, a small server, a SQLite file, no framework churn.

Documentation and diagrams

Runbooks and handover documentation written so the next person can run the thing without calling you. Network and architecture diagrams that match what is actually deployed. A career of being the next person taught me what is usually missing.

AI that respects a boundary

I run my own AI chief of staff, all day, every day. It triages my email, briefs me each morning on my calendar, tasks, and inbox, files my documents, tracks my spending, and drafts replies that wait for my sign-off. More than 6,000 logged agent tasks so far, unattended, on hardware I own; the log carries the agent, the model, the cost, and the transcript.

I build the same pattern for other people: agents that read, research, organize, and draft continuously, but never send a message or spend a dollar without approval. The approval gate is enforced in code, not in a prompt.

I am not selling a smarter agent. I am selling one you can point a regulator, a client or a lawyer at.

Selected work

Systems I built and run in production, described as they actually run.

Production firewall migration

Cisco ASA to pfSense at a 125-person company, without a big-bang cutover: a high-availability pair, dual-WAN failover validated on live carrier feeds, site-to-site IPsec rebuilt, and remote access moving in stages. The new edge carries live traffic today while the old firewall is retired piece by piece.

  • pfSense
  • Cisco ASA
  • HA
  • IPsec
See the before and after diagramHide the diagram
Network diagram, the typical starting point One internet feed reaches a single Cisco ASA firewall. Site-to-site IPsec and remote access both terminate on that same appliance, which sits in front of the internal network. Internet Cisco ASA Site-to-site IPsec Remote access Internal network

One appliance carries everything, and one feed reaches it.

Network diagram, after the migration Two carrier feeds reach a pfSense high-availability pair, two nodes sharing a virtual IP, in front of the internal network. Site-to-site IPsec is rebuilt on the pair, and remote access is still moving over in stages. The old Cisco ASA is drawn faded and still attached, retiring piece by piece. Carrier feed Carrier feed High-availability pair pfSense pfSense shared virtual IP Site-to-site IPsec, rebuilt Remote access, moving in stages Cisco ASA retiring Internal network

Two feeds, two nodes, and the old firewall on its way out.

What changed

  • No single point of failure at the edge. One node can fail and traffic keeps flowing.
  • Dual-WAN failover, validated on live carrier feeds.
  • Staged cutover, reversible at every step. The new edge carried live traffic before the old one was retired.
Illustrative reference pattern, not a customer network.

Email triage with a hard privacy gate

An inbox where routine mail and a protected class of records arrive mixed. A classifier routes every thread before anything else touches it; protected mail diverts through a write gate to an encrypted volume, and the synced database provably never sees it. My own audit caught the classifier matching the sender only and missing a protected address that appeared only in Cc. The fix checks every participant and can only upgrade a thread’s sensitivity, never downgrade it.

  • LLM classification
  • Python
  • privacy boundary
See the privacy gate diagramHide the diagram
Flow diagram of the email triage and its privacy gate Routine mail and protected records arrive mixed in one inbox. A classifier checks every participant of every thread, then the flow forks: routine mail lands in the synced database, and protected records pass through a write gate onto an encrypted volume. A barred marker on the synced database records that protected records never reach it, and the fork can only upgrade sensitivity, never downgrade. Inbox routine mail protected records arrive mixed Classifier checks every participant can only upgrade sensitivity, never downgrade Synced database protected records never reach it Write gate Encrypted volume

Why it holds

  • Every thread is classified before anything else touches it.
  • Protected records never reach the synced database.
  • Sensitivity can only be upgraded, never downgraded.
Simplified for clarity. This is a system I built and run.

Document intake pipeline

Drop a document in a folder and it gets read, classified, renamed, filed, and summarized, then indexed into a local SQLite database searchable by content. Sensitive documents file as pointers, originals on an encrypted volume, so the index stays clean. Every run closes with an honest report of what it processed and what it skipped, because a pipeline that silently drops files is worse than no pipeline.

  • Python
  • SQLite
  • document AI
See the pipeline diagramHide the diagram
Flow diagram of the document intake pipeline A drop folder feeds a pipeline of five stages: read, classify, rename, file, summarize. Documents land in a SQLite index searchable by content. A sensitive document branches: a pointer goes into the index while the original goes onto the encrypted volume, so the index stays clean. The run terminates in a run report of what was processed and what was skipped. Drop folder read classify rename file summarize sensitive document SQLite index searchable by content pointer index stays clean Encrypted volume original Run report processed · skipped

Why it holds

  • Sensitive originals stay on the encrypted volume. Only pointers are indexed.
  • Every run closes by reporting what it processed and what it skipped.
Simplified for clarity. This is a system I built and run.

Meeting transcription, fully on device

whisper.cpp transcribes the recording on the machine itself, then a language-model pass turns it into decisions, action items, and open questions, folded into the notes I walked in with. Zero bytes of audio leave the machine, and there is no per-minute bill. This is my daily workflow.

  • whisper.cpp
  • local speech-to-text
  • Python
See the on-device diagramHide the diagram
Diagram of the fully on-device transcription flow A boundary labelled this machine encloses the whole flow: a recording goes through whisper.cpp to a transcript, then a language-model pass produces decisions, action items, and open questions, folded into the notes I walked in with. The only link toward the internet outside the boundary is severed, marked zero bytes of audio leave. Internet zero bytes of audio leave this machine recording whisper.cpp transcript language-model pass decisions action items open questions the notes I walked in with

Why it holds

  • Zero bytes of audio leave the machine.
  • No per-minute bill.
Simplified for clarity. This is a system I built and run.

Agent orchestration with an audit trail

A coordinator routes work to a roster of scoped agent roles, each with a brief naming exactly the files it may read. Inexpensive models take the mechanical work; expensive ones are saved for judgment. Every dispatch lands in a SQLite audit log carrying the agent, the model, the tokens, and the transcript. When something goes wrong, the investigation starts from a record instead of a guess.

  • multi-agent
  • cost routing
  • SQLite audit log
See the orchestration diagramHide the diagram
Diagram of the agent orchestration and its audit trail A coordinator fans work out to three scoped roles, and each role’s brief names the files it may read. Two roles take mechanical work on an inexpensive model; one takes judgment on an expensive model. Every dispatch lands in a SQLite audit log recording the agent, the model, the tokens, and the transcript. Coordinator Role mechanical work inexpensive model Role mechanical work inexpensive model Role judgment expensive model brief names the files it may read every dispatch SQLite audit log agent model tokens transcript

Why it holds

  • Each role’s brief names exactly the files it may read.
  • Inexpensive models take the mechanical work. Expensive ones are saved for judgment.
  • Every dispatch is logged with the agent, the model, the tokens, and the transcript.
Simplified for clarity. This is a system I built and run.

Operations dashboard

One screen answering two questions: what is the system doing, and what needs me? Tasks, priorities, calendar, spending, and the overnight feed, read from the same database the agents write to and served on my own metal. Most infrastructure people cannot make a front end feel finished; most front-end people cannot make it run on your own hardware. I do both.

  • HTML/CSS
  • SQLite
  • self-hosted
See the dashboard diagramHide the diagram
Diagram of the operations dashboard loop Inside a boundary labelled my own metal, agents write into a SQLite database and one screen reads the same database, showing tasks, priorities, calendar, spending, and the overnight feed. Nothing in the drawing sits outside the boundary, and no cloud service appears anywhere. my own metal write read Agents SQLite database One screen tasks priorities calendar spending overnight feed

Why it holds

  • Reads the same database the agents write to.
  • Served on my own metal.
Simplified for clarity. This is a system I built and run.

Apps

Resurrection Drive is also an independent app studio. Small software, made carefully: quiet, offline, and it leaves your data where it is.

Emmie’s Night Light

A calm bedtime companion for iPad, built for my daughter: an ambient scene and a gentle sound bed that run all night. No accounts, no ads, no network access, nothing to configure at 8pm with an overtired kid. Built end to end and test-first, now at 180+ automated tests, with an overnight soak before it reached her nightstand. App Store release in progress.

More apps are in daily family use and will be released when they are ready.

The operator

I’m Nick Nghiem. I’ve spent twenty years in enterprise IT: networks, servers, security, and the automation that holds them together. My day job is in critical-communications infrastructure, where the product is a live connection and downtime means the product is failing. Beyond it, I built and run the AI system this page describes, and I take on outside work: fixed-scope projects, assessments, and automation builds, delivered on a schedule we agree to up front.

Every system on this page runs in production today, either at the company where I’ve spent the last decade or in the system I built and run for myself. What I haven’t done yet is deliver it independently for a client. If you’re first, you get the operator, not an agency markup.

How I work

Fixed scope or hourly. Nothing starts without a written scope: what is in, what is out, the price, the window. I scope honestly, tell you what it will cost to run after I leave, and put everything in writing. I keep a small number of engagements going at a time, and I don’t sell on-call: if you need a team on standby, I’ll say so and point you at one. A thirty-minute first look costs nothing.

Get in touch

Tell me what’s eating your team’s time, or the system nobody wants to touch. I’ll tell you honestly what it takes to fix, what it costs to run, and whether it’s worth the money.

[email protected] for project and consulting work
[email protected] for the apps