For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | danfarrelly's commentsregister

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?


I don't know, but the requirements are different. They manage a single huge queue for your website (or part of it), and your own backend is expected to be able to handle some trivially small number of concurrent users. The most common use case is highly contentious online ticket sales, where users might even wait an hour in line. Latency isn't much of a concern.


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


Ingest is definitely nice. Its design is an orchestrator/scheduler where you offload your workers as serverless functions.

The only issue is for background jobs you need to design it in such way to not run in to timeouts.

Which makes it slightly more complex then just having a single executable running periodically.

There is also https://www.defer.run/ which run your code on their infra and don't have timeouts. But they only support node/bun at the moment.


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.


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


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


Temporal is designed for industrial strength flows and scale. For example an HTTP based push mechanism can overload workers hence the queue.

And its jusr code so not sure about the DSL reference (of course thats common with other systems)?

What use cases is this designed for? Easier to learn and build usually has tradeoffs


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.


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


Just to confirm my understanding; would you consider at least part of your product offering to be similar to temporal.io [1]? Your examples are reminiscent of theirs. [1] https://temporal.io/


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


No questions, just wanted to say congrats!


Congrats on the funding

Typo on this line

Your CI/CD process remains the same as before and Inngest


Thanks! Fixed :)


What's the best way to go about getting Guillermo's attention?


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


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You