# zKillboard updates its fitting data with a manual command guarded by tests

> zKillboard is a PHP killboard for EVE Online served from two container images, one for the site and one for cron. Its fitting data does not refresh on a schedule: a Node script downloads a new EVEShip.fit release, runs the fitting tests, and only then asks a human to commit two compressed files.

**zKillboard/zKillboard** — zKillboard.com is the premier killboard for EVE Online. Track players, corporations, and alliances, analyze battle reports, and monitor PvP anywhere in New Eden.

- Repository: https://github.com/zKillboard/zKillboard
- Website: https://zkillboard.com
- Stars: 315 · Forks: 82
- Language: HTML
- License: NOASSERTION
- Published: 2026-08-27 · Updated: 2026-08-27 · Language: en
- Canonical page: https://hysenlabs.com/projects/zkillboard-zkillboard

## The fitting data update is one command and a human commit

Nothing refreshes the fitting data on a timer. Updates are manual, run from the repository root with Node.js 24 installed.

```bash
node setup/updateFitData.mjs
```

The sequence inside that script is deliberate. It checks the latest public `@eveshipfit/sde` release, downloads the data that changed, and runs the fitting tests before replacing the data assets. A release argument lets you select a specific upstream release instead of the newest. If a download fails or the tests fail, the current assets are retained rather than replaced.

After a successful run, the work is still not deployed. You review and commit the changed `public/vendor/eveshipfit/data.json.gz` and `sde.dat.gz`, then push them to the web and static servers or rebuild the web image. So the gate is twofold: tests protect the data, and a person decides when the change ships. The metadata records both the package release and the SDE build, which is what lets a server say which upstream snapshot it is serving.

Setup guidance for this subsystem lives in a dedicated section of `Docker.md`, under EVEShip.fit Fit Stats.

## Every web server carries its own copy of the fitting assets

The EVEShip.fit engine, its bindings, the license notices, and the verified fitting-data assets are all included in the repository and in the Docker images. That is a deliberate answer to a topology problem: there is no central fitting service.

Each web and static server uses its own deployed copy. No cron job is required for Fit Stats, and no shared storage is involved. The consequence for operators is that updating the data means pushing files to every server, or rebuilding images and redeploying them, which is exactly the step the manual updater leaves to a person.

The design trades freshness for independence. A killboard instance cannot fail to serve fitting data because a shared store or a scheduled job failed, and a server does not need network access to a sibling to answer a fitting question. The cost is that instances drift unless the deploy step is treated as mandatory, since a server left behind will answer with old data and no visible error.

## Two Dockerfiles split the public site from the cron side

The repository carries two image definitions rather than one. `Dockerfile.www` builds the public site, and `Dockerfile.cron` builds the scheduled work. That separation is visible in the file list, where a top-level `cron/` directory sits beside the application directories, and it matches the note that fitting data needs no cron job while other work evidently does.

The application itself is PHP. `index.php` and `routes.php` sit at the repository root with `init.php`, a `classes/` directory for code, `templates/` with `pug.php` for view templates, `view/`, `information/`, and a `public/` directory that holds the vendored EVEShip.fit data. `composer.json` and `composer.lock` are present, so dependencies are resolved through Composer and pinned in a lock file rather than vendored by hand.

Around that sit `tests/`, `docs/`, `setup/` holding the update script, a `scratch/` directory, a directory named `mer/`, an `AGENTS.md`, and an `updateVersion.sh`. The default branch is `master` rather than `main`.

## The files say AGPL v3 while the repository index says NOASSERTION

The licensing position is documented in two places and indexed in a third, and they do not agree at a glance. The credits state that zKillboard is released under the GNU Affero General Public License version 3, with the full license in `AGPL.md`, and a separate section repeats that licensing for all files in the repository is in `AGPL.md`. Both `AGPL.md` and a `LICENSE.md` are present at the root.

Repository metadata, by contrast, reports the license as NOASSERTION, the marker used when a license cannot be detected automatically. For a PHP project with a composer manifest and no license field visible here, that is an indexing artifact rather than a different legal position, but it is the field most tools read.

Game assets are handled separately. zKillboard uses data and images from EVE Online, covered by a license from CCP, and that text is in `CCP.md` beside the AGPL text. Third-party libraries are called out as carrying their own terms, with their documentation as the reference. Anyone redistributing an instance needs to account for all three layers rather than the AGPL alone.

