Transitous: a community-run transit router over GTFS feeds

The goal statement is a policy, not a feature list

Transitous describes itself in one short line as free and open public transport routing. The goal section below it is longer and matters more. The service is meant to focus on the interest of the user rather than on the public transport operators, to be free to use, to value user privacy, to not stop at borders, and to aim at crowd-sourced maintenance of data feeds in the spirit of FOSS. Read as a whole, that is a policy statement about who the routing service answers to, and it explains the shape of the repository: feeds are contributed and maintained by the community rather than licensed from a single operator's portal. The primary language is Lua, the topics are gtfs, public-transport and transit, and the homepage is transitous.org. If you were expecting a hosted consumer journey planner, this is not that product. It is the working surface for people who want to operate or contribute to such a planner themselves.

feeds/ and configs/ carry the region model

The README says almost nothing about the pipeline, so the top level of the repository does the explaining. feeds/ holds the data side, configs/ the configuration side, src/ the source, scripts/ the tooling and docs/ the prose. Three of the other entries are worth naming. ansible/ points at machine provisioning for running services. ci/ sits next to .github/ and .woodpecker/, which is the layout of a repository that keeps its pipelines in more than one place. .devcontainer/ points at a containerised developer environment. transitland-atlas appears at the top level beside .gitmodules, which is the conventional pairing for a tracked submodule rather than copied source. That feeds/ is a top level directory at all is the clearest signal of the crowd-sourcing goal. A region arrives as a directory of feed definitions, and other people maintain it afterwards. The topics name GTFS, so the interchange format in view is a static schedule with optional realtime companions.

Release tags track the motis engine version

The release history is where the routing engine becomes visible. The three most recent tags are motis-v2.11.3 on 2026-09-10, motis-v2.11.2 on 2026-08-12 and motis-v2.11.1 on 2026-08-08. The naming is informative on its own. The version numbers belong to motis, so what the repository versions and publishes releases against is the engine's version rather than a project-owned number for the orchestration and data layers around it. The spacing of those three dates also says something: a month between the first two and four days between the last two, which looks like bursts around engine changes rather than a fixed cadence. The repository is not archived and the last push was on 2026-10-20, so work continues. The release tags, however, trail that push by roughly five weeks, and the repository does not say whether the commits since are a release in preparation or ordinary work.

Region setup starts on the website, not in the repository

There is no install command in the README, and none of the repository files in view contain one either. What the README offers is a pointer: the documentation for adding a region lives on the project website, under the adding-a-region page. So the first real step is to open https://transitous.org/doc/#adding-a-region and follow the region procedure there, rather than to clone and build. The Python dependency file shows what the tooling around feeds expects to find in an environment, and it is an unpinned working set, with no version numbers given:

requests
types-requests
ruamel.yaml
license-expression
pycountry
beautifulsoup4
lxml
toml
tzdata

None of those entries are pinned, so a reproducible environment depends on whatever the website documentation or the CI configuration prescribes. The .devcontainer/ directory is the more likely route for a contributor who wants a working environment, and the ansible/ directory points at a server side deployment path for operators.

REUSE.toml and per-file SPDX tags settle licensing file by file

Repository level licence metadata reads as unknown, so the files themselves are the reliable source. The README opens with an SPDX-License-Identifier: CC0-1.0 header and the same header sits at the top of requirements.txt. A LICENSES/ directory and a REUSE.toml file appear at the top level as well. That combination is the REUSE convention, in which each file carries a machine readable licence tag and REUSE.toml records the cases where a file cannot carry one. license-expression appears in the dependency list, which is the sort of helper a tooling setup would use to resolve those expressions. This is not legal advice, and the practical conclusion is narrow rather than sweeping: check the SPDX tag on the specific file you intend to copy, because the repository does not resolve to a single identifier on your behalf.

ansible/, ci/ and a devcontainer hint at the operational shape

The pipeline directories say more about how Transitous is maintained than the README does. A .woodpecker/ directory alongside .github/ and ci/ is consistent with a self-hosted continuous integration setup rather than a single hosted service, and .devcontainer/ points at a containerised developer environment that can be brought up without assembling one by hand. ansible/ at the top level points toward configuration managed deployment, which fits a service expected to run for many regions on separate infrastructure. CODE_OF_CONDUCT.md and AI_POLICY.md are also present at the top level, so the project publishes a contributor code of conduct and states a position on AI assisted contributions. None of this is described in the README, and none of the contents of those files are visible from the directory listing alone, so treat them as files to open rather than policies you can summarise from the entry list.

Where the repository stops short of documentation

Two constraints shape who should try this, and both come from what is missing. First, the setup path leaves the repository. The README itself sends region work to the website, and nothing in view gives you a command to stand up a routing instance, seed a feed or query a vehicle position. Second, the data scope is GTFS shaped. The goal section names GTFS, GTFS-RT and similar feeds, so realtime data arrives through those feeds, and a region whose operators publish nothing machine readable will not appear in the output no matter how good the router is. The visible release history is also thin in a way that matters for adoption, since the three most recent releases are all engine tags and the repository presents no separate versioning record of its own. If you need a turn by turn consumer app with a support contract behind it, this is the wrong shape of tool.

Editorial conclusion

Transitous suits contributors who want to run a provider-neutral transit router or add a region, and operators who already publish GTFS and can maintain a feed definition. It does not suit teams looking for a hosted journey planner, a documented HTTP API or a commercial support contract, because the setup path lives on transitous.org and the repository ships no install command of its own. Before adopting, read the adding-a-region documentation, check the SPDX tag on the files you intend to reuse, and match your build against the motis-v2.11.3 release.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. public-transport/transitous on GitHub
4. README
5. Releases