Deploy Huginn
Build agents that watch websites and alert you when they change
Just deployed
/var/lib/postgresql/data
huginn-web
Just deployed
huginn-worker
Just deployed
mailpit
Just deployed
/data
huginn-scheduler
Just deployed
/mnt/scheduler
Deploy and Host Huginn on Railway
Huginn is an open-source system for building agents that watch the web and act on your behalf. Each agent does one small job — scrape a page, read a feed, call an API, listen on a webhook — and emits events that flow into other agents that filter, reformat, combine or deliver them. Chained together they replace the recurring "check this, tell me when it changes" work people otherwise pay IFTTT, Zapier or Make to do, except the data never leaves infrastructure you control. It is MIT licensed and ships around seventy agent types out of the box.
This template runs Huginn the way its own Procfile recommends for production: three processes rather than one box doing everything. Deploy Huginn on Railway and you get a web service running Puma for the UI and incoming webhooks, a scheduler that decides which agents are due, a worker that runs them, a managed PostgreSQL database holding agents, events and the job queue, and a Mailpit inbox capturing what Huginn emails. Only the web UI and the inbox get public URLs.

Getting Started with Huginn on Railway
Set SEED_USERNAME, SEED_PASSWORD and SEED_EMAIL before deploying — they become your administrator account and are read once, on the web service's first boot. Set INVITATION_CODE to something only you know: the signup page is reachable by anyone but demands that code, so it is what keeps strangers out. Open the web URL and sign in. Huginn seeds seven example agents, so click Agents: a Website Agent scraping the current XKCD comic, an Event Formatting Agent turning it into HTML, a Weather Agent, a Trigger Agent and two Email Digest Agents.
To confirm everything is wired up, open the XKCD Source agent, change its schedule from Every 1d to Every 1m and save. Within a minute the scheduler queues it, the worker runs it, and the Events tab fills with the scraped payload — one round trip exercising the scheduler, the worker, the database and outbound HTTP. Change the schedule back afterwards. Then click View diagram for the agent graph, and open the Mailpit URL to read what your agents have emailed.




