Show HN: SnackBase – Open-source, GxP-compliant back end for Python teams (snackbase.dev)
I built this because I work in Healthcare and Life Sciences domain and was tired of spending months building the same "compliant" infrastructure (Audit Logs, Row-Level Security, PII Masking, Auth) before writing any actual product code.
The Problem: Existing BaaS tools (Supabase, Appwrite) are amazing, but they are hard to validate for GxP (FDA regulations) and often force you into a JS/Go ecosystem. I wanted something native to the Python tools I already use.
The Solution: SnackBase is a self-hosted Python (FastAPI + SQLAlchemy) backend that includes:
Compliance Core: Immutable audit logs with blockchain-style hashing (prev_hash) for integrity.
Native Python Hooks: You can write business logic in pure Python (no webhooks or JS runtimes required).
Clean Architecture: Strict separation of layers. No business logic in the API routes.
The Stack:
Python 3.12 + FastAPI
SQLAlchemy 2.0 (Async)
React 19 (Admin UI)
Links:
Live Demo: https://demo.snackbase.dev
Repo: https://github.com/lalitgehani/snackbase
The demo resets every hour. I’d love feedback on the DSL implementation or the audit logging approach.
11 comments
[ 2.9 ms ] story [ 17.7 ms ] threadBookmarked to keep a tab on for future reference.
I noticed that SQLAlchemy (an ORM) is part of the stack, and that “Postgres support” is in the roadmap. For people coming from Supabase and the like which is Postgres-first, some upfront clarification around which database is already supported, would be helpful.
None of Django, Rails, Pocketbase or Supabase, which I think count as competitors, use AGPL.
Unless you can clarify that custom hooks and schemas are outside of the AGPL license, SnackBase may be a non-starter for commercial use.
> Compliance Core: Immutable audit logs with blockchain-style hashing (prev_hash) for integrity.
Had this in the back of my mind for a while now, too. In terms of prior art, Keybase had been doing something similar, but with Merkle trees.
> I’d love feedback on the DSL implementation
Could you tell in a bit more detail why you decided to go with your own DSL here? :)
I think every developer has a story about spending months on those exact features. Organizations, RBAC, Auth, etc. before they ever get to write a single line of code for the actual business problem they were trying to solve.
Since you are coming from plain Flask, you would likely find the SnackBase architecture very familiar. I chose FastAPI and Pydantic specifically to give that same "get out of my way" developer experience, but with the compliance-first features (like the immutable audit logs) baked into the core so you don't have to think about them.
If you ever have a chance to play with the demo or the repo, I’d love to know if there are any specific missing pieces from your Flask implementation that you think should be in SnackBase.
It’s unfortunate that so many of these projects just whither away, blasts of commits with hundreds of files but nothing changed in months.
For SnackBase, I actually spent the majority of my time on the architecture and compliance logic rather than just generating boilerplate.
Compliance Core> Getting the immutable hash-chain for audit logs to work correctly with async SQLAlchemy while ensuring it doesn't kill database performance is something I had to iterate on manually. AI is great at writing a function, but it's notoriously bad at keeping a consistent "Clean Architecture" across hundreds of files without a human steering the ship.
Custom DSL> I built the DSL specifically to solve the maintenance problem you mentioned. It acts as a single source of truth for the DB, API, and UI. This makes the project much easier to maintain long-term because you aren't manually updating three different layers every time a schema changes.
I built this because I actually need it for my work in Life sciences domain. My goal isn't a blast of commits but a rock-solid foundation that can survive a GxP audit.