expo.fyi: short links to the explanations nobody wants to inline

One path segment, one markdown file

expo.fyi is described in the repository description as little bits of information that you may find useful when interacting with Expo tools and service, with the instruction to append the markdown filename to https://expo.fyi/ to get a quick link to it.

The mechanism is smaller than the name suggests. The website is a URL shortener that redirects users to a markdown file in the github.com/expo/fyi repository. The example given is https://expo.fyi/bundle-identifier, which redirects to the file bundle-identifier.md on the master branch of the repository.

There is no database and no content store. The repository of markdown files is the content, and the service is a redirector in front of it. The root URL, https://expo.fyi, redirects to the GitHub repository itself, which is a sensible default for a service whose primary object is a folder of files.

And a name that does not exist is not handled by the service at all. You can add any arbitrary string like this-does-not-exist to the URL and it brings you to the GitHub 404 page, which the README treats as a documented behaviour rather than a bug, with the advice not to link to a file you have not created and not to delete a file that something already links to.

The primary language of the repository is listed as Shell, which tells you something about the service code and nothing at all about the content, because the content is the markdown files that live beside it.

The catalogue is the actual product

The top level of the repository is a flat list of markdown files, and the names are the index. A partial reading of the file list gives a good picture of what lives there.

The Apple and account material is there in quantity: bundle-identifier.md, apple-team.md, asc-app-id.md, asc-issuer-id.md, creating-asc-api-key.md, creating-google-service-account.md, apns-entitlement-sdk-51.md, apple-app-specific-password.md and apple-2fa-sms-issues-workaround.md.

The Android side has android-package.md, android-app-size.md, android-16kb-page-sizes.md, android-reset-keystore.md, android-r.md, authorize-android-device.md and bumping-android-version-code.md, alongside several build failure notes such as android-071-rc-build-failure.md.

The EAS and updates material is the largest cluster. There is eas-json.md, eas-project-id.md, eas-build-queues.md, eas-build-archive.md, eas-config-mismatch.md, eas-update.md, eas-update-rollouts.md, eas-update-asset-limits.md, eas-update-config.md, eas-update-missing-headers.md, eas-patch-package.md and eas-vcs-workflow.md, plus a file called cryptic-error-eas.md, which is the name of a thing every EAS user has searched for at least once.

There is also dev-client.md, expo-go-usage.md, credentials-non-interactive.md, dependency-validation.md, delete-build.md, embedded-assets.md, edge-to-edge-system-bars.md, deprecated-globals.md, auth-proxy-migration.md and expo-extension-migration.md.

Two observations follow. The naming is consistent, hyphenated and descriptive, which is what makes a mechanical redirect usable: you can guess the URL for a topic that is not in the list and be right. And several files are named after symptoms rather than concepts, which is the pattern you would expect from a repository whose purpose is to be linked to from a support answer.

Why a short link instead of a docs page

The README gives the reasoning in a paragraph, and it is the most useful part of the documentation for anyone deciding whether to use the service.

The scenario is that you are working on Expo CLI and want to add more context on some terminology you are using in a prompt to the user. Maybe you need to ask them for a bundle identifier. You want the user to have easy access to more information about what that means, but you do not want to inline a whole explanation of it and crowd the interface. At the same time you cannot be bothered to create a docs page for it, or maybe the existing docs page does not provide the most relevant context for the situation the user is in.

So the answer is a short link. The stated purpose is to remove any friction to create a shareable link to a persistent explanation of some piece of knowledge that is useful to developers using Expo tools.

That framing explains the whole shape of the project. A documentation site is heavy, versioned, searchable and slow to change, and it answers questions nobody asked. A folder of small markdown files with stable names answers one question well, and the friction of adding to it is the friction of a pull request that adds one file.

It also explains why the tool is a redirect rather than a hosting service. The explanation lives where it is edited, in version control, and the link is a stable handle for it.

Adding a file is the whole contribution workflow

Creating an FYI takes three steps, and the README is explicit that the extension matters.

You go to the expo/fyi repository, click Create a new file, and pick a name for it including the .md extension. The example given is that if you are teaching people about the tunnel connection type in expo-cli, you might call the file tunnel-connection.md, and then the URL is https://expo.fyi/tunnel-connection.

The extension is not optional decoration, because the redirect is built from the file name. That is also why the guidance in the FYI section warns against deleting a file that is already linked to from somewhere, since the link would then land on a GitHub 404 rather than on a useful explanation.

The service itself is a separate repository, expo/expo-fyi, and it is small enough to read in one sitting. The README says you can create your own domain like this by cloning that repository, describing it as a small service that you can deploy to, for example Vercel or Netlify, and that the URLs it uses are customised in index.js.

That last point is the interesting one for an organisation. A team that wants the same behaviour under its own domain, pointing at its own repository of explanations, can run the same service with the redirect target changed. The mechanism is not tied to Expo, and the customisation is a single file.

The limits of pointing a link at a moving branch

There are real constraints, and they all come from the same decision to redirect to a branch in a repository rather than to host anything.

The redirect targets the master branch, so the content a link points to is whatever that file says at the moment it is followed. A link shared in a chat last year now shows today's wording, and if a file is rewritten, everyone who clicks the old link sees the new text without knowing it changed. For an explanation of an error message that is being fixed, that is arguably a feature, since the reader gets the current answer. For an explanation of a concept where the precise wording matters, it is a hazard.

The second constraint is lifetime. The service holds nothing, so a deleted file is a dead link, and the repository's own guidance says not to delete a file that is already linked to. There is no redirect map, no tombstone and no archive.

The third is discoverability. The catalogue is a flat list of files, and while the naming convention makes guessing easy, there is no index page generated for readers and no search. Someone arriving at a link has arrived at the answer, which is the design, but someone hoping to browse what exists has only the repository view to work with.

On the project itself, the repository is not archived and the last push was on 2026-09-15, so the catalogue is being added to. There are no GitHub releases, which is what you would expect from a repository whose unit of content is a file rather than a package, and the licence is not declared in the repository metadata, so if you want to reuse a specific note you should ask before copying it.

Editorial conclusion

expo.fyi fits an Expo developer who keeps needing to explain the same term to a colleague, a support answer or a code review, and wants a link that survives in a chat message rather than a paragraph that has to be rewritten each time. It does not fit a project that needs a documentation site with versioning, navigation and search, and it does not fit anyone who needs the link to keep working after the repository moves. Verify three things before you point anyone at one of these links: that the file name in the repository is exactly the path segment you are sharing, since the mapping is mechanical, that the file is still there, because the service redirects rather than hosting and a deleted file becomes a GitHub 404, and that you are linking to the master branch, which is the only branch the redirect targets, so a link published today reflects whatever that file says now.

Frequently asked questions

Official sources

1. expo/fyi on GitHub
2. Issues
3. README