Forem: Chris King

I Love Detailed Releases. I Hate Doing Them.

Chris King — Mon, 06 Apr 2026 07:00:00 +0000

So I Made an AI Do It For Me.

You know what's fun? Shipping code.

You know what's not fun? The 47-step release ceremony afterwards where you squint at a diff, pretend you remember what you changed three days ago, write release notes that say "misc fixes," bump a version number wrong, forget to build, upload the wrong artifact, and then lie to your team about it in Slack.

I got tired of it. So I built Rel-Ease — a terminal release manager powered by Backboard.io that reads your diff, proposes a SemVer bump, writes real release notes, and handles the build-and-publish dance. Python, Rust, Node — it detects your repo and adapts.

The trick: the AI drives the thinking, but every mutation runs through explicit CLI tools on your machine. It doesn't hallucinate that it published to PyPI. It actually publishes to PyPI. Revolutionary concept, I know.

The workflow is obscenely simple

pip install release-cli
export BACKBOARD_API_KEY=sk-...
rel-ease release .

That's it. It diffs, it thinks, it bumps, it notes, it commits, it builds, it ships. You approve or you don't.

Want a dry run? --dry-run. Want to steer it? --hint "minor bump, new API". Want to make sure your environment isn't cooked? rel-ease doctor .

Why this exists

Because I wanted release notes I could actually email to a human without shame. Because "bump version" shouldn't require 15 minutes of my finite life on this earth. Because every manual release is an invitation to be lazy, and I am absolutely going to accept that invitation every single time.

Rel-Ease is me outsourcing the discipline I refuse to have.

It's open source

Because suffering alone is stupid.

GitHub: chrisk60331/Rel-Ease
PyPI: release-cli

Go use it. Go break it. Go make your releases embarrassingly detailed for once.

I Open Sourced My AWS Fork of Uptime Kuma

Chris King — Fri, 03 Apr 2026 12:05:00 +0000

I Got Tired of Paying Hundreds for a Status Page, So I Open Sourced My AWS Fork of Uptime Kuma

There’s a point where “hosted convenience” stops being convenience and starts being rent.

I hit that point with status page and uptime monitoring tools.

So I built and open sourced Uptime Kuma (AWS) — my AWS-focused fork of Uptime Kuma — to give myself a cleaner, cheaper, more ownable option.

GitHub repo: https://github.com/chrisk60331/uptime-kuma

The problem

A lot of uptime/status page products start cheap, look simple, and then quietly turn into another monthly bill you don’t want.

If all you need is:

uptime monitoring
alerting
clean status pages
solid control over your own deployment

…paying hundreds a month starts to feel ridiculous.

Especially when you already know how to run infrastructure.

What I built

Uptime Kuma (AWS) is an easy-to-use AWS-hosted monitoring tool based on Uptime Kuma.

It gives you a practical way to monitor services, trigger notifications, and publish status pages without handing yet another core operational function to a pricey vendor.

What it does

Core features include:

Monitoring for HTTP(s), TCP, keyword checks, JSON query checks, WebSocket, Ping, DNS records, push, Steam game servers, and Docker containers
Fast, reactive UI
Notifications via Telegram, Discord, Slack, Gotify, Pushover, Email (SMTP), plus 90+ notification services
20-second monitoring intervals
Multiple status pages
Domain mapping for status pages
Ping charts
Certificate info
Proxy support
2FA support
Multi-language support

Why I open sourced it

Because this is exactly the kind of software that should be easy to inspect, run, modify, and own.

Infra tooling gets better when builders can:

deploy it themselves
adapt it to their environment
avoid getting trapped in recurring SaaS spend
improve it in the open

Open source keeps the leverage where it belongs: with the operator.

Why it matters

This isn’t just about saving money.

It’s about control.

If uptime monitoring and status communication are important to your business, you probably shouldn’t treat them like a black box subscription you barely control.

You should be able to:

run it where you want
understand how it works
customize it when needed
keep your costs sane

That’s the point of this project.

Built in the same spirit as what I’m doing with Backboard.io

I’m building more tools in and around Backboard.io, and the pattern is simple:

Build useful things.
Solve real problems.
Open source what should be open.
Keep the stack practical.

This project fits that exactly.

Getting started

Run locally:

./start.sh

Deploy:

./build.sh

Repo again:
https://github.com/chrisk60331/uptime-kuma

Final word

