Bubble’s 30-Second Limit Is Painful. Would You Use This Instead?

Questions
1

I’m building a tool for Bubble developers to solve one specific problem: Bubble Server-Side Actions time out after about 30 seconds.

The idea is that Bubble can trigger a workflow on our infrastructure, get a run_id back immediately, and let the job continue running for minutes if needed.

The workflow builder would support both visual actions and arbitrary Node.js code, for example:

Bubble Trigger
→ Download Files
→ Merge PDFs
→ Run custom Node.js
→ Convert Image
→ Return Result

It would also support reusable Node.js functions, npm packages, secrets, PDF/image utilities, retries, and detailed run history.

The part I also want to include is real-time status for the frontend.

So after Bubble starts a workflow, the frontend could know things like:

Queued
→ Running
→ Merge PDFs — 45%
→ Run Code
→ Completed

and receive live:

progress
current step
logs
success/failure
final output

This could power progress bars, loading states, live logs, and “workflow completed” events directly in the Bubble UI, while a webhook callback would still be available for backend workflows.

The goal is basically:

Run backend workflows beyond Bubble’s 30-second limit, while still making the whole thing feel native to Bubble.

I’m curious about two things:

  1. Would you actually use something like this?
  2. What are you currently doing when a Bubble server-side job takes longer than 30 seconds?

I’d especially love to hear real use cases — PDFs, AI jobs, image/video processing, bulk data operations, large imports/exports, long API calls, etc.

2

Hmmm why not just use polling?

3

@philipp.laengle107 What do you mean by polling here, polling the status of a job running on an external service, or polling Bubble itself?

If you mean an external async API, then yes, polling can work.

The problem I’m trying to solve is also cases where the actual work is happening inside a Bubble server-side action, like custom Node.js, PDF/image processing, loops, file handling, or something like converting a webpage to PDF.

In those cases there may be nothing external to poll. Bubble is the thing executing the work, and if that processing takes longer than ~30 seconds, Bubble terminates it.

So polling helps when another service is already doing the long-running job, but it doesn’t solve the underlying timeout when Bubble itself is doing the work.

5

i get the problem, but imo a 30s timeout doesn’t automatically justify adding a second workflow engine outside Bubble.

for most long-running jobs, you can break the work into smaller backend workflows, queue them, and track the progress in Bubble. that keeps the auth, data, retries and state in one place instead of adding another runtime and sync layer.

this makes more sense for genuinely compute-heavy tasks like video or PDF processing, or anything Bubble shouldn’t be handling in the first place. for regular backend workflows, though, it feels like a lot of extra infrastructure just to work around a timeout.

6

The server side actions on my app don’t time-out until around the two minute mark. I haven’t experienced any issues at 30 seconds. For reference, the actions I’m referring to make API calls to an external service. In the worst case, they’re waiting for approximately 2 minutes.