49 karma · joined December 14, 2020
The server-express.ts template generates the webhook route with the raw body parser before express.json() (Stripe requires the raw body for signature verification — agents almost always get this wrong). The route handles checkout.session.completed, customer.subscription.updated, and customer.subscription.deleted events and auto-updates the user's plan in your database.
So when your agent runs corral init, the webhook endpoint is already in your server at /api/corral/webhook, with Stripe signature verification wired in. Your agent just needs to:
corral stripe sync — creates the products/prices in Stripe Set STRIPE_WEBHOOK_SECRET in .env For local dev: stripe listen --forward-to localhost:3000/api/corral/webhook That's it. The agent doesn't have to figure out raw body parsing, event routing, or idempotency — the template handles all of it. And since corral doctor checks for the webhook secret in your env, the agent gets told if it's missing.
The worst Stripe webhook bugs I found during testing were (1) express.json() parsing the body before the webhook route sees it, and (2) agents putting the webhook route after auth middleware that rejects unsigned requests. Both are baked into the template ordering now.
corral add provider github Under the hood, Corral is built on Better Auth, which has a plugin architecture. Any Better Auth plugin works with Corral — so if someone builds a provider plugin for Better Auth, it automatically works here too. We're not reinventing auth crypto, just making it agent-installable.
On the crypto payments front — that's actually a great use case for Corral's plugin model. The billing layer is modular (Stripe today, but the gating/metering layer doesn't care where the payment event comes from). A BTC/USDC payment plugin that fires the same "user upgraded to plan X" event would slot right in. Interesting idea.
Let me know what you think!
The Support + Service model has been proven by large and small companies alike - it is one that will also survive the AI contraction coming.
We still are Rownd (https://rownd.com); but we see the writing on the wall. SaaS Software that helps with "hard code" problems is going the way of the dodo.
What used to take a few weeks and was hard to maintain can be down with Codex in the background. We are still bringing in decent revenue and have no plans to sunset, we are just not investing in it.
We all have IBM backgrounds - not sexy, but we are good at running complex software in customer datacenters and in their clouds. AI is going to have to run locally to extract full value from regulated industries.
We are using a services + support model, likely going vertical (legal, healthcare, and we had some good momentum in the US Gov until 1 October :)).
Any GPU that is not being used at 80% capacity needs to be put to work; we have a lot of work that can be done. (A lot of industries cannot lease their GPUs to the public due to regulatory issues).
We’re starting with regulated enterprises (defense, healthcare, legal, fintech) where control and compliance actually matter. The same YAML-defined system can run in AWS, in a hospital, or fully air-gapped — no lock-in, no data leaving.
We’re building a few sample recipes to show it in action:
Legal: doc analysis + precedent search with local vector DBs
Healthcare: privacy-preserving RAG over clinical notes
Industrial/Defense: offline sensor or alert agents that sync later
Partnering with MSPs and modernization firms seems like the obvious path — they already have the relationships and budgets, and LlamaFarm gives them something repeatable to deploy.
Still figuring that out though — what’s the best way to actually get into the MSP funnel?
You can pull down the repo and run a few easy commands to get inference up and running.
Our bet is that the timing’s finally right: local inference, smaller and more powerful open models (Qwen, Granite, Deepseek), and enterprise appetite for control have all converged. We’re working with large enterprises (especially in regulated industries) where innovation teams need to build and run AI systems internally, across mixed or disconnected environments.
That’s the wedge — not another SaaS, but a reproducible, ownable AI layer that can actually move between cloud, edge, and air-gapped. Just reach out, no intro needed - robert @ llamafarm.dev
We now support AMD, Intel, CPU, and Cuda/Nvidia.
Hit me up if you want a walk through - this is in dev right now (you have to pull down the repo to run it), but we'll ship it as a part of our next release.
Our goal is to target large enterprises with services and support, leveraging deep channel partnerships. We do ship agents as a part of the project and it will be a critical part of the services model in the future.
Yeah, the beachead will be our biggest issue - where to find first hard-core users. I was thinking legal (they have a need for AI, but data cannot leave their servers), healthcare (same as legal, but more regualtions), and government (not right now, but normally have deep pockets).
What do you think is a good starting place?
You can wire things together yourself (LangChain, bash, Ollama, etc.), but LlamaFarm tries to make that repeatable and portable. It’s declarative orchestration for AI systems — you describe what you want (models, RAG, agents, vector DBs) in YAML, and it runs the same way anywhere: laptop, cloud, or fully air-gapped edge.
So instead of gluing frameworks and breaking them every update, you can do something like:
name: home_guarde runtimes: - detect_motion: {model: "phi-3", provider: "lemonade"} - alert: {model: "gpt-5", fallback: "llama3:8b"} rag: embedder: "nomic-embed-text" database: chromaDB
…and it just runs — same config, same behavior, whether you’re doing local RAG or home monitoring. The goal isn’t to replace the DIY route, just to make it composable and reproducible.
Then do LF init to get the project started!
I still use a "physical" checklist as I get ready in the morning - my wallet, keys, ear buds, and keys all have their physical spot over night and in my pocket.