If you’re paying too much for uptime monitoring or status page software, this may be the shove you need to just run your own.

No pitch deck.
No “contact sales.”
No nonsense.

Just a solid open source AWS-hosted option.

If you check it out, fork it, improve it, or deploy it, I’d love to see what you do with it.

I forked Cluely and pushed it further.

Chris King — Thu, 02 Apr 2026 12:41:00 +0000

I Open Sourced Caddy: An Invisible Desktop AI Assistant Built on Backboard.io

It’s called Caddy:
an invisible desktop AI assistant that lives on your machine, watches context, transcribes audio locally for speed, and lets you chat against what’s happening on your screen.

GitHub:
https://github.com/chrisk60331/caddy

What it is

Caddy is a desktop overlay built on Backboard.io.

It can:

capture screenshots
run OCR on what’s on screen
transcribe live audio locally
send context into Backboard
let you chat with that context using 17,000+ models
keep the thread alive with persistent memory

So instead of copy-pasting between tabs like an animal, you just ask questions in context.

Why I built it

A lot of “desktop AI” tools still feel slow, fake, or weirdly disconnected from the actual workflow.

I wanted something that felt:

fast
local where it matters
model-flexible
memory-native
actually useful while you work

So I forked Cluely, added local transcription, wired it into Backboard’s memory, and made it easy to use as a real-time desktop assistant.

That changed the feel of the product immediately.

Less lag.
More context.
Way better experience.

Why local transcription matters

If audio has to take a field trip before becoming usable context, the experience dies.

Caddy uses local transcription so it stays quick and responsive.

That means better support for:

meetings
calls
live research
screen-based workflows
follow-up questions while context is still fresh

Fast input makes the assistant actually feel intelligent.

Why Backboard.io

Backboard gives this thing real leverage.

Caddy uses Backboard for:

LLM routing
memory
contextual chat
access to 17,000+ models

That means you’re not trapped in one provider or one brittle workflow.

You get a desktop-native interface on top of a massive model layer with memory baked in.

That combo is nasty.

Stack

A quick look under the hood:

Electron for the invisible desktop overlay
React frontend
Flask backend
Local Whisper for transcription
Tesseract OCR
Backboard SDK for LLMs + memory

Core features

Invisible overlay — translucent, always-on-top, low-friction
Screenshot analysis — capture anything on screen and get answers fast
Audio intelligence — live transcription and analysis
Contextual chat — ask follow-ups with memory intact
Model selector — switch across providers via Backboard
Screen watch — periodic OCR + analysis of what’s on screen
Cross-platform — macOS, Windows, Linux

Who it’s for

Caddy is for people who live on their computers and want AI that works in the flow of actual work:

developers
researchers
operators
founders
power users
anyone tired of tab-hopping into prompt boxes all day

Why I open sourced it

Because desktop AI is still early, and a lot of the interesting stuff should be inspectable, hackable, and remixable.

Also because open source is still the cleanest way to pressure the market.

If someone wants to build on this, improve it, fork it, or weaponize the idea in a better direction — good.

That’s the point.

Try it

Repo:
https://github.com/chrisk60331/caddy

If you’re building with Backboard.io, or just want a fast open source desktop AI assistant with local transcription and memory, give it a spin.

If you improve it, I’d love to see where you take it.

I Open-Sourced Nash

Chris King — Wed, 01 Apr 2026 12:04:00 +0000

17,000 Models, Ridiculous Memory, and a Cleaner Way to Build AI Apps

Most AI apps have one move.

A chat box.

A model picker.

A little retrieval.

Maybe a tool call if you’re lucky.

That’s not enough.

So I open-sourced Nash — an AI assistant app built on Backboard.io with 17,000 models, Stripe subscriptions + overages, and what I’d argue is the smartest memory system in the game.

Not a toy.

Not a wrapper.

A real foundation for building serious AI products.

The problem

A lot of AI app demos look good for five minutes.

Then the cracks show:

memory is shallow
model support is narrow
billing is bolted on
orchestration gets messy
the product feels like a prototype wearing a blazer

The result: lots of flash, not much flow.

If you want to build something users actually come back to, the app needs more than a prompt box. It needs context, continuity, flexibility, and a business model that doesn’t collapse the second people start using it.

What Nash does

Nash is an open-source AI assistant app that gives builders a serious starting point.

It includes:

access to 17,000 models
subscription billing with Stripe
usage overages
deep memory
tool-friendly AI app architecture
a polished product foundation built on Backboard.io

