xfb2xfb is a lookup table for the systems Facebook built internally

A table, not a framework

xfb2xfb describes itself as a lookup table of similar tech and services, by ex-Facebookers for ex-Facebookers, also known as Metamates, and the description in the repository says the same thing. There is no library, no service and no API. The entire artefact is a markdown file in the repository root, a table, and a small build that turns it into a website. The problem it addresses is narrow and real. Inside a large company, systems have internal codenames, and when engineers leave, that vocabulary becomes a liability. Someone knows the company calls its feature flag system Gatekeeper, or its configuration service Configerator, but has no idea what the equivalent is called outside. The table exists to translate the codename into a list of things you can actually install.

Three columns, plus a place for caveats

The structure is a four column table, and the columns are the interesting part. The first column is the Facebook internal name, the second is the open source or real world equivalent, the third is a cloud or commercial service, and the fourth is a Notes column. The fourth column is where the table admits uncertainty. Most rows leave it empty, but some fill it in, and those entries are the most valuable. The Dotsync row says there is no native support for automatically saving and loading configuration changes. The FBAR row expands the acronym as Facebook Auto-Remediation. The FOQS row notes that it is similar to Iris but more general, and that it was used to support Facebook's Async Tier. The FBurl row says self hosted URL shortener. A reader who only looks at the Notes column still learns something useful, which is a good sign for the parts of the table that are just lists.

The build turns markdown into a static site

The site is generated, and the package manifest shows how small the toolchain is. The whole project is an ES module package with a single dependency, `marked` pinned at version 17.0.5, and two scripts:

  "scripts": {
    "build": "node scripts/build.mjs",
    "start": "npm run build && node scripts/serve.mjs"
  },

The build script parses the markdown and the serve script runs the result locally, so a contributor only needs Node 20 or later to preview a change before pushing it. The repository layout is consistent with that design, with a `scripts/` directory holding the two scripts, a `site/` directory holding the generated output, and the README as the single source of truth. The primary language of the repository is CSS, which tells you where the effort went. The table is the content, and the sticky headers that keep the column headings visible while you scroll a long table are the main piece of presentation work.

Browsing it through the Pages workflow

The README gives an unusual but practical instruction for reading the site. It says to browse with sticky headers, open the latest successful run of the pages workflow, and then follow its github-pages website link. The reason is spelled out in the note that follows. This shortcut follows the current repository, so forks open their own site after enabling Pages, and a direct site link is also available in the repository's About section when configured. That is a deliberate design decision about forks. A lookup table like this gets forked by people who want to add a row for their own company's internal tools, and with a Pages workflow per fork, each of those forks publishes its own site rather than sending traffic back to the original. The cost is a slightly awkward first click for a reader who just wants the table.

What the rows actually cover

The entries are infrastructure, which matches the topics of infrastructure, infrastructure management and lookup table. Configerator, the configuration service, maps to Protoconf, Consul, etcd, ZooKeeper, Jsonnet, Cue and Dhall on the open source side, and to AWS AppConfig, AWS Systems Manager Parameter Store, Azure App Configuration and Google Secret Manager in the cloud column. DataSwarm, the workflow orchestrator, maps to Airflow, Prefect, Dagster, Luigi, Kedro and Argo Workflows, with Azure Data Factory, Google Cloud Composer, AWS Step Functions and Databricks Workflows as commercial options. FBTrace maps to Jaeger, Zipkin, LightStep, OpenTelemetry, SkyWalking and Pinpoint, with AWS X-Ray, Google Cloud Trace and Azure Application Insights in the cloud column. The Deltoid row covers experimentation platforms, listing GrowthBook, Wasabi and PlanOut against Statsig, Google Optimize, Optimizely, VWO, Adobe Target and Dynamic Yield.

The gaps are declared rather than hidden

One line in the README sets the scope of the whole project, and it is the line that makes the rest credible. It says no confidential projects, please. That is why the entries are codenames that were already public, and it also explains why some rows have only a thin answer. The inspirations are listed too, and they are worth reading for the shape of the project. The first is xg2xg, a similar table for Google, the second is a Venkat V Note on Facebook-like tools in the wild, and the third is a Martin K Post, both of them private and therefore visible only as names. So the table is a community effort that leans on earlier art and on internal writing that outsiders could not read, and the acknowledgement of that lineage is a good sign of how the project is run.

A static page with an unclear licence

The maintenance picture is straightforward. The repository is not archived, the last push was on 2026-10-09, and there are no GitHub releases, which is consistent with a project whose deliverable is a website regenerated from the README rather than a versioned package. The licence is the part that needs a decision from you. No licence is identified in the repository metadata, so the default position is that the content is not granted for reuse, even though the table is full of links to other people's open source projects and the point of it is to help people find those. If you want to fork it and publish your own site, that is exactly what the Pages workflow is set up for, but the licence file is where you should check what you are actually allowed to do, and the README gives no terms to rely on. The practical takeaway is that the table is good reference reading to link to, and something to be careful about republishing.

Editorial conclusion

Adopt xfb2xfb as a starting map when you are moving from Facebook internal infrastructure to something you can run yourself, since each row names the internal system and lists the open source, cloud and commercial options that map to it. Do not treat it as a decision guide, because the table is a list of candidates rather than a comparison, with no criteria, no licensing notes per entry and no support matrix. Verify first that the recommended option still fits your constraints, since the site is generated from a repository that had its last push on 2026-10-09, and check the Notes column, where the table records its own gaps, including the Dotsync entry that has no native support for saving and loading configuration changes automatically.

Frequently asked questions

Official sources

1. greko6/xfb2xfb on GitHub
2. Issues
3. README