rgthelen

Thanks for following along since day 1!

webhooks are the part where most agent-built auth falls apart. Here's how Corral handles it:

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.

Thanks! On auth providers — Corral already supports 9 OAuth providers out of the box (Google, GitHub, Apple, Discord, Microsoft, Twitter, Facebook, GitLab, LinkedIn) plus email/password, magic links, and email OTP. Adding a new one is one command:

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.

It 100% runs locally, is easy to deploy, and it wires it right into your app - even cooler, if you have a JS backend, no extra server, if you have python, go, ruby, etc, it will have your agent create a tiny side-car so you don't need an extra container, etc.

Let me know what you think!

The split model leaves too many holes to make it really useful for the community. When we add things like "authentication", we'll ship the plugins (like okta integration (for enterprises), etc. We will do our best to maintain all of the plugins (but if there are 30 different auth providers, we will have to rely on the community to maintain the smaller ones), but, enterprises will pay us to ENSURE everything is up to date, safe, etc.

The Support + Service model has been proven by large and small companies alike - it is one that will also survive the AI contraction coming.

Yeah, we are in it to win it.

Oh man, yeah, big pivot.

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 :)).

We are adding continuous model fine-tuning soon, and being able to bring extra horsepower into training is an opportunity. There is also a genuine opportunity to do the same thing with shared resources inside an internal server or VPC; timing and utilizing resources, such as GPUs, during off-hours to train, improve, etc., is a never-recovered opportunity that many enterprises leave on the table.

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).

Yeah, totally fair. The “horizontal orchestration” story only goes so far — at some point you need vertical depth.

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?

Yes! Vulcan support is in dev (will be in the next versioned release, probably tomorrow).

You can pull down the repo and run a few easy commands to get inference up and running.

https://docs.llamafarm.dev/docs/models#lemonade-runtime

Appreciate that — and totally agree. The “who cares / who pays” question is exactly why this hasn’t scaled before.

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

Funny you bring it up. We shipped Vulkan support TODAY through a tight integration Lemonade (https://lemonade-server.ai).

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.

https://docs.llamafarm.dev/docs/models#lemonade-runtime

Our business model is not to compete in open-source; we are just providing this to the community since its the right thing to do and as a signal to enterprises to reduce risk.

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.

I hear you and valid. A mixture of Models is probably a better phrase - we are constantly moving between AI experts and very skilled Developers who use OpenAI endpoints and call it AI, so we are constantly working on finding the correct language. This was a miss though - will do better :)

Let me know when you open source it; I think there is a place for this and I think we could integrate it as a plug in pretty easily into the LlamaFarm framework :)

Yeah, I don't see why we could not integrate that. I think that is the next step as we move our workloads to production.

This looks awesome. Are you kind of like lemonade? Let's chat - [email protected]

Cool ideas, thank you.

What are a few use-cases you want to see this used for?

The hardest part, honestly, is the runtime. How do we make it super easy actually to deploy this. We are still working on that. Where do you see a few good places to focus at first? I was thinking AWS and Google, since both have good GPU pricing models, but I am probably missing a few good ones!

Yeah, that’s a fair framing — it is kind of an “application layer” for AI orchestration, but focused on ownership and portability instead of just convenience.

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?

Good question — that’s actually the sweet spot for LlamaFarm.

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.

I am kind of militant about this. The ability to run great AI models locally is critical, not just for this sector, but for innovation overall. The bar of "build a few datacenters" is far too high for all but the largest countries and companies in the world.

Likewise, it's been fun building in the open on this one.

Great job on this. I'll be following.

I got it working locally on a Mac; but would love to hear where you want to deploy to next!

This is what AI is now - sprinkled on top without any actual value.

I used to work in aircraft maintenance on F-15s. We'd have entire toolboxes with cutouts, just like the example.

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.