Temporal vs Inngest vs Trigger.dev: which to choose

Temporal vs Inngest vs Trigger.dev: which one fits your durable work

If your team writes TypeScript or Python and needs durable background work, the choice comes down to where the work should run. Temporal fits multi-language, long-running business workflows that need a deterministic, replayable event history and a dedicated server cluster. Inngest fits event-triggered step functions that are invoked over HTTP. Trigger.dev fits TypeScript teams running long jobs and AI tasks that should live inside the application codebase. Licensing and self-hosting limits can change that answer, so read the rest of this page before you commit.

Start with the operating model you can actually support. A self-hosted Temporal Service runs Frontend, History, Matching and Worker services on top of a persistence store, and the Temporal deployment docs say these services should sit on hosts that are not reachable from the public internet. Inngest's self-hosting path is a single CLI binary that defaults to in-memory Redis and SQLite, which the docs say does not scale beyond a single node, so plan for external Redis and Postgres before production. Trigger.dev splits self-hosting into a webapp and a worker, and its overview says warm starts, auto-scaling and checkpoints are Cloud-only. Confirm each of these against your own network, Kubernetes and data-residency constraints, and confirm the license terms with your legal team, since Temporal is MIT, Inngest's server is under the Server Side Public License, and Trigger.dev is Apache-2.0.

Before you pick, run a short proof of concept against one real workflow. Check how the team handles a deploy that changes a running workflow, how retries and waits behave during an outage, and who on your staff will carry the on-call burden. Ask each vendor, in writing, which features you would need to buy through Temporal Cloud, Inngest's commercial options or Trigger.dev Cloud. The answer to that question often matters more than the feature list.

Which platform fits which scenario

This table maps five common situations to the platform that usually fits best and the condition that makes that choice hold. Read each row against your own team, language mix and licensing rules before treating it as a decision. The main takeaway is that Temporal suits operations-heavy, multi-language estates, while Inngest and Trigger.dev suit teams whose work lives inside a TypeScript or Python application.

Scenario	Best fit	Condition and reason
Multi-language workflow platform with an operations team	Temporal	Holds when several services in Go, Java, TypeScript or Python must share one durable model and you can staff a cluster with Frontend, History, Matching and Worker services plus a persistence store.
Event-triggered functions in a TypeScript or Python app	Inngest or Trigger.dev	Holds when the work is short event handlers or scheduled jobs living in the application repo. Inngest fits event-driven step functions with HTTP-invoked functions, while Trigger.dev fits task code deployed with the app.
Long-running AI tasks with human waits	Trigger.dev	Holds when a TypeScript team needs long-running tasks, waitpoints for human approval and run tracing. Confirm which checkpoint, warm start and auto-scaling features you need, since the self-hosting overview limits some of them to Trigger.dev Cloud.
Single-node pilot	Inngest or Trigger.dev	Holds when one node is enough for evaluation. Inngest's default SQLite persistence does not scale beyond a single node, and Trigger.dev self-hosts with Docker Compose. Plan the move to external Redis and Postgres before production.
Team that must avoid a non-OSI license	Temporal or Trigger.dev	Holds when a non-OSI license is a hard blocker. Temporal Server is MIT licensed and Trigger.dev is Apache-2.0, while Inngest's server is under the Server Side Public License until its delayed Apache 2.0 date. Confirm the terms with counsel before adoption.

How Temporal, Inngest and Trigger.dev execute durable code differently

Temporal runs durable code on worker processes that pull tasks from a Temporal Service, and it recovers state by replaying the complete, ordered event history of each workflow. After a worker restarts or a process fails, Temporal re-executes the workflow code against that history, so the code must make the same decisions on every replay. That makes determinism the central rule: workflow code should not read clocks, random numbers or external state directly, and side effects belong in activities, whose recorded results Temporal does not re-run during replay. Before the first production deploy, confirm with your team how it will check determinism and manage code changes to in-flight workflows, including the versioning approach in the SDK you choose. The Temporal Workflows documentation covers the model in detail.