## The original domain was renamed after a forum banned a word

The site was originally called killwhore.com, and the reason for the change is recorded plainly: the name was abandoned once it was discovered that the EVE Online forums censored the word.

That detail explains the current branding, zKillboard.com, and it is the only part of the documentation that explains the name rather than the software. It is worth knowing when searching for older references, because archived material, forum posts, and third-party integrations may still use the previous domain.

The rest of the project's self-description is narrower. zKillboard is described as a killboard for EVE Online, tracking players, corporations, and alliances, analyzing battle reports, and monitoring PvP, with support handled through a Discord server where questions belong in the `#zkillboard-com` channel. There is no signup flow, no pricing page, and no account system described anywhere in the documentation, which is consistent with a public data site rather than a service.

## A fork is the reason this repository is the official home

The history section explains the project's shape, and the explanation is not a smooth growth story. zKillboard began as the brainchild of Squizz Caphinator, who wanted to improve on the Eve-Dev Killboard. Rather than keep modifying existing code, he started fresh and wrote a new killboard from scratch.

Karbowiak of eve-kill.net then joined, contributed a significant amount of code, created the GitHub repository, and announced zKillboard as the new beta killboard for eve-kill.net. The project matured and gained a user base, and creative differences between the two led Squizz to fork it and make this repository the official home of zKillboard.com.

The technical direction followed the data. In the following year Squizz began exploring NoSQL databases, which suited the scale and structure of killmail data better, and after two months of development and major database changes the repository was made public with full NoSQL support.

The public-access commitment came from a shutdown. With eve-kill.net and Battleclinic gone in the years leading up to 2015, Squizz committed to keeping all collected killmails publicly accessible, and various APIs plus killmail data dumps are offered for that reason, with details in the Wiki.

## Conclusion

zKillboard suits an EVE Online player or analyst who wants battle reports, killmail history, and fitting data in one place, with public APIs and data dumps rather than a closed dashboard. It does not suit someone looking for official EVE Online data, since the project is an independent site licensed separately from CCP, and it does not suit an operator who wants fitting data to refresh on its own, because that step is deliberately manual. Before deploying it, read Docker.md for the service layout, budget for running both the www and cron images, and confirm you can commit and redeploy two data assets when the upstream release changes.

## FAQ

### Is zKillboard an official EVE Online site?

It is an independent site, not an official one. zKillboard uses EVE Online data and images under a separate license from CCP, documented in `CCP.md`, and its history traces to a third-party killboard and to eve-kill.net rather than to the game publisher.

### Who created zKillboard?

Squizz Caphinator, who set out to improve on the Eve-Dev Killboard and wrote a new killboard from scratch rather than modify existing code. Karbowiak of eve-kill.net later joined, contributed code, and created the GitHub repository; creative differences then led Squizz to fork the project and make this repository the home of zKillboard.com.

### How is fitting data updated in zKillboard?

Manually, by running `node setup/updateFitData.mjs` from the repository root with Node.js 24. The updater checks the latest public `@eveshipfit/sde` release, downloads changed data, and runs the fitting tests before replacing assets, and a failed download or test keeps the current files. You then commit `data.json.gz` and `sde.dat.gz` and deploy.

### Where do I find zKillboard setup instructions and support?

`Docker.md` covers application and service setup, with a section on EVEShip.fit Fit Stats, and the repository carries separate `Dockerfile.www` and `Dockerfile.cron` images. For assistance, the project points to its Discord server and the `#zkillboard-com` channel.

### What data can I get out of zKillboard?

Various APIs and killmail data dumps are available, with details in the project Wiki. The stated reason is a commitment to keep all collected killmails publicly accessible after eve-kill.net and Battleclinic shut down in the years leading up to 2015.

### What license is zKillboard released under?

The GNU Affero General Public License version 3, with the full text in `AGPL.md`. Data and images from EVE Online fall under a separate CCP license documented in `CCP.md`, and third-party libraries carry their own terms.

## Sources

- [Official documentation](https://zkillboard.com)
- [Official README](https://github.com/zKillboard/zKillboard#readme)
- [Project repository](https://github.com/zKillboard/zKillboard)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zkillboard-zkillboard