The focus is simple: give developers a system that sees the floor well, moves fast, and makes the whole offense better.

Why I open sourced it

Because too many AI starter apps are either:

too shallow to matter
too rigid to extend
too demo-first to ship
too disconnected from real product needs

I wanted to release something more complete — an OSS app that shows how to build an AI product with actual range:

flexible model access
persistent user context
monetization
product-ready UX
architecture that can support real usage

Something that doesn’t dribble the air out of the ball every time you try to add a feature.

Why the memory matters

The biggest gap in most AI apps isn’t raw model quality.

It’s continuity.

People don’t just want an answer. They want software that remembers what matters, adapts over time, and gets better with use. That’s where Nash is strongest.

A good assistant shouldn’t reset every possession. It should carry context forward, make better decisions, and keep the interaction smooth.

That’s the difference between a neat demo and a product people actually trust.

Built on Backboard.io

Nash is one of three apps I’m open-sourcing, all built on Backboard.io.

The point isn’t just to release code.

It’s to show what a stronger foundation for AI apps can look like when you combine orchestration, memory, billing, and product design in one system.

Repo

If you want to fork it, study it, or build on top of it:

GitHub: https://github.com/Backboard-io/Nash

If you’re building AI apps and you’re tired of the usual iso-heavy demo stack, Nash might be a better starting lineup.

I Open-Sourced CloserNotes

Chris King — Tue, 31 Mar 2026 12:03:00 +0000

I Open-Sourced CloserNotes: ABC — Always Be Closing, Never Be Typing

Coffee is for closers.

And CRMs?

Too many of them feel like punishment.

So I built and open-sourced CloserNotes — a voice-first CRM for people who live in conversations, not forms.

Built on Backboard.io, CloserNotes uses local Whisper + Twilio to turn calls, notes, and follow-ups into something actually usable, without making you spend half your life updating fields like a data entry intern.

The problem

Every sales tool says it helps you sell.

Then it makes your reps do this:

log the call
write the summary
update the contact
add the follow-up
remember what mattered
pretend this is a good use of human life

It’s nonsense.

The best salespeople want to talk, listen, move, close.

Not babysit a CRM.

What CloserNotes does

CloserNotes is built for a simpler flow:

You talk.

It captures.

It organizes.

You move.

It combines:

local Whisper transcription
Twilio-powered calling
voice-first notes
clean CRM workflows
AI-assisted conversation capture

The idea is simple: reduce friction between the conversation and the system of record.

Less typing.

More selling.

Why I open sourced it

Because most “AI CRM” products are either:

hand-wavy
closed off
overdesigned
stuffed with features nobody asked for
missing the one thing that matters: speed

I wanted a real OSS example of a voice-first CRM workflow that feels sharp, simple, and extensible.

Not “enterprise theater.”

An actual build.

Who it’s for

CloserNotes is for:

sales teams
founders doing outbound
operators handling calls
anyone who wants CRM updates to happen with less pain

If your workflow starts with conversations, your software shouldn’t act like the keyboard is the product.

Built on Backboard.io

CloserNotes is one of three apps I’m open-sourcing, all built on Backboard.io.

The point is to show what happens when you build practical, AI-native apps around real workflows instead of toy demos.

Repo

Take a look, fork it, improve it, ship it:

GitHub: https://github.com/Backboard-io/closernotes

A lead comes in.

You call.

You talk.

The system keeps up.

That’s the pitch.

I Open-Sourced TopicMiner

Chris King — Mon, 30 Mar 2026 07:00:00 +0000

I Open-Sourced TopicMiner

Turn One Long Video Into Dozens of Branded Shorts

Most video repurposing tools are either too shallow, too closed, or too annoying to customize.

So I open-sourced TopicMiner.

TopicMiner is built for a simple but painful workflow: you have a podcast, webinar, interview, or long-form video, and you want to turn it into short, branded, vertical clips without manually chopping everything up for hours.

It handles:

local transcription
VTT caption generation
agentic video editing
branded short-form clip creation
Stripe payments

It’s built on Backboard.io, which means it’s not just a one-off toy project — it’s part of a bigger architecture for building serious AI-native apps.

What TopicMiner does

TopicMiner helps turn long-form content into short-form assets that are actually usable for distribution.

Think:

podcast to TikTok clips
webinar to YouTube Shorts
interview to branded social snippets
long videos to multiple cutdowns with captions