Inngest works from the outside in. Triggers (events, cron schedules or webhooks) invoke a function over HTTP, and the function is organized as steps that retry automatically and can run for months. Each completed step keeps its result, so a retry picks up at the failed step and earlier steps are not repeated. Code that sits outside steps, however, runs again on each invocation, so the same determinism discipline applies to it even though the retry model differs from Temporal's. Flow control (concurrency, throttling, debouncing, rate limiting and prioritization) is part of the function model, and it is where concurrency limits for downstream systems get set. Confirm with Inngest how step results are stored, how long a run may wait between steps on your plan, and whether its guarantees for each step are documented in your deployment's terms.

Trigger.dev tasks are ordinary TypeScript functions inside your codebase, and the platform adds long-running execution, retries, queues and concurrency controls, durable cron schedules, and waits and waitpoints for human-in-the-loop steps. Checkpointing appears in the README, but the self-hosting overview states that checkpoints are available only on Trigger.dev Cloud. On a self-hosted deployment, you should therefore assume that a task may run again after a failure and make every external call, payment or write idempotent by design. Ask Trigger.dev which retry and resume behavior applies to self-hosted runs, how waits and waitpoints keep their state across a worker restart, and what changes when a run is paused for a human decision. Those answers determine how much idempotency logic your team must own.

Capabilities compared across all three platforms

This table sets Temporal, Inngest and Trigger.dev side by side on licensing, SDK languages, self-hosting components, persistence, authorization defaults, visibility, versions and managed-only features. Read each row as a question to answer for your own environment, and treat any item marked as to confirm as an open point for the vendor.

Capability	Temporal	Inngest	Trigger.dev
Server license	MIT for Temporal Server	Server Side Public License with delayed Apache 2.0 publication; SDKs are Apache 2.0	Apache-2.0 for the open-source platform
SDK languages	Go, Java, TypeScript and Python workflow code	TypeScript and JavaScript, Python, Go and Kotlin/Java	JavaScript and TypeScript SDK; tasks live in the application codebase
Self-hosted components	Frontend, History, Matching and Worker services plus persistence and visibility stores	Single CLI binary with Event API, runner, queue, executor, state store and dashboard	Webapp (dashboard, Redis, Postgres) plus worker (supervisor and runners)
Persistence options	Cassandra, PostgreSQL and MySQL tested; SQLite for development only	Default SQLite with in-memory Redis; external Redis and Postgres can be configured	Redis and Postgres
Scaling limit noted in docs	Separate visibility store needed, with Elasticsearch or OpenSearch advised at scale	Default SQLite does not scale beyond a single node	Confirm multi-node sizing guidance with Trigger.dev before committing
Default authorization	No Authorizer configured means every API request is allowed (noopAuthorizer); you must add one	Confirm default access controls for the self-hosted dashboard and API with Inngest	Confirm default access controls for the self-hosted dashboard and API with Trigger.dev
Built-in SSO and encryption options	mTLS, ClaimMapper, Authorizer plugin, OIDC for Web UI and custom payload codecs	Confirm SSO and payload encryption options for self-hosted deployments	Confirm SSO and payload encryption options for self-hosted deployments
Visibility and run tracking	Ordered event history plus advanced visibility store for querying executions	Dashboard and GraphQL and REST APIs for runs	Full run tracing in the dashboard
Latest version cited	v1.32.1, published October 8, 2026	v1.46.0, published October 6, 2026	v4.7.4, published October 14, 2026
Managed-only features	Temporal Cloud SLA options and SAML SSO	Warm starts, auto-scaling, checkpoints and dedicated support are cloud-only	Warm starts, auto-scaling, checkpoints and dedicated support are cloud-only

What each license allows and what sits behind a paid tier

The Temporal Server is MIT licensed, so you can run it, modify it and embed it in your own products under permissive terms. Temporal Technologies also sells Temporal Cloud as a managed service, and that paid offering is the main commercial path beyond the open-source server. Self-hosting shifts the operational work to your team, while Cloud moves it to the vendor under a billing model based on actions and storage.

Permissive server license: The MIT license on the Temporal Server places few restrictions on internal use, modification or redistribution. Confirm how your counsel reads attribution and notice requirements for any bundled components.
Security features in the open-source server: mTLS, a ClaimMapper, an Authorizer plugin, OIDC single sign-on for the Web UI and payload codecs are documented for self-hosted deployments. The default noopAuthorizer allows every API request until you configure access control.
Managed-only commercial terms: Temporal Cloud pricing lists a 99.9% SLA, or 99.99% with high availability, and SAML SSO. Confirm with the vendor which of these your self-hosted deployment does not receive.
Persistence and visibility stores: The license does not cover the databases you choose. Check the licenses of your Cassandra, PostgreSQL, MySQL, Elasticsearch or OpenSearch deployments separately.

