Was working with litestream to make backup/restore for my sqlite db on litebin. Plan was to have multiple destinations for backup to land. As usual AI agent told everything works and realised new v0.5 doesn't support multiple destinations. I wanted a local backup then another external one r2/s3, but now litestream doesn't do that and I would need to run multiple instances, one for each destination, which in my lightweight thesis stack doesn't make sense. So I ended up making local as primary destination using litestream, and the moment r2/s3 is added as destination it switches to external. Now to have a local backup I run a daily snapshot from the external and keep it local. This helps in 2 things: 1. I can verify backup is working and I get a local copy to restore just in case. 2. One instance of litestream.
Photo by Alexander Sinn
whoami
codinglog
Field notes, experiments, and the occasional rant. A log of what I'm learning, breaking, and building — plus the random stuff that doesn't fit anywhere else.
tools
The web framework this site is built on. Content-first, zero JS by default.
Headless CMS driving the dashboard. Open API over a SQLite file.
One compose file, the whole stack runs anywhere.
Self-hosted deployment platform for side projects. Builds Docker images on your laptop, streams them directly to your VPS — no registry needed. Containers sleep to zero when idle and wake on incoming requests, so you can host unlimited apps on a single cheap VPS. Multi-node support with mTLS, auto-placement, and a clean web dashboard. Built in Rust, under 58MB.
Fast, disk-efficient package manager. Replaced npm for me.
latest_posts
--> alllatest_notes
--> allI was cleaning up a few pending unpublished projects. One fuel tracking app which I built exactly 1 year back, I pushed myself to publish it now. All fixes on it done, wired Expo, Supabase and RevenueCat. So this will go live next week. Will need to get prod deployment access to my Play Store account, and also will take a look at App Store if this gets some demand.
Got frustrated with a food delivery app today. A few items in the cart went out of stock during a payment retry, and the app didn't confirm the cart modification at all before taking the payment again.
Picking the Cloudflare stack for the new project. The traffic profile is all or nothing: if it takes off it can see millions of hits a day, and if it doesn't it gets none. Setting up for that on AWS or a VPS with Kubernetes means building the scalable deployment upfront, time spent before knowing if the project even works. Instead I'm going with Cloudflare Workers, R2 for images, and KV, starting on the $5/mo Workers plan. The frontend goes on Cloudflare Pages, so that's served through the Cloudflare CDN as well. Not saying $5 covers all the scale, just the start. After that it stays cheap for what it is, and more hits means more revenue, which is easy to pay. What I'd rather avoid is setting up something on a VPS that needs to be scalable upfront for a site this uncertain. No k8s to babysit either way.
$ leave_a_message
Spotted something interesting, or want to point me at a tool? Drop it here.