The goal wasn’t “AI for the sake of AI.”

The goal was to make content repurposing feel less like punishment.

Why I open sourced it

Because a lot of people want to build AI video workflows, but most examples out there are:

thin wrappers
black boxes
impossible to self-host
hard to extend
not wired for real product flows like billing

I wanted to put out something more real.

TopicMiner shows how to build an actual app around AI workflows — not just a demo, but a product-shaped system with media processing, transcription, editing logic, and payments.

What’s under the hood

At a high level, TopicMiner includes:

local-first transcription workflows
caption generation with VTT
agent-driven editing flow
branding-oriented short clip pipeline
Stripe integration for payments

If you’re building in the intersection of:

AI agents
creator tools
media workflows
transcription pipelines
OSS SaaS

…this repo should be useful.

Why this matters

Short-form distribution is one of the biggest leverage points in content right now.

But the workflow is still painfully manual.

A lot of creators and teams are sitting on hours of valuable long-form content that never gets repackaged because the process is too slow. TopicMiner is my take on closing that gap with an open-source stack you can actually inspect and build on.

Built on Backboard.io

TopicMiner is one example of what that stack can support: AI-assisted workflows, product logic, and real app infrastructure in the same system.

Repo

If you want to check it out, fork it, or break it:

GitHub: https://github.com/Backboard-io/TopicMiner

Meet Onni!

Chris King — Fri, 27 Mar 2026 07:00:00 +0000

I turned my open source AI marketing agent into a real product: meet Onni at cmo.dog

A little while ago, I built OpenOkara, an open source AI marketing agent that takes a URL and generates a marketing brief.

That project became the foundation for something more polished and deployed:

https://www.cmo.dog

The face of it is Onni — a good Finnish dog who fetches your Chief Marketing Officer.

And yes, that sentence is ridiculous.

But the product is real.

You drop in a URL, and Onni returns:

a website audit
a competitor map
a brand voice profile
a ranked SEO fix queue
and an AI chat interface for follow-up questions

All in about a minute.

Built on OpenOkara, but meant to be a product

OpenOkara was the open source starting point:

multi-agent orchestration
website analysis
competitor research
brand voice extraction
SEO recommendations
live streaming progress in the UI

That gave me the core workflow.

CMO.dog is the more productized version of that idea:

better branding
clearer UX
a stronger character layer
a tighter user journey
and a domain nobody forgets

That distinction matters.

A lot of projects work as demos but not as products.

The gap is usually not the model.

It’s:

framing
trust
flow
clarity
and whether normal people instantly understand what they’re supposed to do

Why I made Onni

Because “AI marketing” as a category is full of tools that are either:

too expensive
too vague
too generic
or too magical in a bad way

You upload something, wait, and get a glossy blob of text that sounds strategic but doesn’t actually help you decide what to do next.

I wanted the opposite.

I wanted something that feels direct:

put in URL

get marketing answers

No prompt gymnastics.

No huge onboarding flow.

No pretending a founder wants to become a part-time prompt engineer.

What Onni actually does

When you enter a site, four agents run in parallel.

1. Content agent

Reads the site and summarizes the company, offer, and available context.

2. Competitor agent

Searches the web for comparable companies, adjacent players, pricing signals, and positioning patterns.

3. Brand agent

Figures out how the company sounds — tone, voice, style, and positioning cues.

4. Audit agent

Builds the website audit, scores the site, and ranks the SEO fixes by priority.

That gets assembled into a single brief the user can actually act on.

Then the chat interface lets them keep going:

“Which issue should I fix first?”
“How do we position against competitor X?”
“Rewrite our homepage headline in our brand voice”
“What should we test next?”

That follow-up loop is where a lot of the product value shows up.

Why the dog matters more than you think

Onni started as a branding decision.

But I think mascots do something useful for AI products.

A lot of AI apps feel interchangeable:

same layout
same promises
same abstract gradients
same “copilot/cofounder/genius assistant” energy

Giving the product a character made it easier to define the tone.

Onni is helpful, fast, and a little playful — but the output still needs to be sharp.

That’s a better UX constraint than “make it futuristic.”

Also, cmo.dog is objectively funny, which I consider a strategic advantage.

The architecture is boring on purpose

The stack is straightforward:

FastAPI
Next.js 15
Pydantic
Tailwind
shadcn/ui
Backboard for agent infrastructure
SSE for live terminal streaming

