pkgsite, the source behind pkg.go.dev and a documentation server you can run

Two artifacts in one repository

The repository hosts two things that are often confused with each other. The first is the source code of the pkg.go.dev website, the public site where Go packages and modules are discovered and evaluated. The second is pkgsite, a documentation server program that extracts and generates documentation for Go projects. The second is the one you can install yourself, and it is the part that matters for a private module or an internal registry of your own, because the same code that renders the public site can render documentation for a project that never leaves your network. The project is part of the golang.org/x namespace, and the package path for the server program is golang.org/x/pkgsite/cmd/pkgsite. There is also a mirror arrangement to be aware of, since the canonical Git repository is at go.googlesource.com/pkgsite and the GitHub repository is a mirror of it, so a patch should go to the canonical one.

Generating docs for a module on your own machine

The example usage in the README is three commands, and it is the fastest way to see what the program does.

$ go install golang.org/x/pkgsite/cmd/pkgsite@latest
$ cd myproject
$ pkgsite -open .

The install uses the standard go install with a version of latest and the module path, and the server is then run against the current directory with the open flag, which starts it and opens a browser. The point of the tool is that the documentation is produced from the module in front of you, so a team that keeps a module internal can still have the same kind of package pages the public site serves. The README points to the documentation page for the program itself for more, and that page is served by the same machinery, which is a nice property, since the documentation tool documents itself.

A REST API for package, symbol and vulnerability data

The server exposes a REST API, and the endpoint list is short enough to take in at a glance. There is a package endpoint at /v1/package/{path} for information about a package, a module endpoint at /v1/module/{path}, a versions endpoint at /v1/versions/{path} for the versions of a module, and a packages endpoint at /v1/packages/{path} for the packages inside a module. Search results come from /v1/search, the symbols of a package from /v1/symbols/{path}, the reverse dependency information from /v1/imported-by/{path}, which lists the paths of packages that import a given package, and vulnerability data from /v1/vulns/{path}. For the parameter details and the response schemas there are two places to look, the documentation page served at /api, and the annotated source in internal/api/api.go. The imported-by endpoint is the interesting one for anyone building tooling on top, since it is a reverse dependency lookup that is otherwise expensive to compute.

The front end is TypeScript with a jest suite

The site layer is a modern JavaScript toolchain, and the package manifest shows how disciplined it is. The linting runs npm-run-all over a set of lint tasks, one for CSS through stylelint with the standard config and ordering rules, and one for TypeScript through eslint over the static directory. The tests are split in two, a type check with tsc --noEmit and a unit test run with jest against the static directory, using ts-jest and a jsdom environment, so the tests exercise the front end in a simulated browser. There is also a license check, jsgl --local ., which runs the js-green-licenses tool over the tree, and that fits a project that is itself a licence-conscious corner of the Go ecosystem. The toolchain asks for Node 20 or newer, and the dependency set is pinned hard, with exact versions for eslint, prettier, typescript and stylelint rather than ranges, which is a signal about how the site is built and released.

The Go side wants a database and Google Cloud

The go.mod is where the operational shape of the service becomes visible. The storage and platform dependencies are all Google Cloud libraries, with cloud storage, cloud tasks for background work, secret manager, error reporting, logging and the profiler, and an OpenCensus exporter for Prometheus, which points to a deployment on Google Cloud rather than a single machine. The persistence layer is relational, with the Postgres driver jackc/pgx and lib/pq, and the schema lives in db-schema.sql with a migrations/ directory and the golang-migrate tool, so the database is versioned rather than hand maintained. The frontend is assembled with esbuild, and the documentation pipeline uses golang.org/x/tools, x/mod, rsc.io/markdown and blackfriday, with safehtml and templatecheck for output safety and google/licensecheck for licence headers. Redis appears through the go-redis client and its rate limiter, with miniredis in the test dependencies for in-memory testing. In other words, this is not a documentation generator you point at a directory and forget, it is a service with a database, a cache, a queue and an object store, and running it locally means running those pieces too.

The repository is a service, not a script

The top level listing shows what a full application looks like. There is an internal/ directory holding the implementation, cmd/ for the command entry points, static/ for the front end assets and TypeScript, doc/ for documentation, deploy/ for deployment configuration, devtools/ for development helpers, migrations/ for the database schema history, and tests/ with a top level integration_test.go. A Makefile is replaced by all.bash, which is the usual Go convention for a script that runs the whole pipeline, and codereview.cfg holds the review configuration for the Gerrit style workflow the project uses. The JavaScript side has its own tooling files, jest.config.js, tsconfig.json, eslint.config.js and the prettier and stylelint configuration, and a package-lock.json alongside a .prettierignore and .stylelintignore. third_party/ holds vendored code that does not fit the module system. For a contributor, the practical consequence is that this is a codebase with a Go build, a Node build and a database schema that have to agree with each other, so a change to a response shape touches the API package, the front end types and the tests at once.

Where to file what, and what the licence covers

Issue handling is split across the Go project rather than this repository alone, and the README is explicit about it. For a bug or a feature suggestion you are asked to check the known issues label on the golang/go repository first, and to file a new issue through the pkgsite feedback form at golang.org/s/pkgsite-feedback if it is not already discussed. The issue tracker link in the links section points at golang.org/s/pkgsite-issues. Questions have their own page at pkg.go.dev/about, and there is a channel on the Gophers Slack, the pkgsite channel. The licence position is that the Go source files are distributed under the BSD-style licence in the LICENSE file unless otherwise noted, which is the standard Go project arrangement, and the tree also carries a PATENTS file. The project is not archived and the last push was on 2026-10-14, and the repository publishes no GitHub releases, since the artefact that matters is the site and the go install path, not a versioned binary.

Editorial conclusion

pkgsite fits a Go team that wants documentation generated for a private module without publishing it, and it fits a platform team that wants to run a Go package index of its own rather than depend on the public one. It does not fit a project that only needs godoc output, since the pkgsite server is a web application with a database behind it, and it does not fit someone who wants to extend the public pkg.go.dev experience, because the public site is run by the Go team on Google Cloud. Verify three things first: that the Go version and the database you have match what the migrations expect, that the module you point it at is one the tool can extract documentation from, and which upstream you are working against, since the canonical repository is at go.googlesource.com and GitHub holds a mirror.

Frequently asked questions

Official sources

1. golang/pkgsite on GitHub
2. Issues
3. License: BSD-3-Clause
4. README