---
title: "Deploy n8n Cron"
description: "scheduled reports and cron workflows"
category: "Automation"
url: https://railway.com/deploy/n8n-cron
---

# Deploy n8n Cron

scheduled reports and cron workflows

**[Deploy n8n Cron on Railway](https://railway.com/template/n8n-cron)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/n8n-cron/manifest.json

- **Creator:** onepush
- **Category:** Automation

## Template content

### Postgres https://devicons.railway.app/i/postgresql.svg

- **Image:** ghcr.io/railwayapp-templates/postgres-ssl:18

### n8n

- **Image:** n8nio/n8n:2.36.8
- **Health check:** /healthz
- **Public domain:** Yes

### Redis https://cdn.sanity.io/images/sy1jschh/production/0ce0bfdcfbdbf69662b1116671f97c2dd788b655-157x157.svg

- **Image:** redis:8.2
- **Start command:** `/bin/sh -c "rm -rf $RAILWAY_VOLUME_MOUNT_PATH/lost+found/ && exec docker-entrypoint.sh redis-server --requirepass $REDIS_PASSWORD --save 60 1 --dir $RAILWAY_VOLUME_MOUNT_PATH"`

### n8n-worker

- **Image:** n8nio/n8n:2.36.8
- **Start command:** `n8n worker`
- **Health check:** /healthz

## Documentation

# Deploy and Host self hosted n8n Cron Jobs (Open-Source Cron Workflow Automation) on Railway

For a smaller instance without workers, use the [cheapest n8n without queue mode](https://railway.com/deploy/n8n).

Running cron jobs inside n8n means every scheduled run becomes a debug-able graph, not a log line. On Railway in queue mode with Redis Bull and separate workers, schedules execute without blocking the editor-but timezone mismatches and overlapping runs are the usual gotchas. This field guide covers the working setup and the tradeoffs.

Self-host n8n Cron on Railway in queue mode with an n8n editor, dedicated worker, PostgreSQL, and Redis Bull so webhooks and long workflows stay off the UI-flat infrastructure cost instead of per-task SaaS billing.

## About Hosting n8n Cron Jobs open-source software on Railway (self hosted n8n template)

n8n's Schedule Trigger starts a workflow on a cron expression. On Railway you run the editor, at least one worker, Postgres, and Redis Bull as separate services. The editor exposes port 5678 and holds workflow definitions; workers execute jobs. Queue mode requires `DB_TYPE=postgresdb`-SQLite cannot do queue mode at all. The most common failure is timezone: triggers default to UTC unless you set the node's timezone field explicitly. A nightly job set to "2am" will fire at the wrong hour for a Berlin or Chicago team, and in queue mode a delayed run can still be in Redis when today's run fires, producing duplicates unless you add an overlap guard.

## Why Deploy n8n Cron Jobs, the EasyCron alternative on Railway (Railway Free Trial)

EasyCron does one thing well: it pings a URL on a schedule and logs the HTTP status. That stops being useful when your recurring job needs to read a database, call three APIs, parse a webhook, or branch on the result. n8n's cron trigger starts the same way but can run a full pipeline. On Railway you pay a flat infrastructure fee instead of per-cron monthly charges, but you now own the queue, the database, and the encryption key.

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 n8n Cron 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.

### Railway vs Other Hosting Providers and VPS for n8n Cron Jobs self hosting

The table reflects what matters for scheduled, queue-driven workloads: first-class cron support, manual setup of Postgres/Redis, and idle worker cost. Railway keeps all services in one project with internal networking, so the queue connection string never leaves the private network.

| Provider | Cron scheduling | Queue mode setup | Idle worker cost | Best for |
|----------|----------------|------------------|------------------|----------|
| DigitalOcean | Manual via Droplet or App Platform cron | Self-managed Postgres + Redis | Paid even when idle | Teams already on DO |
| AWS | EventBridge or ECS scheduled tasks | RDS + ElastiCache required | Reserved instances can be cheap | Enterprises with AWS accounts |
| Hetzner | Bare VPS with crontab | Self-managed everything | Very cheap, you do all ops | Budget solo operators |

## Common Use Cases for hosted n8n Cron Jobs

The obvious one is the nightly digest: pull yesterday's sales from Postgres, aggregate, render an HTML email, send at 7am local. On queue mode, that runs on a worker while the editor stays responsive. Another pattern is the prune job-a daily Schedule Trigger that deletes execution history older than 30 days, either via `EXECUTIONS_DATA_PRUNE=true` on the container or a workflow calling n8n's API. Recurring cleanup of Redis Bull stuck jobs is a third: a cron workflow that checks `queue.getFailed()` and retries or removes dead jobs.

Less common but useful: rotating API tokens on a schedule, backing up the n8n database to S3 nightly, and warming up cold workflows so the first real request doesn't hit a 10-second cold start. Since the trigger accepts cron expressions like `*/15 * * * *`, you can health-check your own Railway services and post failures to Slack before a human notices.

## Dependencies for n8n Cron Jobs Docker hosted on Railway

A queue-mode n8n cron deployment has four moving parts, and each can break your schedules if misconfigured. The editor image `n8nio/n8n:2.36.8` runs the web UI and scheduler; the worker uses the same image with command `n8n worker`; Postgres stores workflow definitions and execution state; Redis Bull holds the queue. The volume `/home/node/.n8n` on the editor persists credentials and encryption keys across redeploys.

### Deployment Dependencies for Managed n8n Cron Jobs Service (Cron Automation)

The non-negotiable environment variables are `EXECUTIONS_MODE=queue` and `DB_TYPE=postgresdb`. Without the first, every workflow runs in the editor process and a long cron job blocks the UI. Without the second, you're on SQLite, which cannot run queue mode. You also need `WEBHOOK_URL` set to the editor's Railway URL so webhook-triggered workflows called from cron jobs can reach back, and `N8N_PROXY_HOPS=1` so n8n correctly detects HTTPS behind Railway's proxy. The `N8N_ENCRYPTION_KEY` is the one value you must never lose: it encrypts all saved credentials, and rotating it makes every stored API key unreadable.

### Implementation Details for n8n Cron Jobs (Using n8n official docker image)

The editor service runs `n8nio/n8n:2.36.8` on port 5678 with volume at `/home/node/.n8n`. The worker service uses the same image but overrides the command to `n8n worker`. Both share the same Postgres connection string and Redis Bull queue URL. When a Schedule Trigger fires, the editor enqueues the workflow into Redis Bull; any available worker picks it up, executes nodes, and writes results back to Postgres. Scale horizontally by adding worker replicas-Bull distributes jobs round-robin. Set `EXECUTIONS_DATA_PRUNE=true` on the editor so old executions don't bloat Postgres, and never lose `N8N_ENCRYPTION_KEY`.

## How does n8n Cron Jobs compare against other Cron and Scheduled Job platforms

Most cron platforms stop at "fire an HTTP request at time T." n8n starts there and then gives you a graph of nodes for retries, branching, data transformation, and human-in-the-loop steps. The cost is that you now run infrastructure. EasyCron and cron-job.org are simpler to operate but can't handle a workflow that queries a database and conditionally calls a webhook. Zapier Schedule charges per task and locks you into a linear model. GitHub Actions cron is free for public repos but can be delayed up to 30 minutes.

### n8n Cron Jobs vs EasyCron (EasyCron Alternative)

EasyCron wins on setup time: paste a URL, pick a schedule, done in 60 seconds. It loses when your recurring job needs to read from Postgres, transform JSON, or retry with backoff. EasyCron charges per cron job per month; n8n on Railway costs a flat infrastructure fee regardless of how many Schedule Trigger workflows you run. Honest tradeoff: EasyCron is more reliable for simple pings because there's no queue to monitor; n8n is better when the "cron job" is actually a multi-step pipeline.

### n8n Cron Jobs vs cron-job.org (cron-job.org Alternative)

cron-job.org is free for basic HTTP cron jobs and has a clean failure monitoring UI. Its limitation is the same as EasyCron's: it can only trigger URLs, not execute code. If your nightly job needs to read a CSV from S3, transform it, and upsert rows into Postgres, cron-job.org can only call a separate endpoint you've already built. n8n collapses all of that into one workflow. On the flip side, cron-job.org requires zero infrastructure, so for a simple uptime ping it's hard to justify a full Railway deployment.

### n8n Cron Jobs vs Zapier Schedule (Zapier Schedule Alternative)

Zapier Schedule is closest in spirit: it triggers a zap on a recurring interval and runs a linear sequence of actions. The difference is cost and flexibility. Zapier charges per task, so a nightly workflow with five steps costs five tasks per run; at 30 days that's 150 tasks, and you'll hit the free tier quickly. n8n Community Edition has no per-execution fee. Zapier also can't branch into parallel paths or loop over a dataset the way n8n can. Zapier wins on thousands of prebuilt integrations, but for cron-driven data pipelines, n8n's graph model and self-hosted cost are hard to beat.

### n8n Cron Jobs vs GitHub Actions cron (GitHub Actions cron Alternative)

GitHub Actions cron is great if your scheduled job is already a script in a repo and you want git-based versioning. It's free for public repos and has a generous private tier. The catch: cron schedules can be delayed up to 30 minutes during load, and there's no built-in retry with backoff for a failed scheduled run. n8n gives precise second-level scheduling with cron expressions, a visual editor for non-developers, and a queue that retries failed executions automatically. GitHub Actions wins for code deploys or test suites; n8n wins for business workflows a non-engineer can modify.

## How to use n8n Cron Jobs (the OSS Cron Automation)?

Start by creating a new workflow in the editor and adding a Schedule Trigger node. Set the trigger to "Custom (Cron)" and enter an expression like `0 7 * * *` for 7am daily. Then set the timezone explicitly-the trigger's Timezone field overrides the default UTC, and this is the single most important setting for cron correctness. Connect the trigger to whatever nodes your job needs: Postgres query, HTTP request, Slack message, or email. Activate the workflow; the editor enqueues it into Redis Bull, and a worker picks it up at the scheduled time.

For overlapping-run protection, add a guard at the start: query Postgres for the most recent execution of this workflow and stop if it's still running.

## Similar templates

- [N8N Main + Worker](https://railway.com/deploy/n8n-main-worker) — Deploy and Host N8N with Inactive worker.
- [Evolution API with n8n](https://railway.com/deploy/evolution-api-with-n8n) — Automate WhatsApp workflows with Evolution API, n8n, and Postgres.
- [Postgres Backup](https://railway.com/deploy/postgres-s3-backups) — Cron-based PostgreSQL backup to bucket storage

Open this page in a browser: https://railway.com/deploy/n8n-cron