Open source at the core. All of it.
The gtfs.media platform is a suite of GPL‑2.0+ modules for Drupal 10 and 11. The code that runs our managed deployments is the code you can install yourself; there is no enterprise edition.
Eight modules, five layers
Each layer depends only on the ones beneath it. Use just the data core, add realtime, or run the full display stack.
The suite
gtfs
The data core. Models the GTFS specification as structured Drupal entities — routes, stops, trips, stop times, calendars, shapes, and more — Import once, re-import forever: updates land in place and manual additions survive. REST endpoints cover everything it stores.
gtfs_rt
GTFS-Realtime ingestion. Pulls trip updates, vehicle positions, and service alerts from Protobuf endpoints on per-feed schedules and republishes them as a normalized JSON REST API, with async refresh for stale feeds.
gtfs_display
The display engine. Config-deployable display contexts for stops, routes, agencies, or whole systems; an offline-resilient vanilla-JS frontend with staleness UI, lockstep multi-screen paging, annotations and overrides, telemetry, and per-display permissions.
gtfs_display_map
Map utilities for the display stack. MapLibre GL vector rendering for feed geometry, configurable basemap styles, and the plumbing shared by every map surface.
gtfs_display_map_rt
The live layer. Realtime vehicle markers with heading arrows and per-vehicle custom liveries, stop popups with predictions, and the embeddable iframe map variant with its postMessage contract and CSP frame-ancestors control.
gtfs_schedule
Timetables. Renders route schedules by direction and service day from a GTFS server and agency — clean, accessible schedule pages for publishing or embedding.
gtfs_511
Regional provisioning. One settings form provisions static and realtime feeds for any operator on the 511 SF Bay open-data API — idempotent sync, four feed entities per operator.
gtfs_plus
GTFS+ compatibility. Extends the data core to understand the GTFS+ extension files used by some regional feeds.
Why Drupal
Transit data is content, and agencies have content teams.
An admin UI ops staff can use
Feeds, displays, annotations, and overrides are managed in forms — not YAML files and redeploys. Service change on Saturday? Your ops team handles it Friday afternoon.
Real permissions
Per-display access, role-based API grants, restricted admin — the permission system is Drupal's own.
Config as code
Display contexts and feed definitions are config entities: export them, review them in version control, deploy them through your normal pipeline.
Translation built in
Imported GTFS entities are translatable content — serve rider information in every language your community speaks.
Put your feed to work.
Start with the modules on your own Drupal site — and when you'd rather ship than host, we're one email away.