Platform at a glance

The TunnelFlight platform is built as three apps that talk to a single shared database, plus this docs site. This page explains the layout in plain English. For wiring diagrams and code-level detail, see Infra → Architecture (C4).

The three apps

API — the brain

A backend service that owns all the business rules. Anything that matters — who can do what, what counts as currency, when a logbook entry is created, how skill prerequisites cascade — lives here. It exposes HTTP endpoints; the other apps and external partners (Convergence, FuzeMetrix, and the upcoming Tunn3l) talk to it.

WWW — the member-facing site

Where flyers, instructors, trainers, examiners and coaches sign in to manage their own records: viewing their logbook, requesting skills, paying fees, completing recurrent training, and updating their profile. This is what most members think of as “the IBA platform”.

Admin — the staff back office

A separate dashboard used by IBA staff and senior roles to administer the platform: managing members, processing change requests, overseeing currency cycles, configuring tunnels, and producing reports. Not visible to ordinary members.

Where this docs site fits

This site (the one you’re reading) is a fourth app focused on documentation rather than runtime. It lives at docs.tunnelflight.com, is internal-only (Cloudflare Access gates it), and hosts the Overview section, Tech docs, the API reference (Phase 4), and the in-platform chat (Phase 4). It’s deliberately separate from the WWW and Admin apps because its audience is engineers and partners, not flyers.

Shared infrastructure

A few pieces of infrastructure are shared across all three runtime apps:

• Database — a single MySQL database holds everything: members, bookings, logbooks, skills, fees, audit logs.
• Redis — used for sessions, short-lived caches, and the notification token store.
• JWT authentication — a shared session cookie means a member signed in to WWW can also access protected admin features without re-authenticating, if their role permits it.
• External services — Stripe (payments), Mandrill (email), AWS S3 / Google Cloud Storage (files), Sentry (error tracking).
• Infisical — secrets management; every app reads its config from Infisical at startup rather than from hand-edited environment files.

How the IBA’s rules are enforced

Almost every business rule lives in the API service. WWW and Admin are mostly UIs over the API — they don’t decide whether a flyer is current; they ask the API. They don’t decide whether an instructor can approve a Level 4 skill; they call the API and the API says yes or no.

This matters for two reasons:

1. Consistency — there’s exactly one place that knows the rules, so they can’t drift between the member-facing site and the admin dashboard.
2. Integrations — when Convergence, FuzeMetrix, or another partner talks to the IBA, they go through the same API the WWW and Admin apps use. The rules are identical from every direction.

Where the work happens

If you’re an engineer joining the team and trying to figure out where something is, the answer is almost always API first — and then either WWW or Admin if it has a UI.