Before production use, ask counsel to confirm the MIT terms against your distribution model and to review the licenses of every datastore in the stack.

What drives the running cost of each option

Each option charges for different things: staff time for self-hosting, metered usage for managed cloud, and features that sit behind a hosted tier. The cards below separate those cost drivers so a quote can be compared line by line against the scope your team actually needs to run.

Operator staffing for a Temporal cluster

A self-hosted Temporal Service runs Frontend, History, Matching and Worker services, plus a persistence store and, for advanced visibility, a separate Elasticsearch, OpenSearch or SQL visibility store. That is several moving parts to patch, scale and monitor, and the work recurs with every upgrade. Ask who on your team owns each service, how upgrades will be sequenced, and whether the quote includes ongoing operations or a one-time setup.

Temporal Cloud metered usage

Temporal Cloud pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, according to Temporal's pricing page. Actions, active storage and retained storage all rise with workflow volume, so a high-throughput service with long retention will cost more than a low-volume one. Model your expected action count and history retention before comparing against self-hosting staff time.

Inngest single-node default

By default, self-hosted Inngest runs as a single CLI binary with in-memory Redis for queue and state and SQLite for persistence. Inngest's documentation says SQLite does not scale beyond a single node, so moving to production load means provisioning external Redis and Postgres and operating them. Confirm which topology your quote assumes, and who pays for the scaling work when throughput grows.

Trigger.dev split webapp and worker

A self-hosted Trigger.dev deployment divides into a webapp, which includes the dashboard with Redis and Postgres, and a worker, which includes the supervisor and the runners that execute tasks. Both halves, and their data stores, need capacity planning and upgrades. Warm starts, auto-scaling, checkpoints and dedicated support are available only on Trigger.dev Cloud, so a self-hosted budget should not assume those features.

No vendor support for self-hosted Inngest

Inngest's self-hosting documentation says its support team does not guarantee direct support for self-hosted instances and points to enterprise options for dedicated support. Your running cost then includes in-house or partner time for incident response, which is not covered by the vendor. Ask any implementation partner whether support hours, escalation paths and on-call coverage are in scope, and price them separately from the build work.

Securing self-hosted Temporal, Inngest and Trigger.dev

Self-hosted Temporal allows every API request until you configure an Authorizer. If no Authorizer is set, the server uses the default noopAuthorizer, which permits all API calls with no authentication or access control. Treat that default as a blocking gap, not a starting point. Before any environment holds real workflow data, decide how namespace access will work and wire it in. The built-in options are mTLS with separate settings for internode and frontend traffic, a ClaimMapper that maps JWT or certificate claims to namespace roles, a custom Authorizer plugin, OIDC single sign-on for the Web UI, and payload encryption through custom codecs and a codec server. Your security team should confirm which combination matches its identity provider and certificate authority, and should test that an unauthorized client is actually refused.

The Temporal deployment documentation says Temporal services should run on hosts not reachable from the public internet, with network access limited to trusted internal networks. Apply that to the Frontend, History, Matching and Worker services and to the persistence and visibility stores behind them. Check the network path from each worker and client to the Frontend, and confirm that the database and Elasticsearch or OpenSearch endpoints are not exposed. For upgrades, move one minor version at a time and go to the latest patch of the current minor first, because backward compatibility is guaranteed only between two successive minor versions. Where release notes call for a schema upgrade, run it before the server upgrade. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so pin chart and image versions together.

The supplied facts do not describe how Inngest or Trigger.dev authenticate users, service-to-service calls or dashboard access in a self-hosted deployment, and they do not say whether either offers mTLS, role mapping or SSO for self-hosted installs. Do not assume parity with Temporal. Ask each vendor, in writing, which authentication methods, role models and SSO integrations apply to self-hosting, which network endpoints need protection, and how secrets and payload encryption are handled. Inngest's self-hosting documentation says its support team does not guarantee direct support for self-hosted instances, so put these questions to the vendor and test the answers in a pre-production environment. Include the answers in the security review before choosing a platform.

