Pipedream Workflows Is Shutting Down: Keep Your Static IP When You Migrate

Pipedream Workflows closes March 31, 2027. Export every project, move to a proxy-capable service, and keep your existing QuotaGuard IPs.

Pipedream has announced that Workflows and String will shut down on March 31, 2027. Existing workflows remain operational until that date, but the product is in maintenance mode and no longer accepts new signups or subscriptions.

If a Pipedream workflow uses QuotaGuard to reach an IP-allowlisted API, database, SFTP server, payment provider, or customer network, the workflow platform is only one part of the connection. The two addresses approved by the destination belong to the QuotaGuard subscription.

That gives you a valuable migration option:

Old path
Pipedream Workflows
  -> QuotaGuard static IP pair
  -> protected destination

New path
Replacement automation service
  -> the same QuotaGuard static IP pair
  -> the same protected destination

Choose a replacement service that can route the required connection through an authenticated proxy, move the QuotaGuard connection securely, and the destination can continue seeing the same approved addresses. You avoid reopening firewall tickets simply because the workflow engine changed.

Pipedream Connect Is Not Shutting Down

The announcement applies to Pipedream Workflows and String. Pipedream states that Connect, its API, MCP Servers, and API Proxy remain supported and actively developed.

Confirm which Pipedream product you use before planning a migration:

• Pipedream Workflows: Shuts down March 31, 2027.
• Pipedream String: Shuts down March 31, 2027.
• Pipedream Connect: Not affected by the announced shutdown.

Read the official Pipedream shutdown notice before changing production systems.

Do Not Wait Until the Shutdown Date to Export

Pipedream says existing Workflows data will be permanently deleted by April 30, 2027. That deletion includes credentials and OAuth tokens for connected accounts. Pipedream Connect settings and credentials are not affected.

Pipedream provides an export tool, but it is a rebuild reference rather than a portable backup that recreates the production service automatically.

The export runs one project at a time and produces a ZIP archive containing a manifest and a JSON file for each exported workflow. The files describe:

• Workflow names, descriptions, settings, and active state.
• Triggers and their configuration.
• Steps, component versions, code steps, and configured properties.
• Control-flow branches such as conditional and switch paths.

According to Pipedream's export documentation, a single export is limited to 500 workflows or 256 MB of workflow content. Inspect manifest.json for truncated, skipped_never_deployed, and skipped_export_limit entries so nothing silently disappears from the migration plan.

The Export Does Not Contain Your Production Secrets or State

Pipedream deliberately removes sensitive and runtime-managed information. The export does not include:

• Secret property values.
• Connected-account credentials or OAuth tokens.
• Environment-variable values.
• Event history.
• Data-store contents.
• File Store files.
• Source code for private multi-file components.

The workflow JSON preserves the names of many omitted fields, and the manifest records warnings about values that must be supplied again. Build a separate migration inventory for every credential, environment variable, file, datastore, callback URL, and private component the new workflow will need.

The QuotaGuard proxy credential belongs in that inventory. Do not paste the credential into workflow descriptions or exported documentation. Retrieve the current connection URL from a secure secret store or the QuotaGuard dashboard when configuring the replacement.

Inventory the Network Requirement Before Choosing a Replacement

Do not choose the replacement platform solely by comparing trigger and action catalogs. First identify every connection that depends on Pipedream's current runtime or QuotaGuard route.

Connection	What the replacement must support	Static-IP question
HTTP or HTTPS API	Authenticated HTTP proxy in the request node or its HTTP client	Can this exact request use the QuotaGuard URL?
OAuth token request	Proxy control for the token client as well as the API client	Will refreshes use the approved source identity?
SFTP, FTPS, SMTP, IMAP, or database	Authenticated SOCKS5, QGTunnel, a TCP-capable worker, or suitable native egress	Does the platform expose the raw connection path?
Inbound webhook	A new public callback endpoint and verification controls	Does the sender require a stable destination address?
Customer or vendor firewall	A source address the administrator will approve	Can the current QuotaGuard pair remain in place?

An HTTP proxy field in one workflow node does not automatically route SFTP, a native database connector, or every OAuth exchange on the platform. Match the replacement to the protocol and the component that actually opens the connection.

Test the Replacement Platform's Proxy Path Before Rebuilding Everything

The key qualification question is:

