Xe/site is a personal website with a Go backend attached

The README opens by telling you not to use the code

Most project READMEs explain how to install something. This one opens with the opposite instruction, and the tone is worth quoting because it explains the rest of the repository.

The author writes: Don't. This code is not made for you to be able to use without extensive modification. The licence of this code is intentionally chosen in such a way that it will make reuse of this website code verbatim very difficult.

Four conditions follow for anyone who is still set on using the backend. All blog content is all rights reserved, and the author says they aggressively pursue and report content theft. You must fully comply with the licence. You are on your own, because this is code made for himself, and it is only really open source as a side effect of making deployment on NixOS easier. And upon security issues being found and remediated, you will not be notified about issues or remediation instructions.

That last point is the one that matters most for an evaluation. A site with an admin panel, a database and a webhook endpoint is attack surface, and this repository explicitly declines to inform outside users when something is patched. Anyone planning to run this code for an audience of their own needs to accept that they would be operating an unmaintained fork of someone else's site with no security contact.

One repository holds Go, protobuf, Node, Dhall and Kubernetes

The repository description says it is the new frontend/backend code for xeiaso.net, and the tree confirms that both halves live together. The top level carries go.mod with the module path xeiaso.net/v4, alongside package.json for the Node tooling, buf.yaml, buf.gen.yaml and buf.lock for the protobuf pipeline, a proto/ directory and a gen/ directory for the generated code, and a web/ directory for the front end.

The Go dependency list shows what the backend actually does. There is a Postgres stack with gorm and the pgx driver, gRPC with the twirp server implementation, an S3 client from the AWS SDK for Go v2, Prometheus instrumentation on both the client and the gorm plugin, and a Kubernetes client. Sessions come from gorilla/sessions, OAuth from golang.org/x/oauth2, and there is a Patreon client, which lines up with the sponsor panel the package scripts build.

The build tooling is its own ecosystem. config.dhall and a dhall/ directory sit alongside lume/, a .pages.yml file, an Earthfile, docker-bake.hcl, a docker/ directory, fly/ and a manifest/ directory, plus a .tekton/ directory for a second deployment path. Nix is in the topic list and there is a shell.nix. The result is a repository where the site, the content pipeline and the infrastructure definitions are versioned together, which is a deliberate choice by one person who owns all of it.

npm run generate is the step everything else depends on

The package scripts describe the pipeline precisely, and they are the closest thing to documentation in the repository.

  "scripts": {
    "test": "npm run generate && go test ./...",
    "generate": "go generate ./... && buf generate && go run ./cmd/xesitectl merge-openapi",
    "format": "go tool goimports -w . && buf format -w",
    "extract-meta": "node scripts/extract-meta.js",
    "validate-content-dates": "node scripts/validate-blog-dates.js"

Three separate generators run before anything else. Go's own generate pass produces Go code from annotations in the tree, buf generate turns the protobuf definitions in proto/ into the Go and other bindings that land in gen/, and a Go command called xesitectl merges OpenAPI documents. The test script depends on that generation step, which tells you the generated artefacts are not checked in as a convenience, they are part of the build.

Two Node scripts handle content. extract-meta.js pulls metadata out of the site content, and validate-blog-dates.js checks the dates on blog posts. The date validator is a small thing to include and a good signal about how the site is maintained: content has a lifecycle that is checked by tooling rather than by memory.

Local development and Kubernetes deployment are both scripted

The dev script runs the site binary with a preview URL and a development flag, and the two deploy scripts point kubectl at two different clusters, one applying the manifest directory and the other applying the Tekton definitions.

    "dev": "go run ./cmd/xesite --site-url https://preview.xeiaso.net --devel",
    "deploy": "kubectl --context limsa-lominsa apply -k manifest",
    "deploy:ci": "kubectl --context admin@alrest apply -k .tekton",

The split between the two deploy paths is the interesting part. One applies a kustomize manifest, the other applies Tekton pipeline definitions to a cluster with a different context name, so continuous integration and manual deployment are separate routes to two distinct environments.

The environment variables the tooling expects are listed in a sample file at the root, which also shows that the sponsor panel talks to a webhook endpoint.

GITHUB_SPONSORS_SECRET=test-secret-from-env
WEBHOOK_URL=http://localhost:3000/.within/hook/github-sponsors

A separate command exists for the sponsor panel itself, and the repository carries an .env.example with test values for the same kind of settings. Together with the Patreon client in the dependency list, this tells you the site monetises sponsorship through GitHub Sponsors and Patreon, with a panel component built separately from the main binary.

The licence is the point, not an oversight

The licence situation is deliberately unusual and the README says so. The project is listed under the Zlib licence, with a LICENSE file at the root of the repository, and the README states the licence was intentionally chosen to make reuse of the website code verbatim very difficult. The package.json file separately records ISC in its license field, and the badges at the top of the README cover dependency status, licence, language count and repository size.

Zlib is a permissive licence in the usual sense, with a short grant and a clause about not holding the author liable for damage. What the author is doing with it is add friction rather than restriction: the licence permits use, and the README adds the obligation not to reuse the content, and states that violations will be pursued.

Read the LICENSE file directly if you need the exact terms. The practical guidance from the repository is unambiguous about what the author wants, and it is worth respecting rather than looking for a loophole.

For comparison, the author recommends Hugo or Zola and says they are going to be better maintained than this site will be. That is the alternative in the project's own words, and the difference in approach is obvious from the dependency lists: a general purpose site generator has no Postgres, no gRPC, no sponsor webhook and no Kubernetes manifests, and correspondingly has none of the operational weight that comes with them.

Semantic-release drives the version tags

Versioning is automated. The package.json file carries the semantic-release toolchain, including the commit analyser, the git plugin, the GitHub and npm plugins and the release notes generator, and a .releaserc.json file sits at the root as its configuration. The version string in package.json matches the current release tag, 4.26.0.

Recent tags land regularly: v4.26.0 on 2026-10-14, v4.25.1 on 2026-10-05 and v4.25.0 on the same day. The last push was on 2026-10-19, two days after the newest tag, and the repository is not archived. The module path itself carries the major version, xeiaso.net/v4, so the v4 line is the current one and a v5 would be a new module path rather than a breaking tag on the same import path.

That cadence is exactly why the README warns against reuse. A repository that publishes several releases a month under automated versioning is a moving target, and the author is explicit that the project is only open source because NixOS deployment was easier with it in the open. The CHANGELOG.md file is not in the top level listing either, so the tag history is the release record.

Editorial conclusion

Read Xe/site as a reference implementation if you want to see a single-person site wired end to end, from buf generate through kubectl apply, but do not fork it as a starting point, because the licence was chosen to make verbatim reuse difficult and the README states the content is all rights reserved. If you want a website rather than a case study, the README itself points you at Hugo or Zola, and that advice is worth taking.

Frequently asked questions

Official sources

1. Issues
2. License: Zlib
3. README
4. Releases
5. Xe/site on GitHub