About Hosting Huginn
Huginn is closer to a programmable monitoring system than a drag-and-drop workflow builder. You configure agents with JSON options and Liquid templates rather than by wiring boxes on a canvas — slower to start with, far more precise once you know what you want. Teams self-host it when what is being watched is sensitive, or when a per-task SaaS bill stops making sense.
Key capabilities:
- Around seventy agent types: Website, RSS, HTTP Status, Post, Webhook, Email, Trigger, Event Formatting, JavaScript, Liquid, De-duplication, Peak Detector
- CSS or XPath extraction from HTML, XML and JSON, with Liquid templating over every value
- Per-agent schedules from every minute to daily, cron scheduling, and incoming webhooks
- Scenarios that group agents and export as JSON, so a setup can be version-controlled
- Event propagation between agents, with a visual diagram of the whole graph
The web service serves the UI and receives webhooks, and is the only one that runs migrations. The scheduler decides which agents are due; the worker does the fetching, parsing and sending. PostgreSQL stores everything including the job queue — Huginn uses Delayed::Job, so no Redis is needed. Mailpit accepts SMTP privately and holds what Huginn sends.
Why Deploy Huginn on Railway
Railway removes the setup work that makes Huginn hard to self-host:
- PostgreSQL is provisioned, connected and backed by a volume automatically
- Web, scheduler and worker are already split and wired together
- The worker scales horizontally from the dashboard when agents get busy
- A capture-only mail inbox ships with it, so email agents work immediately
- HTTPS, health checks and private networking are configured for you
Common Use Cases
- Change monitoring — watch a pricing page, job board or status page and get emailed when the extracted value differs from last time
- Feed and API plumbing — merge RSS feeds, filter against keywords, reformat entries and forward them to Slack or a webhook
- Scheduled API glue — poll an internal API, detect a threshold crossing with a Trigger or Peak Detector agent, and POST the result onward
- Personal dashboards — collect weather, transit and inbox signals into one morning digest
Dependencies for Huginn
- Huginn — built from gridalpha/huginn-railway, a thin layer over the official
ghcr.io/huginn/huginn-single-processimage that bakes in the PostgreSQL adapter and adds a role-selecting entrypoint. Run as web, scheduler and worker. - PostgreSQL — Railway's managed Postgres, storing agents, events, scenarios, credentials and the Delayed::Job queue.
- Mailpit —
axllent/mailpit:latest, capturing outgoing SMTP so email agents and password resets work without an external provider.
Environment Variables Reference
| Variable | Purpose |
|---|---|
HUGINN_ROLE | web, scheduler or worker — picks the process |
DATABASE_URL | Overrides every discrete DATABASE_* setting |
APP_SECRET_TOKEN | Rails signing key; same on all three services, stable forever |
DOMAIN | Hostname used in emails and in webhook URLs |
INVITATION_CODE | Code required to register an account |
SEED_USERNAME / SEED_PASSWORD | First administrator, created on first boot only |
SMTP_SERVER / SMTP_PORT | Where Huginn sends mail; Mailpit by default |
ENABLE_INSECURE_AGENTS | Leave false unless every user is trusted with a shell |
Deployment Dependencies
- Upstream: github.com/huginn/huginn, with agent docs in its wiki
- Official images:
ghcr.io/huginn/huginn-single-processandhuginn/huginn - Runtime: Rails 8 on Ruby 4, Puma, Delayed::Job, PostgreSQL
Hardware Requirements for Self-Hosting Huginn
| Resource | Minimum | Recommended |
|---|---|---|
| CPU | 1 vCPU shared | 2 vCPU |
| RAM | 512 MB per Huginn service | 1 GB each |
| Storage | 1 GB for PostgreSQL | 5 GB, more with long retention |
| Runtime | Ruby 4 / Rails 8 / PostgreSQL | Same, plus a second worker |
Each Rails process holds roughly 300-400 MB resident. Storage grows with retained events, so set keep_events_for on chatty agents.
Self-Hosting Huginn with Docker
The quickest local try is the all-in-one image, which starts its own MySQL:
docker run -p 3000:3000 ghcr.io/huginn/huginn
For anything real, split the processes and use an external database, as this template does. The following is a minimal Docker Compose file for PostgreSQL:
services:
postgres:
image: postgres:16
environment:
POSTGRES_USER: huginn
POSTGRES_PASSWORD: change-me
POSTGRES_DB: huginn
web:
image: ghcr.io/huginn/huginn-single-process
ports: ["3000:3000"]
environment: &env
DATABASE_URL: postgres://huginn:change-me@postgres/huginn
APP_SECRET_TOKEN: a-long-random-string
INVITATION_CODE: pick-your-own
worker:
image: ghcr.io/huginn/huginn-single-process
command: /scripts/init bin/threaded.rb
environment: *env
APP_SECRET_TOKEN must match across containers and must never change, or every existing session breaks.
How Much Does Huginn Cost to Self-Host?
Huginn is free and open source under the MIT license — no paid tier, no hosted edition, no per-task metering. A thousand agents checking every minute costs nothing in software. Your only expense is infrastructure, billed by Railway for what the five services use. That is why people move here from Zapier or Make, where the same volume is priced per task.
FAQ
What is Huginn?
Huginn is an open-source Rails application for building agents that monitor the web and act for you. It is often called a self-hosted IFTTT or Zapier alternative, though it leans far more toward scraping and monitoring than toward SaaS connectors.
What does this Railway template deploy?
Five services: a Huginn web UI, a scheduler, a background worker, a managed PostgreSQL database, and a Mailpit inbox for outgoing mail. The web UI and inbox get public URLs; everything else stays private.
Why does Huginn need PostgreSQL rather than just a volume?
Agents, their memory, every event they emit and the background job queue all live in a relational database — Delayed::Job is backed by a table, not by Redis. Postgres also gives the three services one shared source of truth.
How do I send real emails instead of catching them in Mailpit?
Either point SMTP_SERVER, SMTP_PORT, SMTP_USER_NAME and SMTP_PASSWORD at your own provider on all three Huginn services, or set Mailpit's MP_SMTP_RELAY_* variables with MP_SMTP_RELAY_ALL=true.
Can I run more than one worker to speed up my agents?
Yes — raise the replica count on the worker service, since Delayed::Job locks rows and workers never collide. Leave the scheduler at one replica: it has no leader election, so a second copy runs every due agent twice.
Template Content
huginn-web
gridalpha/huginn-railwayhuginn-worker
gridalpha/huginn-railwaymailpit
axllent/mailpit:latesthuginn-scheduler
gridalpha/huginn-railway