Deploy and Host Flowise + n8n on Railway

This template deploys a complete self-hosted AI automation stack: Flowise for building AI agents and LLM workflows visually, and n8n for triggers, webhooks, and 400+ integrations — connected over a private network with a shared PostgreSQL backend. n8n handles the "when this happens, do that" automation; Flowise handles the AI reasoning. Together they build AI-powered pipelines no single tool covers alone, and this template pins both encryption keys so your saved credentials survive redeploys.

What This Template Deploys

n8n is public-facing to receive webhooks and triggers; Flowise stays on Railway's private network and is called by n8n internally, which keeps your AI agent layer off the public internet. Persistent volumes back each service.

About Hosting

This stack has two services, each with an encryption key that most Flowise+n8n templates leave unpinned — and that's exactly what breaks them.

Both encryption keys must be set and kept stable. Flowise encrypts your stored model-provider credentials (OpenAI, Anthropic, Pinecone keys) with FLOWISE_SECRET_KEY, and n8n does the same with N8N_ENCRYPTION_KEY. If either isn't set, the service generates a random key on boot — and Flowise's own documentation warns that when that key regenerates on a later deploy, you get Credentials could not be decrypted and every saved credential is lost. This template pins both keys at deploy so a redeploy never invalidates your AI provider credentials. It's the single most common way the other combo templates fail.

Both services need persistent volumes. Flowise stores chatflows, credentials, and config in /root/.flowise; n8n stores workflows and its key material in /home/node/.n8n. Without volumes, a redeploy wipes both. Both are mounted here, and both point their data at the shared PostgreSQL for durable app state.

The public/private split is deliberate. n8n is exposed so external services can trigger workflows via webhook; Flowise is kept private and reached only through Railway's internal network, so your AI agent endpoints aren't open to the internet. n8n calls Flowise over the private domain.

Both are CPU services that call external LLM APIs — no GPU needed. Budget a bit more RAM than a single-service template, since you're running two Node apps plus Postgres.

Typical cost: ~$10–15/month on Railway across the three services, plus your LLM provider usage.

How It Compares

n8n alone has AI nodes but not Flowise's depth for multi-agent flows and RAG; Flowise alone can't trigger on external events or integrate with hundreds of apps. Zapier bills per task and keeps your data. This stack pairs the best automation engine with the best visual AI builder, self-hosted and redeploy-safe.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — n8n, Flowise, and PostgreSQL build automatically (~4 minutes)
2. Confirm FLOWISE_SECRET_KEY and N8N_ENCRYPTION_KEY are set, and save them externally
3. Set FLOWISE_USERNAME/FLOWISE_PASSWORD and n8n's owner account credentials
4. Confirm volumes are mounted at /root/.flowise and /home/node/.n8n
5. Open n8n's public URL to build workflows; reach Flowise privately from n8n via its internal address

Add your LLM provider keys in Flowise, then call Flowise flows from n8n workflows.

Common Use Cases

• AI-powered automation pipelines — n8n triggers on an event, calls a Flowise agent for reasoning, then acts on the result
• Customer support automation — route inbound messages through n8n, answer with a Flowise RAG agent over your docs
• Content and lead workflows — n8n orchestrates the pipeline; Flowise agents handle research, drafting, and analysis
• Scheduled AI jobs — n8n's cron triggers Flowise agents for recurring analysis, summaries, or reports
• Multi-agent orchestration — Flowise coordinates multiple agents; n8n wires them into your live systems

Configuration

Both encryption keys must stay stable. FLOWISE_SECRET_KEY and N8N_ENCRYPTION_KEY encrypt each service's saved credentials. If either regenerates on a redeploy, that service's stored API keys become undecryptable and must be re-entered. This template pins both — back them up.

Volumes and the public/private split. Flowise persists to /root/.flowise, n8n to /home/node/.n8n. Keep Flowise private and reach it from n8n over Railway's internal network; expose only n8n publicly for webhooks.

Dependencies for Flowise + n8n Hosting

• Railway account — expect ~$10–15/month across the three services
• Persistent volumes for Flowise and n8n (included)
• LLM provider API keys (OpenAI, Anthropic, etc.) added inside Flowise
• Optional: SMTP for n8n email notifications

Deployment Dependencies

• Flowise GitHub Repository
• n8n GitHub Repository
• Flowise Environment Variables
• Railway Private Networking

Implementation Details

The template runs flowiseai/flowise (port 3000) and n8nio/n8n (port 5678) against a shared Railway PostgreSQL service, both configured with postgresdb as the database type so workflow and chatflow state persists in Postgres rather than SQLite. n8n is exposed publicly to receive webhook and trigger traffic; Flowise is kept on the private network and called by n8n through its internal Railway domain, keeping AI agent endpoints off the public internet.

FLOWISE_SECRET_KEY and N8N_ENCRYPTION_KEY are set explicitly at deploy. This is the reliability difference: both tools auto-generate a random key when none is provided, and both lose access to their stored provider credentials if that key changes on a later deploy — a documented Flowise failure mode (Credentials could not be decrypted). Pinning the keys makes redeploys safe.

Persistent volumes at /root/.flowise and /home/node/.n8n hold each service's local files and key material. Both services run on CPU and delegate model inference to external LLM APIs, so no GPU is required.

Frequently Asked Questions

Why deploy both together instead of separately? They're complementary. n8n handles triggers, scheduling, and 400+ app integrations; Flowise builds the AI agents and RAG flows. Together, n8n can trigger a Flowise agent and act on its output — an AI automation pipeline neither does alone.

Why does the template pin both encryption keys? Because Flowise and n8n each encrypt stored credentials with a key that, if it regenerates on redeploy, makes those credentials undecryptable. Flowise's docs call this out directly. Pinning both keys is what keeps your saved provider credentials working across redeploys — the main flaw in other combo templates.

Why is Flowise private and n8n public? n8n needs a public URL for webhooks and triggers. Flowise's AI endpoints don't need public exposure and are safer private, reached by n8n over Railway's internal network. This is the recommended security posture.

Do my workflows and credentials survive a redeploy? Yes. State lives in shared PostgreSQL, and each service's files on its volume, with encryption keys pinned. All of it persists across redeploys.

Do I need a GPU? No. Both are CPU services that call external LLM APIs (OpenAI, Anthropic, etc.). Add your provider keys inside Flowise.

Can I scale this? Vertically, yes — raise CPU and RAM. Both support queue/worker modes for heavier scale, which is a larger redesign beyond this single-instance stack.

Why Deploy Flowise + n8n 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 + n8n on Railway you get a complete AI automation stack with the reliability pitfalls solved — both encryption keys pinned so credentials survive redeploys, persistent volumes, a shared Postgres backend, and a public/private split that keeps your AI layer off the internet. Build AI-powered automation pipelines, with everything on infrastructure you own.