What implementing each platform involves, step by step

This sequence takes a team from an SDK choice to a tested pilot on Temporal, Inngest or Trigger.dev, and shows where each platform adds or removes work at every stage.

Choose the SDK language and code layout
The application team picks the language and decides where durable code lives. Temporal offers SDKs for Go, Java, TypeScript and Python, and its workflows are written as code that must follow deterministic rules, so developers need to learn what is safe to call inside a workflow. Inngest offers SDKs for TypeScript and JavaScript, Python, Go and Kotlin/Java, and its functions run as HTTP-invoked steps in your application. Trigger.dev tasks use its JavaScript and TypeScript SDK inside the application codebase. The step is done when a team has one sample function per candidate platform that runs in a local development environment and the developers agree on the code layout.
Pick the deployment method
Platform engineering chooses how the server runs in your infrastructure. Temporal can be deployed with Docker Compose, Go binaries, Helm charts that run each Temporal Server service in its own Kubernetes pod, or by importing the server package into a custom Go build, and its services should sit on hosts not reachable from the public internet. Inngest self-hosting is a single CLI binary that runs all services, with in-memory Redis and SQLite by default, which the vendor documents as unable to scale beyond a single node. Trigger.dev self-hosts through Docker Compose or an official Helm chart and splits into a webapp and a worker. The step is done when the chosen method has run in a non-production environment and the team has written down which components it operates and which it does not.
Configure persistence and queues
The team selects and provisions the stores the platform needs. For Temporal, persistence is tested on Cassandra, PostgreSQL and MySQL, with SQLite for development only, and advanced visibility uses Elasticsearch or OpenSearch for larger volumes, so a Cassandra deployment adds a separate visibility store. For Inngest, moving beyond the default SQLite requires configuring external Redis and Postgres. For Trigger.dev, the webapp depends on Redis and Postgres. The step is done when backups for each store are defined, a restore has been tested, and the database versions match the vendor's tested list. Ask each vendor which database versions they test and confirm them against your own standards before you commit.
Add authorization, identity and secrets handling
Security engineering sets access controls before any real workflow data flows through the system. Temporal's default Authorizer is noopAuthorizer, which allows every API request, so teams must configure an Authorizer, a ClaimMapper for namespace roles, mTLS for internode and frontend traffic, and OIDC single sign-on for the Web UI. Payload encryption through a custom codec and codec server is also a Temporal setup task. Inngest and Trigger.dev self-hosting documentation should be checked for equivalent controls on your version, including how the dashboard is protected and where signing and API keys are stored. The step is done when an unauthenticated request is shown to be rejected, role mapping has been tested with real identities, and secrets are held in your existing secrets manager.
Define retries, timeouts and flow control
The application team writes the retry policy, concurrency limits and rate controls for each workflow type. Temporal expresses retries and timeouts in workflow and activity code, and its event history allows a workflow to resume after failure. Inngest provides flow control built in: concurrency, throttling, debouncing, rate limiting and prioritization, plus steps that retry automatically. Trigger.dev provides queues, concurrency controls and retries as part of the task model, along with waits and waitpoints for human-in-the-loop steps. The step is done when each workflow type has documented retry and concurrency settings and a reviewer has checked that side effects inside retried steps are idempotent.
Run a failure test
The team deliberately breaks the system to see how each platform recovers. For Temporal, stop a worker in the middle of a workflow and confirm the workflow resumes from its recorded history. For Inngest and Trigger.dev, interrupt a running step or task and confirm that the retry or checkpoint behaves as the team's design expects, noting that Trigger.dev checkpoints and warm starts are documented as Cloud-only. Also test the single-node limit on Inngest's default storage and any dependency outage on Redis or Postgres. The step is done when every failure case has a recorded outcome, an owner for each gap, and a decision on whether the gap blocks production.
Rehearse an upgrade
Operations runs a version upgrade in a copy of the environment before the first production upgrade. For Temporal, follow the documented path of moving one minor version at a time to the latest patch of the current minor, running schema upgrades before server upgrades when release notes require them, and check that the Helm chart version is compatible with the server image. For Inngest and Trigger.dev, confirm the release notes for breaking changes, including Trigger.dev's note that 4.5.0 was the last version to run v3 tasks. The step is done when the upgrade, rollback and task-in-flight behavior have been written into a runbook and timed by your own team. Ask each vendor for its support window for self-hosted versions before you sign off.
Document the support model and hand over
The team decides who answers when the platform breaks and records it. Temporal self-hosting relies on your own operations team plus any commercial support you contract separately, while Temporal Cloud is a managed option with its own SLA terms. Inngest's documentation says it does not guarantee direct support for self-hosted instances and points to enterprise options. Trigger.dev documents community support for self-hosting, with dedicated support available on its Cloud. DeployOpen can plan, implement, harden, back up, upgrade and document a self-hosted deployment under a fixed-scope written agreement, and offers retainers for ongoing support. The step is done when the runbooks, dashboards, alerts and escalation paths are handed over and the owning team has signed them off.