Can the replacement service route this specific customer-controlled connection through an authenticated QuotaGuard proxy?

Several common patterns can work:

• Node-level proxy setting: The workflow's HTTP request component accepts a credentialed proxy URL.
• Custom code: A code step can configure the HTTP client with QuotaGuard explicitly.
• Process environment variables: A self-hosted runtime accepts HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, and the selected client honors them.
• Customer-controlled worker: The automation triggers a service where you can run QGTunnel or a SOCKS5-capable client.
• Native static egress: The replacement offers its own supported route and you choose to replace the existing allowlist after comparing scope and ownership.

Do not assume compatibility from a platform-level feature list. Test the exact node, SDK, connector, or protocol used by the production workflow.

Examples of Replacement-Platform Network Controls

The following examples show why the individual connection matters:

n8n HTTP Request

n8n documents a Proxy option on its HTTP Request node. The field accepts an HTTP proxy and takes precedence over global HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY settings. That makes it a plausible path for selectively migrating HTTP and HTTPS workflow steps through QuotaGuard.

The setting does not prove that an n8n SFTP node, database node, or app-specific node uses the same proxy. Review each connection separately. See the n8n HTTP Request proxy documentation.

Make HTTP v4

Make documents configurable proxy settings in version 4 of its HTTP app. That can provide a route for compatible HTTP and HTTPS requests. It does not establish proxy support for every Make application module or non-HTTP protocol.

Confirm the exact module before selecting Make solely for this requirement. See Make's HTTP v4 announcement.

Zapier

Zapier publishes native static ranges for a defined list of supported apps on eligible paid plans. The current ranges are two /28 blocks, representing 32 total addresses across two regions. Static routing is not available for every public app.

If the destination accepts Zapier's ranges and the required app is supported, the native option may be sufficient. If the destination wants a much smaller portable identity, or the workflow needs a connection outside Zapier's supported list, validate a customer-controlled route before committing to the migration. See Zapier's current static-IP documentation.

These are examples, not a recommendation to choose one service for every Pipedream workload. Trigger support, credentials, code execution, proxy scope, protocol, cost, and operational control must all match the workflow being rebuilt.

Keep the Existing QuotaGuard IPs Instead of Reopening Every Firewall

The static IP pair is attached to the QuotaGuard subscription, not the Pipedream workflow. Moving the proxy credential to a compatible replacement does not require changing those two addresses.

This matters when the pair has already been approved by:

• A customer's security or network team.
• A banking or payment provider.
• A database firewall.
• An SFTP or trading partner.
• An enterprise API owner.

Approving a new source address can require a ticket, security review, maintenance window, customer confirmation, and production retest. Preserving the QuotaGuard pair separates the workflow migration from that firewall process.

Do not cancel or recreate the QuotaGuard subscription during the move. Retrieve its current connection URL securely, configure the replacement, and confirm the existing pair in the QuotaGuard dashboard.

Run the Old and New Workflows in Parallel

A safe cutover proves more than basic connectivity. It confirms that the replacement preserves the workflow's behavior and network identity.

1. Export every Pipedream project and inspect each manifest.
2. Record secrets, connected accounts, environment variables, data stores, files, schedules, and private components outside the export.
3. Rebuild one representative workflow on the replacement platform.
4. Configure only the protected connection to use QuotaGuard.
5. Call https://ip.quotaguard.com through that same node or client and confirm that it returns one of the existing subscription addresses.
6. Run the real destination request and confirm that its firewall or connection logs show the same approved pair.
7. Compare payloads, retries, error handling, schedules, side effects, and destination records between old and new workflows.
8. Move production triggers only after the replacement behaves correctly.

Be careful with workflows that create payments, orders, messages, tickets, or records. A parallel test must not duplicate production side effects. Use idempotency keys, test endpoints, or read-only operations where the destination supports them.

Rotate Secrets After the Migration

Pipedream's export excludes credentials, which forces you to reconnect accounts on the replacement. Use that as an opportunity to clean up the security boundary.

• Create replacement-platform secrets rather than embedding credentials in workflow code.
• Rotate API keys and OAuth credentials when practical.
• Rotate the QuotaGuard subscription password after the final cutover if it was exposed to people or systems that no longer need it.
• Revoke old callback URLs and application credentials.
• Remove obsolete Pipedream environment variables and connected accounts.
• Download required File Store data before Pipedream deletes it.