The agents are orchestrated through a backend pipeline, and the frontend streams progress in real time.

I like the live terminal because it replaces the worst UI element in AI products: the dead-eyed loading spinner.

If the system is doing work, let users see it doing work.

That single choice makes the app feel more trustworthy.

A product lesson I keep relearning

Open source gets you attention from builders.

A product has to work for everyone else.

That means the hard part isn’t just getting useful output from agents.

The hard part is packaging the experience so a user instantly understands:

what this does
why it matters
whether they trust it
and what they should do after the result appears

That’s the part I wanted to explore with CMO.dog.

Not just “can I make the workflow work?”

But:

can I make the workflow feel like a product people want to use?

Why I think this category is vulnerable

A lot of premium AI SaaS products are charging serious money for workflows that are becoming easier to reproduce.

Not trivial.
But reproducible.

Especially when the product is fundamentally:

URL in
analysis happens
report out
follow-up chat

If your moat is just “we arranged the prompts nicely,” you should be nervous.

The defensible stuff is elsewhere:

distribution
trust
UX
speed
reliability
workflow depth
integrations
historical data
and product taste

That’s another reason I like building both open source and productized versions of ideas.

It reveals what’s actually valuable.

If you want to look at the code

The deployed product is here:

https://www.cmo.dog

The repo is here:

https://github.com/Backboard-io/cmo.dog

And the open source foundation it grew out of is here:

https://github.com/Backboard-io/openokara

Final thought

Sometimes the interesting part of a project isn’t the first build.

It’s the second one.

The version where you take the raw capability, add character, tighten the UX, sharpen the promise, and turn it into something people can immediately understand.

That’s what Onni is.

A good Finnish dog built on top of an open source AI marketing agent — now fetching CMOs at:

https://www.cmo.dog

Backboard.io continues to astound me! What a journey! Memory tiers, Customizable Memory Orchestration? Like it works great out of the box but now its suuuuper configurable!

Chris King — Thu, 26 Mar 2026 19:01:32 +0000

Jonathan Murray

Mar 26

We Just Shipped What OpenAI, Google, and Anthropic Have Not. Here Are 6 Updates.

#ai #programming #devops #tooling

Comments

5 min read

OpenOkara

Chris King — Thu, 26 Mar 2026 07:00:00 +0000

Opensourcing AI CMO, Built on Backboard.io

I built an open source AI CMO that audits your site, maps competitors, and finds your brand voice in 60 seconds

Hiring a CMO is expensive.

Hiring a good one is really expensive.

And if all you need is:

a site audit
competitor intel
brand voice extraction
SEO fixes
and a way to ask follow-up questions

…you probably don’t need a $200k/year exec and a 3-month ramp.

So I built OpenOkara: an open source AI CMO that turns a URL into a marketing brief in about a minute.

Drop in a website. It spins up multiple AI agents in parallel and gives you:

Website audit

Performance, SEO, accessibility, and best-practice checks
Competitor analysis

Direct and adjacent competitors, positioning, and pricing signals
Brand voice profile

A usable summary of how your company actually sounds
SEO fix queue

Ranked issues with step-by-step remediation guidance
AI chat

Ask follow-up questions without starting over

No prompt engineering. No mystery workflow. Just a URL.

Why I built it

A lot of “AI for marketing” products are just:

expensive wrappers
vague outputs
pretty dashboards hiding weak execution
and black-box workflows you can’t inspect or customize

I wanted the opposite:

open source
fast
inspectable
hackable
and actually useful

So OpenOkara shows its work while it runs.

Instead of a spinner, you see a live terminal stream as agents:

summarize the site
search for competitors
infer brand voice
run the audit
and assemble the final brief

That visibility matters. It makes the system feel less like magic and more like software.

How it works

The app uses a simple orchestrator pipeline:

Content agent → reads the website and summarizes content
Competitor agent → searches the web for rivals and pricing context
Brand agent → extracts voice, tone, and positioning cues
Audit agent → scores the site and generates prioritized fixes

Backend is FastAPI, frontend is Next.js, and the agents run on Backboard.

Stack

Python 3.11+
FastAPI
Next.js 15
Pydantic v2
Tailwind CSS
Backboard.io
SSE streaming for live run output

What I like most about it

The best part is that it’s not trying to be “AI magic.”

It’s trying to be useful.