Questions buyers ask before choosing a durable execution platform

What does implementing Temporal, Inngest or Trigger.dev cost in effort, and who pays for what?

The software licenses for the three options are different. Temporal Server is MIT licensed, Inngest's server is under the Server Side Public License with delayed Apache 2.0 publication, and Trigger.dev is Apache-2.0 licensed, so the recurring software line is often zero for self-hosting. The larger costs are engineering time to write and test workflow code, the platform team's time to run the infrastructure, and any external consultant or partner fees. Ask any vendor or partner for a written quote that separates one-time build work from recurring operations, upgrades and support. For managed options, Temporal Cloud publishes pay-as-you-go pricing starting at 50 US dollars per million actions on its pricing page, but Inngest and Trigger.dev Cloud pricing must be confirmed on their sites.

How long does a pilot take, and what drives the timeline?

The pilot length depends mainly on how many workflows you migrate, how many services must be reachable from the engine, and how much of the platform your team must build. Temporal pilots usually carry the most infrastructure work because a self-hosted Temporal Service runs Frontend, History, Matching and Worker services plus a persistence store, and you must choose and size that store. Inngest and Trigger.dev pilots can start faster on a single node, but Inngest's default SQLite persistence does not scale beyond a single node, so a production plan needs external Redis and Postgres. No duration figure is supplied here, so ask any implementation partner to state the timeline and its assumptions in the written scope before work starts.

Can a small team realistically self-host each option?

A small team can self-host any of the three, but the operating load differs. Trigger.dev splits a deployment into a webapp (dashboard, Redis and Postgres) and a worker (supervisor and runners), and it documents Docker Compose and an official Helm chart. Inngest ships its CLI as a single binary with all services, which is the lightest start, but the project states that it does not guarantee direct support for self-hosted instances. Temporal has the most moving parts: Helm chart versions below 0.73.1 do not work with server images 1.30 and later, upgrades should move one minor version at a time, and the Temporal deployment docs say services should not be reachable from the public internet. Ask whether your team has on-call capacity for each component.

Should we hire a consultant or implementation partner for this?

Hire outside help when the internal team lacks the time or experience to run a durable engine in production, or when security review requires a documented hardening and backup plan. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any partner to show which Temporal, Inngest or Trigger.dev components they will operate and who keeps the runbooks afterward.

Which option fits a Python-only team best?

Temporal is the option with an established multi-language SDK model, and its workflows are written in general-purpose languages including Python, so a Python-only team can use it without learning another language. Inngest provides SDKs for TypeScript and JavaScript, Python, Go and Kotlin/Java. Trigger.dev tasks are written with its JavaScript and TypeScript SDK, so it is the weakest fit for a team that writes no TypeScript. Your choice then turns on whether you need a replayable event history with deterministic workflow code (Temporal) or event-triggered functions (Inngest). Confirm each SDK's Python feature parity with the vendor before committing, since feature coverage can differ by language.

What changes if our license must allow commercial use?

Licensing is the main difference here. Temporal Server is MIT licensed, which permits commercial use without a separate agreement under its published terms. Trigger.dev is Apache-2.0 licensed. The Inngest server and CLI are under the Server Side Public License, with the software scheduled to become Apache 2.0 on the third anniversary of its release, and all Inngest SDKs are Apache 2.0. Have your legal team review the exact license text in each repository for the version you deploy, and confirm with the vendor whether any paid tier changes the terms for your use case.

