Technical Deployment & Infrastructure Guide

1. Purpose of This Document

This guide provides the technical detail that a school IT team needs to set up, secure, and maintain the backend infrastructure for the platforms described in Fieldtripping with AI. It covers the server environment, authentication architecture, data ingestion from school information systems, deployment procedures, and security posture. It is written for IT administrators who may be deploying these tools in their own school context, or supporting an educator who has built them in partnership with AI.

The guide reflects the infrastructure deployed at Your School, but is written to be adaptable. Where our setup uses specific products (Windows Server, IIS, Fortigate), we note where alternatives exist and how the same principles apply in different environments.

2. The Security Problem This Solves

Before discussing the technical architecture, it is worth understanding the security problem that existed before this infrastructure was built — because it is the same problem that exists in almost every school running camps, excursions, and off-site programs.

The Traditional Approach: PII Everywhere

The traditional method of managing student information on a school trip involves printing staff camp books — bound documents containing student medical records, dietary requirements, allergy alerts, emergency contacts, room allocations, and parent phone numbers. These books are photocopied and handed to every staff member. They travel in backpacks, sit on restaurant tables, get left in hotel rooms, and are carried through busy city streets. When the trip is over, they are supposed to be collected and destroyed. In practice, they end up in desk drawers, car boots, and recycling bins. This is not a theoretical risk: the author has personally experienced a trip where a staff member left the camp booklet — containing the full medical, dietary, and emergency contact details of every student — in a café. The booklet sat on a public table, accessible to anyone, until another staff member happened to notice it was missing.

Alongside the printed books, the same information lives in spreadsheets on shared drives, in email attachments sent to staff before departure, in WhatsApp group chats where dietary requirements are discussed, and in paper notes taken during the trip. Every copy is unencrypted, untracked, and beyond the control of the school's data governance framework.

What Purpose-Built Infrastructure Solves

The platforms described in this guide consolidate all sensitive student data into purpose-built applications with the same authentication, access control, and audit logging that the school applies to its core systems. Medical data is never printed. It is never emailed. It is never in a spreadsheet on someone's laptop. It lives in an encrypted, access-controlled application that requires Microsoft Entra ID (Azure AD) authentication to access, that logs every access event, and from which access can be revoked in real time by removing a user from an Azure AD security group.

This is not a marginal improvement over the traditional approach. It is a fundamentally different security posture — one that brings excursion data management into line with the standards schools already apply to their student information systems but have historically failed to extend to off-site programs.

3. Architecture Overview

The infrastructure comprises three distinct components, each with its own deployment model:

Network Topology

All web-facing applications run on a single Windows Server 2022 virtual machine (VMware vSphere) on the school's internal network. The server is not directly internet-accessible. External access is routed through a Fortigate firewall via a port-forward rule to the server's internal IP. All traffic is SSL-encrypted via a certificate bound in IIS.

Backend applications (Node.js processes) run on localhost ports and are never directly exposed to the internet. They are accessible only through the AppPortal reverse proxy, which handles authentication before forwarding any request. This means a backend application does not need to implement its own authentication — it receives requests only after AppPortal has verified the user's identity and group membership.

4. AppPortal: The Authentication & Proxy Layer

AppPortal is the centrepiece of the security architecture. It is a custom-built web application dashboard that provides a single, secure entry point for all school web applications. It was designed in partnership with Claude Code and serves two critical functions: it authenticates every user via the school's existing Microsoft Entra ID tenant, and it acts as a reverse proxy that routes requests to backend applications only after verifying identity and group membership.

4.1 Authentication: Microsoft Entra ID (Azure AD)

AppPortal uses Microsoft's OpenID Connect (OIDC) protocol integrated with the school's Azure AD / Entra ID tenant. This means:

• No separate usernames or passwords — users log in with their existing school Microsoft account
• Multi-factor authentication (MFA) is enforced if the school's Azure AD conditional access policies require it
• Session tokens are managed securely and expire automatically
• Works on any device or browser — staff on school computers, students on personal phones

This is the same authentication layer that protects the school's email, Teams, SharePoint, and every other Microsoft 365 service. By using it for custom-built applications, those applications inherit the same security posture — including conditional access policies, sign-in risk detection, and centralised audit logging — as the school's enterprise systems.

4.2 Two-Layer Access Control

Every application registered in AppPortal has two independent access gates, both of which must pass before a user can reach the backend:

Gate 2 runs on every request, not just at login. This means access can be revoked in real time by removing a user from an Azure AD security group — the next request they make will be denied. This is a stronger access control model than many commercial SaaS products, which typically check permissions only at login.

