Hey @josegonzalez - you're spot on with your comments and a few cloud "stacks" will definitely be in our docs as we proceed. I'd like an AWS and GCP to start w/ open source services as well that could run anywhere. Here's a reference for what could work for backing components:

Resources

• Event Stream - AWS managed Kafka, SQS, or SNS+SQS, Kinesis
  • Inngest uses Go Cloud's pubsub package so really anything with an existing driver, but really anything could be used if it implements the pubsub package patterns.
  • The simplest set up would be SQS or Kafka
  • An advanced set up might use a SNS+SQS set up for multi-region or multi-account. Think a single global Events API with data being processed in different regions' SQS queues.
• Job Queue - SQS fits best, but you could use managed Redis w/ Redis Streams
• DBs - The State and System DBs could be the same in a simple setup, but for performance when scaling, it would be ideal to split them into databases designed for their purposes:
  • System DB - This stores the configuration of how the system should receive events and execute jobs. The basic information is the function versions, function event triggers, function step versions, Events API keys. Most of the data is immutable as there is versioning, so it is read more than it is written to.
    • AWS RDS w/ pretty much any db engine would work well.
    • DynamoDB would work here as well, although, indexes would have to be set up correctly and it could be expensive depending on your experience provisioning read/write capacity.
    • Theoretically DocumentDB could work as well, but our initial work will be around relational DBs
  • State DB - This stores the current state of jobs being executed. The Runner and Executor write the metadata for current jobs including the function being executed, the event itself and the responses/errors from individual function steps. This state is used to pass data from step to step as well as retry failed steps.
    • AWS ElasticCache (Redis) - This would provide the performance that would be ideal in a production setup.

Services

• Our goal is for all 4 Inngest services to produce metrics that can be used for understanding when to scale out (CPU, throughput, etc.). CPU and throughput should be fine indicators for scaling horizontally.
  • Runner - This may partially depend on your Event Stream's configuration. For example, if you're using Kafka, it would be ideal for your Kafka topic to have enough partitions so you can scale our your Runners (Kafka consumers as part of a consumer group in this case) horizontally.
  • Executor - In the future we may also expose metrics for the "time to execution" which could show how long a function takes to get triggered from the time when the event is received. Your system may have different design goals which may mean you need to scale up your executors (and maybe Runners).

Misc

Other areas not included in the stack or diagram are your own choices in:

• Network - network policy, reverse proxies, load balancers, etc.
• Authentication - Authentication is current out of scope for Inngest API's self-hosted MVP, but we hope to add it in the future. We plan to learn more about how people might want to authenticate
• Image registry - We're leaving choice of and authentication for your container image registry to the user, the Inngest CLI will build and push images, but your user (or machine for CI/CD) will have to be authenticated with your registry. Inngest Cloud run's its own registry proxy and we understand teams may have different desires for how they do this.

I know that's a bit of a brain dump here and @tonyhb shared some great thoughts in Discord, but I hope this helps aide in planning and discussion for you and others!

Legally you can self-host, as long as you're not doing whole sale. :)

Unfortunately, it's not the highest priority for us at the moment, and bits and pieces are missing for the OSS version to work as a standalone workload that you can use in prod. e.g. authn, authz etc

We do have self-hosting in mind as a roadmap item so efforts around this will happen, just unclear when yet.

FYI your guys' product is awesome!

As far as self-hosting goes, what are the main things missing?

If it's just auth, would you say it might be usable in prod by hosting within a private network? Alternatively, by self imposing auth before running the server handler? Thanks!