How hard is it to move between these platforms later?

Switching is hardest once workflows hold long-running state. Temporal workflows are code with a replayable event history, so they are rewritten in the new SDK rather than exported, and in-flight executions need a drain or cutover plan. Inngest and Trigger.dev functions are also code in your application, so the rewrite cost is similar in kind, though the trigger and step models differ. To keep options open, keep business logic in plain functions that are called from thin workflow wrappers, document retry and idempotency rules per step, and ask any partner to estimate migration effort from the workflow inventory rather than from the platform choice alone.

What switching later costs once workflows are in production

Switching later is expensive because lock-in sits in your workflow code, not in the platform's configuration. With Temporal, a workflow's ordered event history is what allows replay and resume after failures, so in-flight executions are tied to the SDK and workflow definitions that produced them. Those histories cannot simply be moved into Inngest or Trigger.dev. The practical path is to let running executions finish on the old cluster, stop starting new ones, and only then retire the namespace. Confirm with Temporal how long a namespace must stay up to drain, and whether any history export exists for audit retention.

Inngest and Trigger.dev lock you in through different mechanisms. Inngest functions are defined through its triggers, flow control and steps, and its HTTP-invoked model means the application endpoints and event names become part of the contract. Trigger.dev tasks live in your codebase with its TypeScript SDK, and it keeps run state, queues and waitpoints in its own platform. Before choosing either, ask each vendor in writing what it exports for in-flight and completed runs, what format that export takes, and whether pending waits or human-in-the-loop steps can be carried over.

Plan the switch as a drain, not a migration. Keep retry and idempotency logic in shared service code where possible, so a replacement engine calls the same business functions, and record which workflow versions are still running. Illustratively, a team with long approval waits might need to keep the old runtime online until the longest wait expires, which is a timeline set by the business process, not the vendor. Ask every vendor for its documented export limits, its version support window, and the steps your team would own during a cutover.

How DeployOpen helps choose and implement a durable execution platform

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Temporal, Inngest or Trigger.dev decision, that means helping your team test the candidates against your own workloads and then running the chosen platform in your environment.

How we scope

Written scope agreed before work starts, covering which platform, which languages and which workloads are in it
Inventory of your background jobs, retry needs, long-running AI tasks and event triggers to test against each candidate
Decisions on hosting target, persistence store, identity integration and secrets handling, recorded in the scope document
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing

How we build

Deploy the chosen platform in your cloud account, data center or air-gapped network, following your network and access rules
Configure authentication, authorization, TLS and payload handling against the vendor's documented security options
Build sample workflows or tasks in your application language to verify retries, timeouts and failure recovery
Run security testing of the workflow APIs, dashboards and self-hosted components before go-live

How we hand over

Written architecture and runbook covering components, upgrade order and the backup and restore procedure
Documented configuration for the persistence store, visibility or dashboard, and the self-hosted services each depends on
Knowledge transfer sessions so your engineers can deploy, change and troubleshoot workflows without us
Evidence and control documentation prepared for your compliance assessors, who issue any audit reports

How we support

Ongoing support, upgrades and continuous testing available as a retainer after handover
Upgrade planning that follows the vendor's documented version sequence and schema steps
Confirm with the vendor which support tiers apply to your self-hosted deployment before you commit
Periodic re-testing of workflows and access controls as your application and platform versions change

Temporal vs Inngest vs Trigger.dev

Temporal vs Inngest vs Trigger.dev: which one fits your durable work

Which platform fits which scenario

How Temporal, Inngest and Trigger.dev execute durable code differently

Capabilities compared across all three platforms

What each license allows and what sits behind a paid tier

What drives the running cost of each option

Operator staffing for a Temporal cluster

Temporal Cloud metered usage

Inngest single-node default

Trigger.dev split webapp and worker

No vendor support for self-hosted Inngest

Securing self-hosted Temporal, Inngest and Trigger.dev

What implementing each platform involves, step by step

Choose the SDK language and code layout

Pick the deployment method

Configure persistence and queues

Add authorization, identity and secrets handling

Define retries, timeouts and flow control

Run a failure test

Rehearse an upgrade

Document the support model and hand over