I had a quick look at `pdf-bot`, and though we both rely on the same underlying technology (we are only just moving to headless Chromium; we were on Electron before), I believe we have slightly different ambitions with our respective project. But, I may be biased.
For example, `pdf-bot` seems to be tied exclusively to a specific converter, and storage backend. With `athenapdf` however, we are moving more, and more towards building a toolkit or rather, framework for other people to construct their own conversion processes (or even microservice)[0].
Consequently, we are working towards general abstractions like fetching, converting, and uploading, that can have different implementations (e.g. wkhtmltopdf, LibreOffice, Weasyprint, etc).
With our microservice assembly as well, we are focused heavily on ensuring we have:
1. Instrumentation, and metrics (which `pdf-bot` appears to currently lack)
2. Support for different retry mechanisms (e.g. retry using the same converter or retry using a different converter)
3. Support for multiple input MIME types
4. Synchronous API calls (`pdf-bot` appears to be mostly asynchronous, with batch processing, and callbacks)
5. Ease of installation (e.g. Docker), and configuration
We also have a CLI assembly[1] that can support custom JavaScript plugins[2] (e.g. Markdown -> PDF, Readability, etc). So you don't need to run a service or make API calls for conversions.
[0] https://github.com/arachnys/athenapdf/tree/v3/pkg
[1] https://github.com/arachnys/athenapdf/blob/v3/cmd/cli/main.g...
[2] https://github.com/arachnys/athenapdf/tree/v3/pkg/runner/plu...