4.3 Reverse Proxy (YARP)

AppPortal uses YARP (Yet Another Reverse Proxy), a Microsoft-built proxy library, to forward authenticated requests to backend applications. Backend apps run on localhost ports and are never directly internet-accessible. URL paths are rewritten so users see clean URLs (/tools/icons/) while backend apps receive requests at their own root.

4.4 Role-Based Access

AppPortal uses Microsoft Graph API to resolve the authenticated user's Azure AD group memberships, then matches these against the allowedGroups configured for each application. The audience model supports staff, primary students (Years 1–6), secondary students (Years 7–12), all students, all users, and admin-only access. Group membership is resolved from Azure AD in real time using the school's existing group structure — no additional directory or user database is required.

4.5 Configuration

Applications are registered in a JSON configuration file on the server. Adding, removing, or modifying applications requires editing this file — no code changes or redeployment needed. A new proxied application requires an app pool recycle command (Restart-WebAppPool -Name "AppPortal"). Changes to name, description, audience, or groups take effect immediately.

4.6 Logging and Audit

AppPortal logs all activity using Serilog to daily rolling log files. Logs capture every login event, every dashboard load (with user identity and number of tiles shown), every application access (with username, path, status code, and response time), and all errors with full exception details. This provides a complete audit trail of who accessed what, when, from which device — the same level of audit logging that schools expect from their student information systems.

5. School Information System Integration

The Staff Companion iOS app is powered by data ingested from the school's existing information systems via their APIs. This section describes how the integration was designed, how security was handled, and how other schools can adapt the approach for their own systems.

5.1 Why API Integration Matters

Every modern school information system — whether it is Synergetic, TASS, Compass, Sentral, SIMON, or another platform — provides APIs (Application Programming Interfaces) that allow authorised software to request data programmatically. Schools already use these APIs to feed data into timetabling systems, learning management systems, finance platforms, and reporting tools. The same APIs can be used to feed data into purpose-built educator tools.

The alternative — manually exporting data to spreadsheets and retyping it into applications — introduces transcription errors, creates stale data (the spreadsheet is out of date the moment it is exported), and produces uncontrolled copies of sensitive information on local machines, USB drives, and email attachments.

5.2 How the Integration Was Designed (with AI)

The API integration was co-designed with Claude Code. The AI helped with:

• Identifying available endpoints — reading the API documentation for the school's information system and identifying which endpoints provide medical data, dietary requirements, emergency contacts, and enrolment information
• Designing the authentication flow — implementing OAuth 2.0 client credentials flow to authenticate against the API without user interaction
• Writing the ingestion script — a Python script that authenticates, requests specific data fields, transforms the response into the format required by the iOS app, encrypts the output, and writes it to the Xcode project directory
• Designing the security model — ensuring credentials are stored as environment variables on the developer's local machine, never appear in source code, and never pass through the AI

5.3 Security Architecture for API Credentials

The credential management follows industry best practice:

5.4 Adapting for Other School Information Systems

The approach generalises to any school information system with an API. The key steps for an IT team are:

