GSA/data.gov is the umbrella repository for the data.gov service

An umbrella repository with no application in it

The description of this repository is one line. It is the main repository for the data.gov service.

The important word is main, and the first thing to understand is that the code for the service is not here. The topics attached to the repository are ansible, infrastructure, provisioning, stack and terraform, which is the vocabulary of running services rather than writing them, and the top level contents match: a `bin/` directory, a `ckan/` directory, a `docs/` directory, an `egress/` directory, a `metrics/` directory, and the usual governance files in `CONTRIBUTING.md`, `SECURITY.md`, `SYSTEMS.md` and `LICENSE.md`.

So this is the repository that holds the shared infrastructure, the operational scripts and the documentation for a service that is itself split across several other repositories. A `SYSTEMS.md` file in the root is a strong hint at what the document is, since that name is the convention for describing which system a given set of credentials, hosts or endpoints belongs to.

The audience is twofold. For a maintainer, this is the place where the shared infrastructure lives and where the state of every component is visible. For anyone outside the agency, it is a map, and the map is more useful than it first appears, because the way a government service is decomposed into components is itself a design statement.

The repository is not archived and the last push was on 2026-10-16, so the shared infrastructure is still being changed.

The README is a deployment dashboard

The structure of the README is the most informative thing about it. It is a table titled Data.gov Actions, with one row per site or repository, and the columns are almost entirely badges.

This is unusual and it is worth understanding why. A badge for a commit workflow tells you whether the code is passing its checks. A badge for a deploy workflow tells you whether the last deployment succeeded. A badge for a restart workflow tells you whether the application was restarted cleanly. A Snyk security badge tells you whether the dependency scan is clean. Each of these is a piece of operational state that would otherwise live in a chat channel or a wiki page.

The rows name the components. `harvest.data.gov` points at the GSA datagov-harvester repository, `catalog.data.gov` at datagov-catalog, `inventory.data.gov` at the inventory-app, and `backup-manager` at the cf-backup-manager project. The final row is this repository itself, with badges for workflows that disable and enable the egress proxy.

So the table is a cross section of the whole service. It tells you that the harvester has a workflow to synchronise an OpenSearch index, that the catalog has a sitemap workflow, that the inventory app has a workflow to update the inventory publishers list and another to delete inactive users, and that the backup manager has an S3 backup monitor.

Each of those badge names is a small fact about the system architecture. A publisher list that has to be synchronised from somewhere, an inactive user cleanup that runs on a schedule, an OpenSearch index that has to be kept in step with the catalogue, and an egress proxy that can be switched on and off are all things you would otherwise have to ask a person about.

What the directories tell you about ownership

The directories in the root are where the interesting detail is, because each one names a piece of the service that this repository, rather than a component repository, is responsible for.

`egress/` is the clearest. An egress proxy is a network control point, and the presence of a directory for it here, along with workflows that disable and enable it, says that the service has a mode in which outbound traffic from its components is routed through a controlled proxy and a mode in which it is not. The workflows to switch between them are visible to anyone reading the README, which is a deliberate transparency choice for a government system.

`metrics/` is the other one. A metrics directory in the infrastructure repository usually means the collection and publishing of operational measurements for the services, and the fact that it sits here rather than in a component repository suggests that the measurement is a cross-cutting concern rather than a property of one application.

`bin/` holds scripts, which for an infrastructure repository is where the operational entry points live, the commands an operator runs rather than the code the services run.

`ckan/` is the one worth a second look, because the name points at CKAN, the open source data catalogue software, which suggests that the catalogue side of the service is CKAN-based rather than bespoke.

`docs/` holds the documentation that belongs to the service as a whole rather than to one component.

Each component is a separate repository with its own pipeline

The decomposition is the interesting design decision here, and it follows a pattern that is common in government platform work.

Each of the four component repositories has its own set of workflows, and the badge names are consistent across them. A commit workflow runs the checks. A deploy workflow publishes. A restart workflow restarts the running application. A Snyk workflow checks for known vulnerabilities. That is a coherent template applied four times, and it means a new engineer can look at any component and see the same four questions answered: does it build, did it deploy, did it come back up healthy, and is it free of known dependency issues.

The exception proves the rule. The backup manager's row does not have the commit, deploy and restart set, it has a single badge for a backup S3 monitor, and the badge is hosted in this repository's own actions rather than in the component's. Backups are the kind of function that has to be watched centrally, since a backup that silently stops is worse than no backup, and the monitoring schedule is a property of the platform rather than of the thing being backed up.

The same centralisation shows up in the inventory app, which has a workflow to update the inventory publishers list. The list of publishers is a shared piece of state, so keeping it in step is a platform job.

For a contributor, the practical effect is that the boundary between repositories is a real boundary. A change to harvesting behaviour belongs in the harvester, a change to the shared deployment belongs here, and the badge table is how you check that both halves are healthy before you assume a problem is in the code you are reading.

Where this repository is the wrong place to look

The limitation is the same one that comes with the umbrella pattern, and it is worth stating plainly for anyone arriving with an expectation of a normal application repository.

First, there is nothing to run here. There is no application, no package to install, no test suite to point at, and no command that starts a service. If you are looking for the code that serves the catalogue, it is in the catalog repository, and the code that harvests data is in the harvester repository. The README's job is to point you at them.

Second, the operational state in the badge table is a snapshot, not a source of truth. A green badge means the last run of that workflow was green, on whatever branch and at whatever commit the badge is for. Reading a dashboard of badges is a fast way to answer a rough question, such as which component is unhealthy right now, but it is not an audit trail and it will not tell you why a deployment failed.

Third, the documentation in `docs/` is service level documentation. It describes the system as a whole, its components and its operations, and it will not contain the API reference of any individual component.

The alternative to reading this repository is, in practice, to read the component repositories directly, and to use this one as the map. The difference in approach is that a component repository shows you one service in detail, while this one shows you the decomposition, the shared infrastructure and the health of the whole. For a contributor, both are needed and the order matters, this one first, because it tells you which component owns the thing you are about to change and which shared infrastructure it depends on.

One last practical note is the licence. The repository's licence is not one GitHub can classify, so the LICENSE file in the root is the text to read, and for code that is deployed as a government service that file is the reference, not the badge.

Editorial conclusion

data.gov suits an engineer who needs to understand how the service is deployed, which component owns which part, and whether the automated pipelines are currently green, and it is the right first stop for anyone contributing to the service. It is the wrong repository for the catalogue code, the harvesting code or the inventory application, since each of those lives in its own project. Check first the component you care about in the README table, because the badge column there is the fastest way to see which pipeline is failing, and note that the licence file is a custom one that GitHub does not classify.

Frequently asked questions

Official sources

1. GSA/data.gov on GitHub
2. Issues
3. Project website
4. README