It was a blast joining Jason for this podcast - a great lineup of initial guests too! Check it out ⬇️
31.01.2026 01:01
👍 2
🔁 1
💬 0
📌 1
It was a blast joining Jason for this podcast - a great lineup of initial guests too! Check it out ⬇️
Hey Andrew! We’ll get that PR merged and released ASAP. I’ll take a look tomorrow.
For the other issue, where are you seeing that? If you have an account on Inngest cloud, dm me your account email and I’ll check out the function config and see what’s up
on Spotify there are video and audio options: open.spotify.com/show/1je9GKo...
Workflows made simple (& durable). 🤝🔗☁️
Inngest, a durable workflow orchestration platform, helps developers build scalable products, like AI workflows, agents, & e-commerce stores, without the complexity of managing infrastructure. ➡️ https://do.co/4oQGVPx
fetch the snapshots of the state from the API and push to the browser. We might explore some sort of long-term KV or state store in the future, but in the near term, I think this API would help - what do you think?
This makes sense - it's a cool approach. Our AgentKit library is doing something similar with state as well leveraging the output of steps to build up state. Ideally if state was persisted in the output of `step.run` and we added an API to query the output of each step you would be able to...
The Redis and pg URI options are documented here in our docs. We’d like to add a full docker compose example soon, but this should get you going.
www.inngest.com/docs/self-ho...
Yeah. That’s accurate. If you’re putting prod workloads on the self-host, I would run Redis and Postgres to back it instead of sqlite. You can also sign up for cloud for free to try things out pretty easily then move over to self -hosted later if you want.
Anything in particular that you’re curious about?
We should create a comparison table for reference, but our newest features like realtime and “connect” are also in self-hosted setup although may require some configuration. Self-hosting continues to get new benefits every week as that’s where our team commits our core code
It can be used in prod and devs are doing that today. It does not have feature parity with cloud though. It doesn’t have the o11y metrics dashboard, auth and bulk actions like replay or cancellation. All flow control and queueing are core to the self-hosted setup so execution is exactly the same!
coffee shop putting death cab and new bad bunny back to back, ideal for reaching flow this morning
Tomorrow we're teaming up with our friends at Inngest!
Learn how to build a content localization engine that instantly translates all of your content into whatever languages you'd like when you hit save
👉 RSVP for the workshop: directus.is/workshop/in...
Love starting the day and seeing messages like this in our Discord. Fuel for the day!
Awesome - ping me here or on our Discord with any feedback - we'd love thoughts on how to smooth out the API and things that might help you reduce boilerplate, etc.
Funny you should ask about hooks and realtime... www.inngest.com/docs/feature... (this developer preview just went live 2 days ago; haven't promoted it)
What do you think? We do need more examples, but we're iterating on APIs and hooks to make it as ergonomic as possible. Would love your feedback!
They’re selling Girl Scout cookies at the brewpub. This is genius, these girls are gonna sell so many boxes. Everyone is buying, including me.
durable execution is an abstraction, not the end goal.
I would love to layer on more ways to use Inngest’s primitives over time, like how we’re doing with AgentKit. I think as we’ve seen several other companies adopt the step/context.run model after Inngest tools could also be interoperable.
Yeah, that’s interesting. Maybe workflow kit needs to be more composable and kinda of like a portable format like it can be an output and an input whereas Inngest function outputs and trace visualizations now cannot be inputs.
Maybe this is a bad path the more I look at things. 🙈
I know this is asking a lot, but is there an example in the docs that matches your workflow most closely?
Not sure if this is a good approach, but I was looking for a way to hook into the xstate execution loop and inject Inngest's step.run into there.
That's helpful. I have to admit that I'm not very well accustom to xstate and just took a look at it for a few minutes to explore how we might map it to Inngest and there are so many ways to create state machines in xstate it's hard to find a clean path to map to
Ah ok - that's the main main value for you w/ xstate? the visual side of seeing it ahead of time?
Is that what you're thinking more or less? How would you wanna write this, with a state machine, a DAG or just in code with a kind of "router" function? Also, are you looking for functions that kind of run forever or something that is mostly executing to completion?
This is interesting, we have modeled ideas like this, especially for AI use case where each step.run within an Inngest function returns the current state of the entire workflow (like a DO) then the loop takes that current state and decides what to run next, returning the state.
This is insane level of TypeScript. Really a fun watch and some awesome how-we-did it context from Dimitri. I love this.
www.youtube.com/watch?v=0mCs...
At the end of the day, it's all highly dependent on your use case though, what are you building?
Lastly, Inngest has great coverage from our local dev server which runs on your machine for fast iteration and cloud observability with metrics and traces. Your code can run on any cloud or infra and it scales to billions of executions a month.