1. Identify the API — check your SIS documentation for REST API endpoints. Most modern systems (Synergetic, TASS, Compass, Sentral) provide these. If your system only provides CSV exports, the same ingestion script can read CSV files instead of calling an API.
2. Request API credentials — work with your SIS vendor to obtain API client credentials with read-only access scoped to the minimum required data fields.
3. Set up the ingestion environment — a secured machine (the developer's workstation or a dedicated build server) with credentials stored as environment variables. The AI partner can help write the ingestion script for your specific API.
4. Schedule or trigger ingestion — run the script before each trip to pull current data. For a week-long trip, running it the day before departure ensures data is current. For longer programs, consider scheduling daily ingestion.
5. Audit the data flow — document which fields are extracted, where they are stored, and who has access. This documentation supports compliance with your school's data governance and privacy obligations.

6. Deployment Procedures

6.1 Server Setup (One-Time)

The following describes the initial server setup for a school deploying this infrastructure for the first time:

1. Provision a Windows Server VM — Windows Server 2022 on VMware vSphere (or Hyper-V, or any hypervisor). Allocate a minimum of 2 CPU cores, 4 GB RAM, and 100 GB disk. Assign a static internal IP.
2. Install IIS — enable the Web Server role with the ASP.NET Core Hosting Bundle (version 8.x or later).
3. Install Node.js — LTS version (currently 22.x). Install PM2 globally (npm install -g pm2) for process management of backend Node.js applications.
4. Configure SSL — purchase an SSL certificate (or use a wildcard certificate if available) and bind it in IIS to port 443. All traffic must be HTTPS.
5. Configure the firewall — create a port-forward rule on the school firewall (Fortigate, pfSense, SonicWall, etc.) routing external HTTPS traffic to the server's internal IP on port 443.
6. Register an Azure AD application — in the school's Entra ID (Azure AD) portal, register a new application with OpenID Connect. Configure the redirect URI to match the public URL. Grant the application the necessary Microsoft Graph permissions for user identity and group membership resolution. Record the Client ID, Tenant ID, and Client Secret for AppPortal configuration. Consult Microsoft's documentation for the minimum required permission scopes.
7. Deploy AppPortal — extract the AppPortal build to [install directory]\AppPortal\. Configure the application settings with the Azure AD credentials. Create an IIS application pool named "AppPortal" and an IIS site pointing to the AppPortal directory.
8. Configure apps.json — register each backend application with its ID, name, description, audience, allowed Azure AD groups, and localhost port. See the companion document How to Add a New App for detailed instructions.

6.2 Deploying a Backend Application (Melbourne Icons, Explore Zones)

1. RDP into the application server
2. Copy the application files to a directory under [install directory]\apps\ (e.g. [install directory]\apps\[app-name]\)
3. Install dependencies: npm install --production
4. Start the application with PM2: pm2 start server.js --name [app-name] -- --port [port]
5. Save the PM2 process list: pm2 save
6. Register the application in the configuration file with the assigned localhost port
7. Recycle the AppPortal app pool: Restart-WebAppPool -Name "AppPortal"
8. Test: log in to AppPortal with a user account in the configured allowedGroups and verify the tile appears and the application loads

6.3 Deploying the Staff Companion iOS App

1. Run the data ingestion script on the secured build machine to pull current student data from the school information system
2. Open the Xcode project on a Mac with the latest Xcode installed
3. Verify the data files in the project are up to date (students, staff, schedule, locations)
4. Build the project (Cmd+B) and resolve any warnings
5. Connect each staff iPhone via USB and deploy the app to the device
6. Have each staff member open the app and verify their data access

6.4 Deploying Explore Zones (Student GPS Maps)

Explore Zones is a lightweight web application with no student authentication requirement — it does not contain any personally identifiable information. Students access it via a URL or QR code on their phones. The admin interface (where staff create and manage zones) is protected behind AppPortal's authentication layer. Deployment follows the same Node.js/PM2 process described in 6.2.

7. Security Posture

This section summarises the security measures across the entire platform, from network layer to application layer to data handling.

7.1 Network Security

• All traffic is SSL/TLS encrypted (HTTPS enforced)
• Backend applications run on localhost and are never directly internet-accessible
• The only public-facing component is the AppPortal reverse proxy, which authenticates before forwarding any request
• Fortigate firewall rules restrict inbound traffic to HTTPS on port 443 only
• The server has no other public-facing services

7.2 Authentication and Authorisation

• Microsoft Entra ID (Azure AD) provides enterprise-grade authentication via OpenID Connect
• Multi-factor authentication (MFA) is enforced where configured in the school's Azure AD conditional access policies
• Two-layer access control (tile visibility + proxy access) verified on every request
• Access revocable in real time by changing Azure AD group membership
• Session tokens expire automatically
• No separate user database — all identity management through the school's existing Azure AD tenant

7.3 Data Security

• Sensitive student data (medical, dietary, emergency contacts) is never printed, never emailed, never stored in spreadsheets
• Data is ingested from the school information system via authenticated API calls, encrypted, and bundled into the iOS app at build time
• API credentials are stored as environment variables, never in source code or version control
• The iOS app stores data on-device (no cloud sync, no runtime API calls)
• SQLite databases for web applications are stored on-server with no external access
• No student PII is stored in or transmitted through the scavenger hunt or GPS boundary systems

7.4 Audit and Compliance

• Every authentication event, dashboard load, and application access is logged with user identity, timestamp, path, and response code
• Logs are stored on-server in daily rolling files, accessible to IT administrators
• The data flow from school information system to iOS app is documented and auditable
• The platform meets the practical requirements of the Australian Privacy Principles (APPs) as they apply to educational institutions handling student data

7.5 Comparison: Traditional vs. Purpose-Built Security

8. The Role of AI in Designing This Infrastructure

The infrastructure described in this document was co-designed with Claude Code, an AI development tool. It is important for IT teams to understand exactly what the AI did and did not do, and how security was maintained throughout the process.

8.1 What Claude Code Did

• Designed the AppPortal architecture — the authentication flow, the YARP reverse proxy configuration, the two-layer access control model, and the role-based dashboard
• Wrote the ASP.NET Core application code, including the OpenID Connect integration, the Microsoft Graph API calls for group resolution, and the Serilog logging configuration
• Designed the API integration architecture — the credential management model, the ingestion script, the data transformation pipeline, and the encryption layer
• Wrote the backend Node.js applications (Melbourne Icons, Explore Zones) including the database schema, API routes, and frontend interfaces
• Built the Staff Companion iOS app in Xcode — the Swift code, the interface layouts, the offline data model, and the integration with iOS features (phone calls, SMS, Apple Maps)
• Helped write this documentation and the associated IT procedures

8.2 What Claude Code Did Not Do

• At no point did the AI have access to actual API credentials, student data, or any personally identifiable information
• The AI did not access the school's Azure AD tenant, information system, or any production system
• The AI did not make decisions about which data to collect, who should have access, or how the tools should be used pedagogically — these decisions were always made by the educator
• Deployment to the production server was performed manually by the developer — the AI wrote the code, the human deployed it

8.3 Security Testing with AI

Claude Code was also used to review and test the security of the deployed applications. This included:

• Reviewing the authentication flow for common vulnerabilities (session fixation, token leakage, CSRF)
• Testing the access control model by simulating requests from unauthorised users and verifying that Gate 2 correctly denied access
• Reviewing the SQL queries in the scavenger hunt platform for injection vulnerabilities (all queries use parameterised statements)
• Checking file upload handling for path traversal and size-based denial of service
• Reviewing the ingestion script for credential leakage, ensuring no secrets appear in logs, error messages, or stack traces
• Producing a system health report after the live event, verifying database integrity, checking for failed requests, and analysing error logs

9. Alternative Deployment Models

The architecture described above reflects a specific school environment. Other schools may have different infrastructure, and the same applications can be deployed in several alternative configurations.

9.1 Cloud Deployment (Azure / AWS / GCP)

Schools without on-premise Windows servers can deploy the entire stack to a cloud virtual machine. Azure Virtual Machines are a natural fit given the existing Azure AD integration. The VM runs the same IIS + AppPortal + Node.js stack. The main consideration is network latency — for applications used primarily while students are in a specific city, an Australian data centre (Azure Australia East or Southeast) is recommended.

9.2 Linux Server

AppPortal can be deployed on Linux using Kestrel (the built-in ASP.NET Core web server) behind Nginx or Caddy as the reverse proxy, replacing IIS. Node.js and PM2 run natively on Linux. This eliminates the Windows Server licence requirement and may suit schools that prefer Linux infrastructure.

9.3 Container-Based Deployment

For schools with Docker or Kubernetes infrastructure, each component can be containerised. AppPortal, each backend application, and the database can run in separate containers orchestrated by Docker Compose or Kubernetes. This provides deployment reproducibility and simplifies scaling if the platform is used across multiple simultaneous trips.

9.4 Managed PaaS

Azure App Service or AWS Elastic Beanstalk can host the .NET and Node.js applications without managing a virtual machine. Azure App Service has native Entra ID integration, making the authentication setup straightforward. This is the lowest-maintenance option but may have higher running costs than a single VM.

9.5 Google Workspace Schools

Schools using Google Workspace instead of Microsoft 365 can adapt the authentication layer to use Google OAuth 2.0 and Google Cloud Identity for group-based access control. The AppPortal codebase would need modification to use Google's identity provider instead of Microsoft's, but the architectural principles — SSO, group-based access, reverse proxy, audit logging — remain identical.

10. Ongoing Maintenance

11. Continuous Improvement

Like any production system, the infrastructure should be reviewed regularly for opportunities to improve resilience, automation, and security posture. Areas to consider include: token cache persistence, automated deployment pipelines, uptime monitoring and alerting, Mobile Device Management (MDM) integration for app distribution, and automated database backups. Work with your IT team and, where appropriate, your AI development partner to identify and prioritise enhancements specific to your environment.

Appendix A: Port Allocation

Each backend application is assigned a unique localhost port number. Maintain a port allocation register as part of your server documentation. Recommended practice is to use a contiguous range (e.g. 5000–5090) with each application assigned the next available port.

Appendix B: Administration Commands

Your IT team should maintain a runbook of common administration commands for your specific environment. Key operations to document include: recycling the AppPortal application pool after configuration changes, starting and managing PM2 processes, viewing application logs, checking port usage, and testing SSL certificates. These commands will vary depending on your server operating system and firewall vendor.

Fieldtripping with AI — Technical Deployment & Infrastructure Guide
Technical Reference Document — March 2026
Your School