Persistent Volume Setup for FlowiseAI on Google Cloud Run

[ourdex]

Hi everyone,

I'm attempting to deploy the FlowiseAI Docker image on Google Cloud Run, primarily due to its cost-effectiveness with auto-scaling capabilities.

However, I'm encountering an issue: When auto-scaling scales the container down to zero (sleep mode) and then scales back up, I notice that PDF-related packages appear to be missing or uninstalled. I'm also experiencing other related issues with the container state not persisting properly.

My question is: How can I properly configure persistent volumes with Google Cloud Run for the FlowiseAI Docker image to maintain the installed packages and container state across scaling events?
Any guidance or best practices for handling stateful components in FlowiseAI on Cloud Run would be greatly appreciated.

Environment:

Platform: Google Cloud Run
Application: FlowiseAI (Docker image)
Issue: Package persistence during auto-scaling

Thanks in advance!

[Ganesh-403]

@ourdex
What you're seeing is actually consistent with how Cloud Run works.

Cloud Run instances are stateless. When an instance scales down to zero and a new instance is started later, any changes made to the container's local filesystem at runtime are lost. This includes downloaded files, generated assets, and anything installed or written after the container started. :contentReference[oaicite:0]{index=0}

If "PDF-related packages" appear to disappear after a restart, there are two likely scenarios:

1. The packages are being installed at runtime

If you're doing something like:

npm install ...
pip install ...
apt-get install ...

when the container starts, those changes are not persistent across new Cloud Run instances.

Instead, those dependencies should be baked into your Docker image:

FROM flowiseai/flowise:latest

RUN npm install <your-package>

Then deploy the rebuilt image.

2. You're storing Flowise data on the local filesystem

Flowise stores things like its database, API keys, logs, uploads, and blob storage on disk unless configured otherwise. On platforms with ephemeral storage, Flowise recommends mounting persistent storage and pointing the relevant paths to it. For example, on Render the documentation configures persistent paths using environment variables such as:

DATABASE_PATH
APIKEY_PATH
LOG_PATH
SECRETKEY_PATH
BLOB_STORAGE_PATH

The same principle applies on Cloud Run—you'll want those paths backed by persistent storage rather than the container filesystem. :contentReference[oaicite:1]{index=1}

About persistent volumes on Cloud Run

Cloud Run now supports volume mounts, but it's important to distinguish between:

• Ephemeral Disk → persists only for the lifetime of a single instance and is deleted when the instance is terminated or scaled to zero. It is not suitable for Flowise state. :contentReference[oaicite:2]{index=2}
• Persistent storage → use an external service (e.g. Cloud SQL for the database, Cloud Storage for uploaded files) or a supported persistent volume mechanism rather than relying on the container's filesystem.

Recommended architecture

For production deployments, a more resilient setup would be:

Cloud Run
    ├── Flowise container
    ├── Cloud SQL (database)
    └── Cloud Storage (uploads/blob storage)

This way, new Cloud Run instances remain stateless while all important Flowise data persists independently.

One question

When you mention:

"PDF-related packages appear to be missing"

are these:

• Node/npm packages that you're installing after the container starts?
• Python/system packages installed at runtime?
• Or do you actually mean uploaded PDFs or parsed document data disappear after a scale-to-zero event?

That distinction will help determine whether the issue is with the container image, Flowise's storage paths, or document persistence.

If this solves your problem, feel free to mark it as the accepted answer so others can find it easily.

[calicoagent]

This is a Cloud Run scale-to-zero problem more than a "packages missing" one -- Ganesh's answer above has the right root cause. One thing worth adding on the Flowise side specifically, since it bit me too: people often redirect the database and miss SECRETKEY_PATH. Flowise resolves its default data dir from $HOME, and the Docker image runs as the node user, so if you don't override it explicitly it's /home/node/.flowise -- not /root/.flowise, which a lot of self-hosted guides assume. If that path isn't backed by real persistent storage, encryption.key regenerates on every fresh instance, and every stored credential silently decrypts to {} -- still 200 OK, no error. Logins and API keys look intact until the first request that actually needs them.

If scale-to-zero cost is the whole point, Ganesh's Cloud SQL + Cloud Storage route is the right shape, though Flowise doesn't have a first-class arbitrary blob backend for BLOB_STORAGE_PATH -- you'd be routing it through a FUSE mount or similar, not a supported integration.

If scale-to-zero isn't a hard requirement, a platform with native persistent volumes (Railway, Fly.io, a plain VPS) sidesteps the whole class of bug -- mount a real volume at DATABASE_PATH/APIKEY_PATH/LOG_PATH/SECRETKEY_PATH/BLOB_STORAGE_PATH and it survives redeploys. Full disclosure: I maintain a Railway template for Flowise that does exactly that (correct paths, volume ownership fixed for the node user, Postgres for the rest) and get a kickback if someone deploys through it: https://railway.com/deploy/flowise-v314-or-visual-ai-agent-builder-?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory -- same env vars work on any host with a real disk if you'd rather wire it up yourself.