You type in a URL and get something a founder, marketer, or agency can actually use today:

what’s broken
who you’re up against
how your brand sounds
what to fix first

That’s a lot more valuable than a chatbot saying “your website should be more engaging.”

Open source because the category needs pressure

There are already paid tools aiming at this space.

Some are good.

Some are wildly overpriced.

And honestly, this category needs a little open source pressure.

If a product is charging serious money for “paste URL, get marketing insights,” then the output needs to be really good, the workflow needs to be really polished, and the time savings need to be obvious.

Otherwise, OSS is coming for that margin.

Repo

If you want to try it, fork it, or improve it:

GitHub: https://github.com/Backboard-io/openokara

If you build on top of it, I’d love to see what you make.

Final thought

Open source isn’t just catching up on developer tools anymore.

It’s starting to put real pressure on expensive AI SaaS in categories that used to feel safely premium.

This is one of those categories.

And that makes it fun.

Open Sourcing TrustOS

Chris King — Wed, 25 Mar 2026 07:00:00 +0000

Your One Stop Shop for Compliance: SOC2 and HIPAA, Built on Backboard.io

We Got Tired of Paying for Compliance Theater, So We Built Our Own

Security compliance is supposed to make your company more trustworthy.

Too often, it turns into:

screenshot farming
spreadsheet archaeology
chasing policy acknowledgements
manually proving the same control 14 different ways
paying a premium for a dashboard sitting on top of APIs you already own

So we decided to stop renting the illusion and build the system we actually wanted.

What we built

We built TrustOS — a compliance partner and trust center for continuous audit readiness.

Instead of treating compliance like a once-a-year panic attack, TrustOS makes it operational:

automated evidence collection
continuous control monitoring
audit-ready evidence snapshots
policy and training workflows
vendor and BAA tracking
access reviews
auditor workspaces
customer trust sharing

It supports SOC 2 readiness today and extends cleanly into HIPAA Security Rule readiness.

The architecture

We didn’t reinvent everything.

We stitched together solid OSS building blocks and built the workflow layer ourselves:

OSCAL for canonical control modeling
Compliance Masonry for control mappings
CloudQuery for asset/config ingestion
Steampipe for fast compliance queries
Prowler for AWS posture checks
OPA/Rego for custom control evaluation
Checkov for IaC scanning
Trivy for vuln/config evidence
Temporal for recurring workflow orchestration
Postgres + S3 for metadata and evidence storage

The real value wasn’t in scanning cloud configs.
The real value was building the missing system around it:

evidence graph
point-in-time audit history
remediation workflows
policy acknowledgement tracking
vendor workflows
auditor-facing exports
trust center operations

Why we built it

Because most teams don’t need more compliance theater.
They need:

fewer manual tasks
better evidence provenance
less duplicated work
cleaner audit prep
a faster way to answer customer security reviews

We wanted something that felt like an engineering system, not a bloated admin tax.

What surprised us

The hardest part was not pulling data from APIs.

The hardest part was making compliance outputs:

defensible
repeatable
understandable
useful to humans who aren’t security engineers

The scanners are the easy part.
The workflow and audit trail are the product.

How to get started

Getting started with TrustOS is simple:

Clone the repo git clone https://github.com/Backboard-io/TrustOS.git copy .env.example to .env and fill in your backboard API key (see my other post about how frictionless it is to sign up for backboard.io)
Start the app

./start.sh
Open TrustOS

Navigate to http://localhost:8000

Or deploy the container/image anywhere you want.
Create your project

Set up a new compliance project and select the control frameworks you want to manage.
Upload your evidence

Load policies, reports, screenshots, training records, vendor documents, and other audit artifacts into the platform.
Create an auditor workspace

Generate a dedicated workspace for your auditor so they can review controls, evidence, and audit-ready materials in one place.

Takeaway

A lot of modern compliance software is really just:
connectors + rules + evidence storage + workflow glue

That doesn’t mean it’s trivial.
It does mean you might not need to keep paying forever for something your own stack can increasingly handle.

Sometimes the best way to cut compliance cost is to stop buying compliance theater and start building compliance infrastructure.

I Built a Hosted SQLite SaaS That's Free to Use 🚀

Chris King — Tue, 24 Mar 2026 07:00:00 +0000

Now Open to Free Signups

SQLite is magical. S3 is cheap. I combined them.