Do not rotate the QuotaGuard subscription by deleting and recreating it if preserving the IP pair is the goal. Use supported credential rotation on the existing subscription or contact QuotaGuard engineering for help with the transition.

QuotaGuard Static or Shield for the Replacement?

QuotaGuard Static is the normal starting point for standard API allowlisting. Outbound HTTPS uses a blind CONNECT tunnel, and QuotaGuard does not decrypt the HTTPS application payload. Static uses the standard HTTP proxy protocol on the customer-to-proxy hop.

QuotaGuard Shield adds TLS protection to that hop. Choose Shield when the workflow handles sensitive data under a security policy or approved compliance architecture that requires the additional protection and the replacement runtime supports the Shield connection method.

QuotaGuard Static starts at $19 per month and Shield starts at $29 per month. Standard plans provide stable shared IP pairs. Enterprise plans provide customer-only addresses and dedicated proxy resources, starting at $219 for Static and $269 for Shield.

Why Keep QuotaGuard Instead of Using the Replacement's Native IPs?

A native static-egress feature may be the right answer when it covers the exact connector and plan you are adopting. Compare more than the advertised price.

Keeping the existing QuotaGuard route provides:

• Allowlist continuity: The destination keeps the addresses it already approved.
• Portability: The network identity is not tied to one automation vendor.
• Selective routing: Only connections that need the static identity use it.
• A small address set: Two addresses instead of a broad platform range.
• Managed availability: Load balancing, failover, monitoring, capacity, and maintenance remain QuotaGuard's responsibility.
• Engineering support: You have a team to help distinguish a proxy problem from a workflow or destination problem.

The real benefit is not avoiding a small price difference. It is avoiding another firewall project now and another one the next time the workflow platform changes.

Move the Workflow Without Moving Its Network Identity

Pipedream Workflows customers have until March 31, 2027 to migrate, but the export is incomplete by design and the replacement's network behavior must be proven before cutover.

Export each project, inventory everything the ZIP omits, qualify the replacement against the real connection protocol, and test one protected request through the existing QuotaGuard subscription. When that path works, the new service can inherit the same two static addresses already approved by customers and vendors.

Keep your QuotaGuard static IPs while you move away from Pipedream Workflows. If you need help evaluating the replacement service or preserving an existing pair during cutover, contact QuotaGuard engineering.

Frequently Asked Questions

When is Pipedream Workflows shutting down?

Pipedream says Workflows and String will shut down on March 31, 2027. Existing Workflows data will be permanently deleted by April 30, 2027.

Is Pipedream Connect shutting down too?

No. Pipedream states that Connect, its API, MCP Servers, and API Proxy are not affected by the Workflows and String shutdown.

Can I import the Pipedream export directly into another platform?

Treat it as a structured rebuild reference, not a complete portable deployment. It contains workflow structure and configuration but omits credentials, environment-variable values, event history, data stores, File Store files, and private multi-file component source.

Will my QuotaGuard IPs change when I leave Pipedream?

No, if you retain the existing QuotaGuard subscription. The static pair belongs to that subscription rather than Pipedream. Configure the compatible replacement to use the existing connection URL and verify the route before cutover.

How do I know whether the new service supports QuotaGuard?

Identify the component that opens the protected connection and confirm that it supports an authenticated HTTP proxy, SOCKS5, QGTunnel, or a customer-controlled worker suitable for the protocol. Then test that exact path against https://ip.quotaguard.com.

Can an HTTP proxy field route SFTP or database connections?

Not automatically. SFTP, SMTP, IMAP, and native database protocols require a compatible SOCKS5 or TCP route such as QGTunnel, a suitable customer-controlled worker, or a verified native platform feature.

Should I use the replacement platform's native static IP instead?

Use it when it covers the exact connection, plan, region, and security requirements and you are willing to update the destination's allowlist. Keep QuotaGuard when preserving the approved pair, selective routing, portability, managed operations, or dedicated infrastructure matters.

Should the migrated workflow use QuotaGuard Static or Shield?

Static is the normal choice for standard HTTPS API allowlisting. Shield adds TLS protection to the customer-to-proxy hop for approved security and compliance architectures. Confirm that the replacement client supports the chosen connection method.