Skip to content

docs: added v3 to v4 migreation note about IP change #3086

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
samejr merged 2 commits into from
Feb 18, 2026
Merged

docs: added v3 to v4 migreation note about IP change #3086

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
59f4ad6
added v3 to v4 migreation note about IP change
isshaddad Feb 18, 2026
27e265c
added link to static ips
isshaddad Feb 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions docs/migrating-from-v3.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,10 @@ Note that between steps 4 and 5, runs triggered with the v4 package will continu
concurrency will return to normal.
</Warning>

<Note>
When migrating from v3 to v4, our infrastructure IPs may change. If you use IP allowlisting (e.g. for databases or APIs), [update your allowlists](https://trigger.dev/changelog/static-ips) with the current static IPs before or immediately after switching to v4 to avoid connectivity issues or downtime.
</Note>
Comment on lines 51 to 53
Copy link
Contributor

@coderabbitai coderabbitai bot Feb 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for any existing IP range documentation in the docs directory
rg -i "ip.*(range|allowlist|whitelist|cidr|egress|address)" docs/ --type=md -A 3 -B 1 2>/dev/null || echo "No matches found with regex"

# Also search for files that might contain IP information
find docs/ -type f \( -name "*.md" -o -name "*.mdx" \) | xargs grep -l -i "ip\|allowlist\|whitelist\|cidr\|egress" 2>/dev/null || echo "No files found"

Repository: triggerdotdev/trigger.dev

Length of output: 7832

🏁 Script executed:

#!/bin/bash
# Look at the actual migrating-from-v3.mdx file
echo "=== Content around lines 51-53 in migrating-from-v3.mdx ==="
sed -n '40,65p' docs/migrating-from-v3.mdx

echo ""
echo "=== Search for egress IP or infrastructure IP mentions ==="
rg -i "egress|infrastructure.*ip|ip.*allow" docs/ -A 2 -B 1 | head -50

echo ""
echo "=== Search in deployment and troubleshooting docs ==="
rg -i "allowlist|whitelist" docs/deployment/ docs/troubleshooting.mdx 2>/dev/null | head -20

Repository: triggerdotdev/trigger.dev

Length of output: 3509

🏁 Script executed:

#!/bin/bash
# Final check: search for any IP-related configuration or documentation that might be in a different format
rg -i "v4.*ip|infrastructure" docs/ --type=md --type-list | head -20

# Also check if there are any external links or references to IP configuration
rg "ip.*address|allowlist.*ip" docs/migrating-from-v3.mdx -A 5 -B 5

Repository: triggerdotdev/trigger.dev

Length of output: 458

🏁 Script executed:

#!/bin/bash
# Search for any IP-related configuration or documentation 
rg -i "v4.*ip|infrastructure" docs/ --type=md | head -20

# Check the migrating-from-v3.mdx file specifically for IP or allowlist references
echo ""
echo "=== IP/allowlist references in migrating-from-v3.mdx ==="
rg "ip|allowlist" docs/migrating-from-v3.mdx -i -A 3 -B 3

Repository: triggerdotdev/trigger.dev

Length of output: 2608

Note is not actionable without the actual IP addresses or a link to them

The note warns users to update IP allowlists but provides no way to find the actual IPs. A reader mid-migration is left without the information needed to act. Two additional clarity issues:

  1. "before or immediately after" is contradictory. The zero-downtime approach is to add the new IPs before step 5 while retaining the old ones, then remove the old IPs only after v3 runs have fully drained. Describing both options as equivalent is misleading.
  2. No step anchor: The note doesn't indicate which migration step triggers the IP change. Based on the context, it's most likely step 5 (deploying to v4 infrastructure); tying the advice there would make it concrete.
📝 Suggested revision 
 <Note>
-  When migrating from v3 to v4, our infrastructure IPs may change. If you use IP allowlisting (e.g. for databases or APIs), update your allowlists before or immediately after switching to v4 to avoid connectivity issues or downtime.
+  When migrating from v3 to v4, our infrastructure IPs may change. If you use IP allowlisting
+  (e.g. for databases or APIs), add the [new IP ranges](/YOUR-IP-ALLOWLIST-PAGE) to your allowlist
+  **before step 5** while keeping the existing IPs. You can safely remove the old IPs once all v3
+  runs have finished draining to avoid any connectivity downtime.
 </Note>

Replace /YOUR-IP-ALLOWLIST-PAGE with the actual docs page that lists the v4 egress IPs.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
<Note>
When migrating from v3 to v4, our infrastructure IPs may change. If you use IP allowlisting (e.g. for databases or APIs), update your allowlists before or immediately after switching to v4 to avoid connectivity issues or downtime.
</Note>
<Note>
When migrating from v3 to v4, our infrastructure IPs may change. If you use IP allowlisting
(e.g. for databases or APIs), add the [new IP ranges](/YOUR-IP-ALLOWLIST-PAGE) to your allowlist
**before step 5** while keeping the existing IPs. You can safely remove the old IPs once all v3
runs have finished draining to avoid any connectivity downtime.
</Note>
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@docs/migrating-from-v3.mdx` around lines 51 - 53, Update the Note in
migrating-from-v3.mdx to point readers to the actual v4 egress IPs (replace
/YOUR-IP-ALLOWLIST-PAGE with the real docs page or include the IP list), clarify
the timing by recommending the zero-downtime approach (add v4 IPs to your
allowlist before performing step 5 and keep v3 IPs until v3 runs fully drain,
then remove old IPs), and add a clear anchor referencing "step 5 (deploying to
v4 infrastructure)" so users know exactly when the IP change occurs.


## Migrate using AI

Use the prompt in the accordion below to help you migrate your v3 tasks to v4. The prompt gives good results when using Claude 4 Sonnet. You’ll need a relatively large token limit.
Expand Down