LiteLoft is a hosted database service built on
distributed-sqlite
— SQLite backed by S3, with a full provisioning layer,
auth, and monetization baked in.

Why this exists

I was already running SQLite on S3 with Litestream for a
production app. Then I built distributed-sqlite — a
SQLAlchemy dialect that treats S3 as the storage layer
with concurrent write support.

The next logical step? Host it.

How it works

Your DB lives in S3 as SQLite files + manifests
We issue short-lived STS credentials scoped to your tenant prefix — zero standing IAM access, ever
Connect with one line of Python via our client SDK

with connect(api_key=API_KEY, api_base_url=BASE) as engine:
    with engine.begin() as conn:
        conn.execute(
            text("CREATE TABLE IF NOT EXISTS hello (id INTEGER PRIMARY KEY, msg TEXT)")
        )

The Stack

distributed-sqlite — S3-backed SQLAlchemy dialect
AWS STS AssumeRole — per-tenant isolated creds
App Runner — lightweight provisioning layer
S3 — the actual database storage

Two Ways to Use It

☁️ Use Our Cloud (Free Tier Available)

👉 liteloft.dev

🛠️ BYO Bucket — Self Host in Your AWS Account

One-click CloudFormation deploy. Your data never
leaves your account.

Install

Server (self-host):

pip install db-host-api

👉 pypi.org/project/db-host-api

Client:

pip install db-host-client

👉 pypi.org/project/db-host-client

Open Source

MIT licensed. Contributions welcome.

👉 github.com/chrisk60331/distributed-sqlite-host

🆓 Free signups open now. No credit card. No infra.
Just a DB that lives in the cloud and costs almost
nothing to run.

Drop a comment if you have questions or want to
collaborate. Building in public — follow along. 🔷

opensource #sqlite #aws #database #python #buildinpublic

webdev #cloudcomputing

Why I Built a Distributed SQLite on S3 (And Why You Might Care)

Chris King — Mon, 23 Mar 2026 07:00:00 +0000

If you've ever deployed on AWS Lambda or App Runner, you know the pain:

You need backend storage, but RDS is overkill.

RDS is great. It's also $30–$100/month minimum before you write a single query. For small apps, side projects, or cost-sensitive workloads, that's a hard pill to swallow.

So you look at the alternatives.

The obvious candidates

DynamoDB? Great, until your access patterns don't fit and you're fighting it constantly.

SQLite? Perfect size. Except Lambda and App Runner are ephemeral. No persistent local disk. Dead on arrival.

Mount S3 directly? Tools like Mountpoint-S3 exist, but SQLite on a mounted S3 bucket only supports a single writer. The moment you have more than one container, you're in trouble.

So what do you do?

What I built

I wanted SQLite. I wanted S3. I wanted multiple App Runner instances or Lambda functions to be able to write concurrently without corrupting each other.

So I built distributed-sqlite: a Python library that lets multiple ephemeral compute instances read and write a SQLite database stored on S3, with conflict detection and automatic retry for safe concurrent writes.

How it works

The core idea is optimistic concurrency over S3 object versioning:

each writer reads the current database state from S3
writes are attempted locally
before committing back to S3, the writer checks whether the state changed underneath it
if it did, the conflict is detected and handled

For INSERT-only overlaps — the most common case in typical web app workloads — instead of raising a ConflictError, the writer:

rebases on the latest state
retries the transaction

Both workers converge to identical final state. No data loss. No conflict errors surfaced to your app.

I tested it

Two frontend web servers. Concurrent writes. Both converged to identical state every time.

That was the moment it stopped feeling like a hack and started feeling like a real primitive.

The honest tradeoffs

This is not a Postgres replacement. Let's be clear about what it is and isn't:

It is:

great for append-heavy workloads
great for low-to-medium write frequency
great for Lambda/App Runner/any ephemeral compute
operationally near-zero — just S3
cheap. Like, really cheap.

It is not:

globally serializable distributed SQL
safe for arbitrary concurrent UPDATE/DELETE without care
a replacement for RDS on high-write, complex-transaction workloads

Who this is for

If you're building:

a side project or indie app on Lambda/App Runner
an internal tool that doesn't justify RDS costs
an edge service with append-heavy writes
anything where "just use Postgres" is financially absurd

...this might be exactly what you need.

Install it

pip install distributed-sqlite

PyPI: https://pypi.org/project/distributed-sqlite/
Github: https://github.com/chrisk60331/distributed-sqllite