danfarrelly

Inngest (https://www.inngest.com) | Engineers, Marketing+GTM | Remote (US, San Francisco) | Full-time | $130-245k + equity Inngest is a developer platform that enables developers to build amazing, complex, and reliable products without the hassle of building and maintaining infrastructure. It combines modern orchestration, advanced multi-tenant aware queueing, and built-in observability packaged in an easy to learn and use product that any developer can learn.

We're backed by top tier investors including a16z, Notable Capital, Afore capital and angels including Guillermo Rauch (Vercel) and Tom Preston-Werner (Github co-founder). We serve customers from startups and large co's like Resend, SoundCloud, Gumroad, TripAdvisor, Browser Use.

You: Want to be part of a fast growing startup that is changing how developers build software.

- Distributed Systems Engineer - San Francisco

- Product Engineer - Full Stack - San Francisco, Remote US

- Developer Success Engineer - Remote US

- Content Engineer, Docs - Remote US

- Product Marketer - San Francisco

Roles: https://innge.st/hn-june-25-hiring

About working @ Inngest: https://innge.st/hn-june-25-info

Inngest (https://www.inngest.com) | Engineers, Marketing+GTM | Remote (US, San Francisco) | Full-time | $130-245k + equity

Inngest is a developer platform that enables developers to build amazing, complex, and reliable products without the hassle of building and maintaining infrastructure. It combines modern orchestration, advanced multi-tenant aware queueing, and built-in observability packaged in an easy to learn and use product that any developer can learn.

We're backed by top tier investors including a16z, Notable Capital, Afore capital and angels including Guillermo Rauch (Vercel) and Tom Preston-Werner (Github co-founder). We serve customers from startups and large co's like Resend, SoundCloud, Gumroad, TripAdvisor, Browser Use.

You: Want to be part of a fast growing startup that is changing how developers build software.

- Product Engineer - Full Stack - San Francisco, Remote US

- Infrastructure Engineer - Remote US

- Distributed Systems Engineer - San Francisco

- Developer Success Engineer - Remote US

- Content Engineer, Docs - Remote US

- Product Marketer - San Francisco

Roles: https://innge.st/hn-may-25-hiring

About working @ Inngest: https://innge.st/hn-may-25-info

You can grab the LLMs-full.txt file here: https://agentkit.inngest.com/llms-full.txt

More realtime examples coming soon!

CTO @ Inngest here. Each event is published with an API key associated with a particular account workspace. We add the workspace id along side the each event in the stream so matches are only evaluated against the matching expressions in a particular workspace. This is the first tier of filtering, but many customers send millions of events and have millions of matchers each day so even at the individual workspace level, the optimizations are necessary to prevent backlogs across user accounts.

How do they handle multi-tenancy for their users? Any post on that?

We'll also be supporting long-running services as well in the near future which subscribe to updates from Inngest, rather than get invoked via HTTP.

Currently, to get beyond the ~5 min limit per step, you'd need to deploy to something non-serverless like Fly.io, Render, or your own instance running Express.js or similar.

This is pretty much what Inngest is (https://www.inngest.com/). Runs on Deno as well.

Our team has just started to use this a bit more and I really liked the .insomnia dir in our projects. This is pretty sad as we've seen this path with Postman - I ~~thought~~ hoped that since Kong had plenty of other viable revenue streams that Insomnia would stay out of this nonsense. Disappointing.

Thanks! RedwoodJS is fantastic and we've been fortunate to collaborate with the core team to build in some great support for Inngest :)

We also collaborated with their core team on a GraphQL envelop plugin that automatically sends events for every mutation called in your api: https://github.com/inngest/envelop-plugin-inngest

Inngest has built in concurrency controls and rate limiting to prevent systems from being overloaded, allowing the user to have the same controls of a traditional worker, but just a simple config option.

Inngest was designed to be a solution that can replace traditional queuing systems and event driven systems. Originally, it was built with the idea to handle complex flows that need to be durable, e.g. healthcare workflows that have time-based follow ups and legal compliance tasks that need to be executed in a specific order depending on patient confirmation or other actions.

We've seen users build all sorts of things: automate infrastructure based on events, building AI Agents around LLMs, perform vulnerability scans across thousands of packages, building scheduling products, and e-commerce data pipelines. We're seeing new use cases each week.

Funny enough, we were fortunate to meet Guillermo through our lead, GGV as part of due diligence. GGV had recently led Vercel's recent round so he was part of the process of vetting our product. Our timing was also great as we had recently shipped our Vercel integration [1] and were the only integration supporting background jobs and workflows in their integration marketplace. He quickly recognized the value in what we were building and was interested to invest. It was an ideal combination of timing of having built something of value to the Vercel ecosystem and being intro'd!

Guillermo has been a fantastic supporter overall :)

[1] https://vercel.com/integrations/inngest

Yeah - definitely overlapping use cases! I expanded on more detail above: https://news.ycombinator.com/item?id=36698178

Hey thanks for the comparison - Temporal is a powerful tool. There are definitely similarities with what Inngest is capable of. Here are a few differences to highlight:

- We’ve taken a different approach that removes the queue and worker abstraction from the end developer and instead uses an HTTP-based invocation. This enables Inngest functions to be run on any platform, including serverless.

- Inngest is powered by events which gives developers the ability to fan out work and build event-driven flows easily.

- Inngest also allows you to coordinate across events, enabling workflows to pause and wait for additional input (step.waitForEvent [1]). This is powerful for human-in-the-middle workflows (e.g. AI confirmation flows) or workflows that pause for days or weeks and conditionally run steps depending on what a user might do in your system (e.g. dynamic email drip campaigns)

- Lastly, events also provide a nice way to easy replay of your workflows across any time window.

- One last thing is that we’ve heard many times that while devs are often quite excited about Temporal, they’ve found Inngest to be much easier to learn and build with. We’ve intentionally worked to make our first SDK with the simplest primitives so their workflows just look like normal code, with minimal DSL.

[1] https://www.inngest.com/docs/reference/functions/step-wait-f...

Thanks! Fixed :)

Inngest co-founder here - happy to answer any questions about Inngest or our fundraising!

I've seen the demo of this and it's pretty slick! It looks super easy to use and it uses Inngest under the hood which is awesome (I'm one of the co-founders of Inngest [https://www.inngest.com] so it's always very cool to see fun and creative projects like this launch with our product - also Sam is great!

Good question. This was a hard question for us last year and we chose SSPL for the time being as a early stage startup to offer some protection. AGPL allows anyone to deploy your system and re-sell it, but SSPL requires the person to open source their additions that they make for their platform, which benefits the project itself.

*Caveat*: This is super nuanced and hotly debated, so this is high level and no perfect answer here.

Mid term, we plan to move from SSPL to a more open license in the future as we further develop our open source project.

Exactly - we have many users that have come over after using Temporal. We designed our SDK to be more lightweight and flexible. We want it to feel more just like writing normal code, not a new coding paradigm. For example, you can define steps right within your function, not as separate "activities."

Being HTTP based (push vs. pull), it's easier to manage and works natively with serverless and servers.

Inngest is also event-driven, so you can fan-out and do things like have your workflow wait for another event. Our `step.waitForEvent()` allows you to pause a function until another event is received, creating dynamic jobs that can wait for additional actions or input. Also, using events allows us to replay failures super easily.

re: ActiveJob - Yeah, multi-step workflows are a huge difference. We manage step retries and the function state for you. That makes things like sleep and coordinating between events easy. As you mentioned, it leads to simpler function definition so it means that almost any engineer can write workflows quickly and easily read the code in a single place, reducing bugs due to disconnected jobs.

This is great - we do capture all logs for each run including any retries, so you can see errors and general successes. All of these other metrics we have internally, but need to expose to our users!

Observability is super key for background work even more so since it's not always tied to a specific user action, so you need to have a trail to understand issues.

> One thing that is easy to overlook is giving users the ability to define a specific “urgency” for their jobs which would allow for different alerting thresholds on things like running time or waiting.

We are adding prioritization for functions soon so this is helpful for thinking about how to think about telemetry for different priority/urgent jobs.

re: timeouts - managing timeouts usually means managing dead-letter queues and our goal is to remove the need to think about DLQs at all and build metrics and smarter retry/replay logic right into the Inngest platform.

> we had rolled our own monitoring which was itself a PITA to maintain

Thanks! What type of monitoring were you looking for? We have some basic metrics now, but know we need to improve this. What metrics, alerting, observability are important for you?

This is a great one. I've experienced this myself, especially when you change an event/message and then you need to handle that change in your job/workflow. Things can break pretty easily so you need to have versioning for both.

This is why we've built event schema versioning and versioning for functions baked into the platform. We have big plans for the schema management side of things that bring concepts of data governance to engineering teams. It should just be for data teams. As a bonus, we can also generate language types from schemas easily then.

What else about schema management is a pain? What have you used for this?

We started with TypeScript because it's not well supported with a current solution and none of them support serverless. We wanted to solve serverless first as it's made supporting long-running servers easy.

A lot of folks in the TS/JS community also don't often build distributed systems and it's easy to get wrong. So we think they're hungry for something like Inngest that they don't need to manage or spend weeks learning some complex system. Plus, TS gives us typing for all events/messages.

We already have a working Go SDK that we use internally and we have a test harness that will enable us to add other languages like Rust or Zig more easily. We even have a community member building a PoC for Elixir.

Thanks for the comment! what were some of the most painful parts of this at the companies that you worked for?

Sure! My previous employers were also great places to work, I've been pretty fortunate in my career. I can understand my response may feel generic, if we were having this convo over a coffee or beer, I could tell you in greater detail.

If I was someone just after the money, I could choose to go downtown and work in fin-tech. Everyone has their own motivations, values and desires. Buffer fits very well within mine!

"an employee could look at that formula after a year and think, "Well, I know where I am now and where I could be in two years, no reason to stay here for that.""

The good part about this is that the formula and system is open to change and will continue to evolve as we find ways that it could be working better for us. We're actually in the midst of some changes right now that have and will really help the formula work in the coming months & years.