Deploy Flowise v3.1.4 | Visual AI Agent Builder, Credentials Survive Redeploys

Deploy and Host Flowise on Railway

Flowise is the open-source visual builder for LLM applications: assemble chatflows, RAG pipelines and multi-agent systems by dragging nodes on a canvas, then serve each one as a REST endpoint or an embeddable chat widget. This template runs the pinned 3.1.4 release with its own PostgreSQL 17 database, and it deploys with an empty form — every value is filled in for you.

Two things it does that the other Flowise listings on this marketplace do not:

• Your provider credentials still work after a redeploy. Flowise encrypts every saved OpenAI / Anthropic / Pinecone key with an encryption.key file, and it keeps that file — along with the six auth secrets and your uploaded documents — in the data directory it resolves from $HOME. The upstream image runs as the node user, so that directory is /home/node/.flowise. Listings that mount their volume at /data or /root/.flowise are not persisting it, and nothing tells you: the credential row survives in Postgres, the UI still lists it, and the secret inside comes back empty. Measured against 3.1.4 on 2026-08-02 — same Postgres, container replaced, GET /api/v1/credentials/:id returns 200 with plainDataObj: {}, and every previously issued session cookie returns 401. This template persists the real directory and pins the encryption key to the project as well, so the same test comes back with the credential intact.
• The version is pinned. The listing holding the most recent deploys in this category ships the bare flowiseai/flowise tag. Flowise runs TypeORM migrations on boot, so a floating tag turns an ordinary redeploy into an unscheduled upgrade of your application database.

About Hosting Flowise

Flowise is a Node application that keeps state in two places, and self-hosting it goes wrong when only one of them is looked after. The database holds flows, chat history, users and the encrypted credential rows; by default that is a SQLite file on the container disk, which on a platform that replaces containers every deploy means the flows are gone. The data directory holds the encryption key those credential rows are encrypted with, the auth secrets that sign sessions, and the blob storage behind document stores and chat uploads.

This template gives Flowise a real PostgreSQL 17 database on a volume over Railway's private network, and a second volume mounted at the data directory the application actually reads, with the mount chowned to the node user before the server starts (Railway mounts volumes owned by root; upstream runs as uid 1000, so without that step the container crash-loops on its first write). Railway builds nothing — the image is prebuilt, so a deploy is a pull and a boot.

Why Deploy Flowise on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Flowise on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Flowise specifically benefits: the private network keeps Postgres off the public internet, the public HTTPS domain is what the embedded chat widget and the prediction API need anyway, and both volumes scale with the plan you move to.

Common Use Cases

• RAG chatbots over your own PDFs, docs or knowledge base, served as an API
• Internal AI tools — support triage, research assistants, document Q&A — without writing orchestration code
• Multi-agent workflows with tool calling, assembled visually instead of in code
• Prototyping a chain on the canvas and calling it from your app as a REST endpoint
• An embeddable chat widget on a marketing site, backed by your own model keys

Dependencies for Flowise Hosting

• PostgreSQL 17 — flows, chat history, users and credential rows (included, on a volume)
• A persistent volume for the data directory — encryption key, auth secrets, uploads (included)
• API keys for whichever model providers you use, added from inside the Flowise UI

Deployment Dependencies

• Flowise GitHub repository — upstream project
• Flowise documentation — nodes, deployment and API reference
• Environment variable reference
• Wrapper image source — ghcr.io/bon5co/flowise-railway, built from flowiseai/flowise:3.1.4

Environment Variables

Every one of these is filled in automatically. Nothing is required from you at deploy time.

Baked into the image, overridable from the Railway variables panel: DATABASE_TYPE=postgres, DATABASE_USER=postgres, DATABASE_NAME=postgres, DATABASE_PORT=5432, DATABASE_SSL=false, SECRETKEY_PATH=/data, BLOB_STORAGE_PATH=/data/storage, LOG_PATH=/data/logs, DISABLE_FLOWISE_TELEMETRY=true, NUMBER_OF_PROXIES=1. Flowise listens on the $PORT Railway injects, which is also what the service domain targets.

Implementation Details

Two services on Railway's private network:

Check that the app is serving:

curl https:///api/v1/ping

After deploying

1. Open the public domain and register immediately. Flowise 3.x has an account system, and the first person to register becomes the owner — after that, ensureOneOrganizationOnly rejects every further sign-up with "You can only have one organization". Until you register, that page is open to anyone who has the URL. FLOWISE_USERNAME / FLOWISE_PASSWORD no longer exist in Flowise 3.x, whatever other listings ask you to type into them.
2. Add your model provider credentials from Credentials. They are encrypted with the generated key.
3. Build a chatflow, then call it:

curl -X POST https:///api/v1/prediction/ \
  -H "Content-Type: application/json" \
  -d '{"question": "What does this document say about pricing?"}'

Persistence and upgrades

Flows, chat history and users live in PostgreSQL on a volume; the encryption key, auth secrets and uploaded documents live on the flowise service's own volume at /data. Both survive redeploys. To move to a newer Flowise, change the image tag — take a backup first, because the TypeORM migration that runs on the next boot is not reversible.

Do not set a start command on the flowise service: it replaces the image entrypoint, and the volume then stays root-owned while Flowise runs as node.