Tracker is a lightweight document and work-tracking system designed around three goals:
1. *Totally self-hosted and 100% private*: I run it over ZeroTier to connect my systems, but Tailscale or just your personal LAN works great as well.
2. *Flexible, immediately usable, & extensible*: It can use S3/R2/etc for the actual document storage if you want object storage, or you can just use local files. I've been running RustFS myself on a small local k8s cluster which emulates S3. It comes with migration tools to switch from one storage system to another, and it is ready to run in many different forms all designed for AI agents to be pointed at it and immediately self-bootstrapped. "Look at the tracker tool at `<ip:port>` and configure your own mcp and skill using the instructions within" is all you need to tell an agent.
3. *Very lightweight, reasonably fast, and designed more for agents to use it well rather than humans*: That being said, it does have a minimal web UI included so you can also browse your documents.
Furthermore, it has a few design quirks which I really wanted—some people will probably love them and others might hate them. You have to remember that I have a... problem? with simply loving computers, so I tend to work from several different machines simultaneously, and that's a major motivating factor here.
- *Flat structure with tags & folios*: Tracker is only slightly opinionated on document storage hierarchy. You can store a massive collection of raw docs in a flat format, or you can use *folios*—which are just documents of `kind='folio'` whose metadata tracks its files (themselves documents tagged with `folio:<slug>`). There is no other way to introduce additional hierarchy; to me, this is a major benefit—I just wanted one big flat space.
- *Explicit locking on everything*: All changes go through an explicit locking mechanism, even simple metadata edits. This is to prevent an agent from reading a stale document before taking action.
- *Strict attribution*: All edits require an actor ID (sent via `X-Actor: <role>@<hostname>/<ip>`). Because I work across Linux, macOS, and Windows simultaneously, it's critical to know exactly which coding agent is doing what, from where, and on which machine.
Duckbill is hiring three-five engineers for 3 roles with hybrid work in downtown SF. We're in-office MWF and WFH Tuesday and Thursdays. Relocation is an option but sponsorship / remote is not.
We're working on Skyway, a new kind of enterprise-grade finops tool born out of the Duckbill Group's consulting business. We're staying small (team-wise) but focusing on the largest of the SaaS spenders and their problems exclusively. We ship daily and have several unfair advantages.
1. Senior Front-end Engineer (TS/JS/React + bit of Python back-end)
2. Senior Back-end Engineer (Python + bit of front-end)
3. Senior Data Engineer (Python, airflow, duckdb, s3, bigquery)
internal reports from current AWS engineers seem to be confirming all of the speculation in this article. Shit's rotten from the inside out and you can pretty evenly blame AI, brain drain, and good old fashioned "big company politics"
Duckbill engineering is hiring a full-time ONSITE senior data engineer in downtown San Francisco. We WFH Tuesdays and Thursdays.
We're tackling the hardest finops challenges for the biggest enterprise customers head-on and have a killer team along with the advantage of the established and industry-leading DuckBill Group.
Help shape the leading edge of an entire industry with us while we're still just at seed stage and under 6 engineers!
Comp range is generous on the equity and between 180k and 210k base depending on seniority. We're cooking with flask, react, postgres, clickhouse, parquet and airflow on AWS at the moment.
Duckbill engineering is hiring a full-time ONSITE full-stack senior SWE in downtown San Francisco. We WFH Tuesdays and Thursdays.
We're tackling the hardest finops challenges for the biggest enterprise customers head-on and have a killer team along with the advantage of the established and industry-leading DuckBill Group.
Help shape the leading edge of an entire industry with us while we're still just at seed stage and under 6 engineers!
Comp range is generous on the equity and between 180k and 200k base depending on seniority. We're cooking with flask, react, postgres, and clickhouse on AWS at the moment.
I'm surprised this take isn't gaining more ground in these discussions.
people keep talking about how "this is what all these Americans want" - bologna I say. They're just voting how they've been programmed to believe.
Find me a Trump supporter that has only researched him from first-hand credible sources and has not been influenced by friends, family, social media, or mainstream media. I would be very surprised if any person like this exists.
last time the checks and balances were more prepared to handle (block) him.
this time, they're primed to enable and embolden their plans (see project 2025).
I don't expect these four years to be anything like the last time. I legitimately won't be surprised if this is the last somewhat-normal presidential election in the united states
Assuming you're arguing in good faith, here is the transcript from someone who was in the room with Trump when he was saying all of this:
> He's looking for obedience. This is the thing that shocks him about American generals and continues to shock him, is that they swear an oath to the Constitution, not to the president. That's what he's looking for, personal loyalty. And we know that from many other discussions we have heard around him.
Agreed. I'm also a bit frustrated that he never tuned vertica in his test of it - he just loaded the data into the default superprojection and queried it like that. Nearly all of vertica's power comes from its concept of projections - just like normal DBs benefit from indexes. I'd really like to see how it performs to these other systems once it's been tuned properly because in my experience it's always been the fastest DB I've ever worked with.
Of course, the key to any successful implementation of end-to-end exactly-once processing lies in the fact that you USE the kstreams APIs - including all semantics around "consumption is completed up to offset X"
Absolutely, we used store-and-forward semantics when I used Kafka at a previous company to guarantee zero message loss (for data getting into kafka). Now that kafka streams provides exactly once semantics, you're in an even better spot to achieve this.
Genuine question - Why does everyone seem to think running a zookeeper cluster is so hard? You can run it on three small VMs and basically forget about it. We didn't have any zookeeper experience at my last startup before we started using it for Kafka and we used a very simple puppet module to install it on three instances in each of our AWS regions. It really never gave us many problems in the several years since.
Also, all the tooling around it is quite mature - there are great monitoring and management tools for probing at the internals which helped when we were dealing with more exotic kafka surgery.