The web app of MyPreflight platform. The electronic flight board itself: dispatch, briefing, check-in and live tracking, in the browser.

About

MyPreflight is a briefing service and electronic flight board app for your virtual flights, providing you realistic figures, checklists, procedures and data to perform your flight like a real pilots do. You can customize your experience, integrate with SimBrief and other tools. Check out our homepage at mypreflight.io. The app itself runs at app.mypreflight.io.

This module is the part running in your browser. It is where every role does its work:

• dispatches flights — schedules, fleet, crew and passengers, preliminary loadsheet and fuel figures,
• walks the pilot through check-in, boarding, off-block, airborne and on-block, with the timesheet, the OFP and the final loadsheet filled at finish-boarding,
• draws the live map from the ADS-B feed and the flight event stream, and gives every flight a public link to share,
• keeps the airport library — runways, terminals, parking positions, gates and NOTAMs,
• installs as a PWA on desktop and phone, and prompts to reload when a new version ships.

The API lives in mypreflight/api and the desktop companion in mypreflight/transponder-app.

Built with

A React Router SPA — ssr: false, no server of its own, deployed as static files. Code is sliced by domain under app/features/<domain>, each owning its service, model and components; state is React Context only, no store library. Forms are Formik with Yup schemas, maps are Leaflet, and the tracking dashboard listens on a socket.io flight event stream.

Getting started

Requirements

• Node 26 (see .nvmrc)
• A running MyPreflight API — locally or the production one. Without it you get no further than the sign-in screen.

Install with a local API (recommended)

1. Clone both projects:

   git clone git@github.com:mypreflight/app.git
   git clone git@github.com:mypreflight/api.git

2. Prepare an environment variable file by copying .env to .env.local and fill it with your data.

   cd app
   cp .env .env.local

   .env holds the production defaults, so point the copy at your local API:

   VITE_NODE_ENV=development
   VITE_FLIGHT_TRACKER_API_HOST=http://localhost
   VITE_ADSB_API_HOST=http://localhost:1080

3. Set up the API. Packages, database schema and seed data are configured automatically.

   cd ../api
   docker compose up -d --build

4. Set up this project:

   cd ../app
   nvm use          # optional
   npm install
   npm run dev

5. Open http://localhost:5173. The seeded accounts all share the password P@$$w0rd:

   Role	Username
   Operations	operations@example.com
   Cabin crew	cabin-crew@example.com
   Admin	admin@example.com

   The API's README lists the rest, including the users seeded with SimBrief, Google and Discord already connected.

6. Enjoy!

Install against the production API

Clone this repository alone, npm install, npm run dev, and leave .env as it is. There are no public accounts — you have to be registered already to sign in.

Environment

Variable	Required	Description
VITE_NODE_ENV	yes	development turns on debug surfaces, production marks the build as released.
VITE_FLIGHT_TRACKER_API_HOST	yes	Base URL of the API. The app throws on start without it.
VITE_ADSB_API_HOST	yes	Base URL of the ADS-B receiver serving live positions.
VITE_DISCORD_INVITATION_HASH	yes	Invite hash behind the "join the community" links.
VITE_GOOGLE_CLIENT_ID	no	Enables Google sign-in and account linking.
VITE_DISCORD_CLIENT_ID	no	Enables Discord sign-in and account linking.
VITE_CARTO_API_KEY	no	Removes the "API key required" watermark from the CARTO basemap tiles.

import.meta.env.PACKAGE_VERSION is injected by Vite from package.json.

Third-party sign-in is off unless configured. Leave both client IDs unset and the app runs on email and password alone, with no Google or Discord identity surface anywhere — VITE_DISCORD_INVITATION_HASH is separate and keeps working, because the community invite needs no client.

VITE_GOOGLE_CLIENT_ID must be the same OAuth 2.0 Web client ID as the API's GOOGLE_CLIENT_ID — the API checks the ID token's audience against its own value, and a mismatch surfaces as Google token is not valid. The app's origin has to be an authorized JavaScript origin on that client.

VITE_CARTO_API_KEY is the free key from carto.com/basemaps/apikey, appended to every basemap tile request as ?key=. Leave it unset and the maps still work, but CARTO stamps every tile with an "API key required" watermark. It is not a secret — it ships in the client bundle like any other VITE_ value — so restrict it to the app's origins on the CARTO side rather than treating it as confidential. The free allowance is 5 million tile requests per calendar month.

VITE_DISCORD_CLIENT_ID needs <origin>/auth/discord/callback registered as a redirect URI on the Discord application, exact match included (http://localhost:5173/auth/discord/callback for local dev). Discord OAuth is a full-page redirect, unlike Google's in-page token, and the deep link reaches the router through public/404.html plus public/ghspa.js — a rewrite that only exists in a built app, so test that flow on a build, not on npm run dev.

Development

npm run dev        # vite dev server with hmr on :5173
npm run lint       # biome, linter and formatter
npm run lint:fix   # biome, autofix
npm run typecheck  # react-router typegen, then tsc
npm run build      # production build into build/client

No test framework is configured; CI runs lint, typecheck and build.

Two things to know when working locally. The dev server mounts twice, so every API call fires about twice — production does not, so check network volume on a build. And the service worker and the GitHub Pages deep-link rewrite are absent from npm run dev entirely, so anything touching them needs npm run build and a static server on port 5173, which keeps the API's CORS origin valid.

Design context lives in PRODUCT.md, the visual system in DESIGN.md and the component inventory in docs/DESIGN_SYSTEM.md.

Build, test and deploy

This project uses semantic versioning. The version in package.json must be bumped before a pull request merges — bin/check_version_is_free fails the build otherwise.

Continuous integration and deployment run on GitHub Actions, configured in .github/workflows. Pull requests are linted, typechecked and built; a push to main builds, tags the release from package.json and deploys to GitHub Pages.

The deployed app is served from https://app.mypreflight.io. The custom domain is configured in the repository's Settings → Pages rather than a CNAME file, because release.yaml publishes through actions/deploy-pages. No URL is baked into the bundle — links are router-relative and the Discord redirect_uri and map share links are built from window.location.origin — but four registrations outside this repo are keyed to the origin and must name it: the DNS CNAME for app, the API's allowed CORS origins, the Discord redirect URI, and the Google authorized JavaScript origin. See the Deployment Domain section of AGENTS.md for the migration details.

Contact

My name is Oskar, an experienced programmer, cybersecurity enthusiast, and conference speaker from Poland. Feel free to contact me via the platforms below:

License

A public domain under the Unlicense. Do what you want with it. I am an experienced software engineer, but I am not connected anyhow with the airline industry. This project is created for educational purposes only and should not be used for real-world aviation operations.