Merge branch 'main' into fix/feb-miscellaneous-fixes

Author: mpcgrid

docs/deploy-environment-variables.mdx

@@ -66,6 +66,18 @@ You can edit an environment variable's values. You cannot edit the key name, you
 
 </Steps>
 
+## Local development
+
+When running `npx trigger.dev dev`, the CLI automatically loads environment variables from these files in order (later files override any duplicate keys from earlier ones):
+
+- `.env`
+- `.env.development`
+- `.env.local`
+- `.env.development.local`
+- `dev.vars`
+
+These variables are available to your tasks via `process.env`. You don't need to use the `--env-file` flag for this automatic loading.
+
 ## In your code
 
 You can use our SDK to get and manipulate environment variables. You can also easily sync environment variables from another service into Trigger.dev.
@@ -360,4 +372,55 @@ This will read your .env.production file using dotenvx and sync the variables to
 
 - Trigger.dev does not automatically detect .env.production or dotenvx files
 - You can paste them manually into the dashboard
-- Or sync them automatically using a build extension
+- Or sync them automatically using a build extension
+
+## Multi-tenant applications
+
+If you're building a multi-tenant application where each tenant needs different environment variables (like tenant-specific API keys or database credentials), you don't need a separate project for each tenant. Instead, use a single project and load tenant-specific secrets at runtime.
+
+<Note>
+  This is different from [syncing environment variables at deploy time](#sync-env-vars-from-another-service). 
+  Here, secrets are loaded dynamically during task execution, not synced to Trigger.dev's environment variables.
+</Note>
+
+### Recommended approach
+
+Use a secrets service (Infisical, AWS Secrets Manager, HashiCorp Vault, etc.) to store tenant-specific secrets, then retrieve them at the start of each task run based on the tenant identifier in your payload or context.
+
+**Important:** Never pass secrets in the task payload, as payloads are logged and visible in the dashboard.
+
+### Example implementation
+
+```ts
+import { task } from "@trigger.dev/sdk";
+import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";
+
+export const processTenantData = task({
+  id: "process-tenant-data",
+  run: async (payload: { tenantId: string; data: unknown }) => {
+    // Retrieve tenant-specific secret at runtime
+    const client = new SecretsManagerClient({ region: "us-east-1" });
+    const response = await client.send(
+      new GetSecretValueCommand({
+        SecretId: `tenants/${payload.tenantId}/supabase-key`,
+      })
+    );
+
+    const supabaseKey = JSON.parse(response.SecretString!).SUPABASE_SERVICE_KEY;
+
+    // Your task logic using the tenant-specific secret
+    // ...
+  },
+});
+```
+
+You can use any secrets service - see the [sync env vars section](#sync-env-vars-from-another-service) for an example with Infisical.
+
+### Benefits
+
+- **Single codebase** - Deploy once, works for all tenants
+- **Secure** - Secrets never appear in payloads or logs
+- **Scalable** - No project limit constraints
+- **Flexible** - Easy to add new tenants without redeploying
+
+This approach allows you to support unlimited tenants with a single Trigger.dev project, avoiding the [project limit](/limits#projects) while maintaining security and separation of tenant data.

docs/idempotency.mdx

@@ -428,18 +428,22 @@ export const parentTask = task({
 });
 ```
 
-When resetting from outside a task (e.g., from your backend code), you must provide the `parentRunId`:
+When resetting from outside a task, you must provide the `parentRunId` if the key was created within a task context:
 
 ```ts
 import { idempotencyKeys } from "@trigger.dev/sdk";
 
-// From your backend code - you need to know the parent run ID
+// If the key was created within a task, you need the parent run ID
 await idempotencyKeys.reset("my-task", "my-key", {
   scope: "run",
   parentRunId: "run_abc123"
 });
 ```
 
+<Note>
+If you triggered the task from backend code, all scopes behave as global (see [Triggering from backend code](#triggering-from-backend-code)). Use `scope: "global"` when resetting.
+</Note>
+
 ### Resetting attempt-scoped keys
 
 Keys created with `"attempt"` scope include both the parent run ID and attempt number. When resetting from outside a task, you must provide both:

docs/limits.mdx

@@ -55,6 +55,14 @@ If you add them [dynamically using code](/management/schedules/create) make sure
 
 If you're creating schedules for your user you will definitely need to request more schedules from us.
 
+## Projects
+
+| Pricing tier | Limit              |
+| :----------- | :----------------- |
+| All tiers    | 10 per organization |
+
+Each project receives its own concurrency allocation. If you need to support multiple tenants with the same codebase but different environment variables, see the [Multi-tenant applications](/deploy-environment-variables#multi-tenant-applications) section for a recommended workaround.
+
 ## Preview branches
 
 | Pricing tier | Limit                |

docs/self-hosting/docker.mdx

@@ -354,6 +354,8 @@ TRIGGER_IMAGE_TAG=v4.0.0
   docker compose logs -f webapp
   ```
 
+- **Deploy fails with `ERROR: schema "graphile_worker" does not exist`.** This error occurs when Graphile Worker migrations fail to run during webapp startup. Check the webapp logs for certificate-related errors like `self-signed certificate in certificate chain`. This is often caused by PostgreSQL SSL certificate issues when using an external PostgreSQL instance with SSL enabled. Ensure that both the webapp and supervisor containers have access to the same CA certificate used by your PostgreSQL instance. You can configure this by mounting the certificate file and setting the `NODE_EXTRA_CA_CERTS` environment variable to point to the certificate path. Once the certificate issue is resolved, the migrations will complete and create the required `graphile_worker` schema.
+
 ## CLI usage
 
 This section highlights some of the CLI commands and options that are useful when self-hosting. Please check the [CLI reference](/cli-introduction) for more in-depth documentation.

docs/self-hosting/kubernetes.mdx

@@ -555,6 +555,7 @@ kubectl delete namespace trigger
 - **Deploy fails**: Verify registry access and authentication
 - **Pods stuck pending**: Describe the pod and check the events
 - **Worker token issues**: Check webapp and supervisor logs for errors
+- **Deploy fails with `ERROR: schema "graphile_worker" does not exist`**: See the [Docker troubleshooting](/self-hosting/docker#troubleshooting) section for details on resolving PostgreSQL SSL certificate issues that prevent Graphile Worker migrations.
 
 See the [Docker troubleshooting](/self-hosting/docker#troubleshooting) section for more information.
 

docs/troubleshooting.mdx

@@ -151,6 +151,10 @@ Your code is deployed separately from the rest of your app(s) so you need to mak
 
 Prisma uses code generation to create the client from your schema file. This means you need to add a bit of config so we can generate this file before your tasks run: [Read the guide](/config/extensions/prismaExtension).
 
+### Database connection requires IPv4
+
+Trigger.dev currently only supports IPv4 database connections. If your database provider only provides an IPv6 connection string, you'll need to use an IPv4 address instead. [Upvote IPv6 support](https://triggerdev.featurebase.app/p/support-ipv6-database-connections).
+
 ### `Parallel waits are not supported`
 
 In the current version, you can't perform more that one "wait" in parallel.
@@ -171,12 +175,52 @@ The most common situation this happens is if you're using `Promise.all` around s
 
 Make sure that you always use `await` when you call `trigger`, `triggerAndWait`, `batchTrigger`, and `batchTriggerAndWait`. If you don't then it's likely the task(s) won't be triggered because the calling function process can be terminated before the networks calls are sent.
 
+### `COULD_NOT_FIND_EXECUTOR` 
+
+If you see a `COULD_NOT_FIND_EXECUTOR` error when triggering a task, it may be caused by dynamically importing the child task. When tasks are dynamically imported, the executor may not be properly registered.
+
+Use a top-level import instead:
+
+```ts
+import { myChildTask } from "~/trigger/my-child-task";
+
+export const myTask = task({
+  id: "my-task",
+  run: async (payload: string) => {
+    await myChildTask.trigger({ payload: "data" });
+  },
+});
+```
+
+Alternatively, use `tasks.trigger()` or `batch.triggerAndWait()` without importing the task:
+
+```ts
+import { batch } from "@trigger.dev/sdk";
+
+export const myTask = task({
+  id: "my-task",
+  run: async (payload: string) => {
+    await batch.triggerAndWait([{ id: "my-child-task", payload: "data" }]);
+  },
+});
+```
+
 ### Rate limit exceeded
 
 <RateLimitHitUseBatchTrigger />
 
 View the [rate limits](/limits) page for more information.
 
+### Runs waiting in queue due to concurrency limits
+
+If runs are staying in the `QUEUED` state for extended periods, check your concurrency usage in the dashboard. Review how many runs are `EXECUTING` or `DEQUEUED` (these count against limits) and check if any runs are stuck in `EXECUTING` state, as they may be blocking new runs.
+
+**Solutions:**
+
+- **Increase concurrency limits** - If you're on a paid plan, increase your environment concurrency limit via the dashboard
+- **Review queue concurrency limits** - Check if individual queues have restrictive `concurrencyLimit` settings
+- **Check for stuck runs** - See if stalled runs are blocking new executions
+
 ### `Crypto is not defined`
 
 This can happen in different situations, for example when using plain strings as idempotency keys. Support for `Crypto` without a special flag was added in Node `v19.0.0`. You will have to upgrade Node - we recommend even-numbered major releases, e.g. `v20` or `v22`. Alternatively, you can switch from plain strings to the `idempotencyKeys.create` SDK function. [Read the guide](/idempotency).