Deploy and Host Dagu on Railway

Built for an LLM agent to deploy and use. There is no /setup page and nothing to fill in: the admin password and the token-signing secret are generated at deploy time and valid from the first boot. The contract below lists every URL, variable name and the one script that proves it works.

Dagu is an open-source, self-hosted workflow engine and scheduler. You describe a workflow as a DAG in a YAML file (shell commands, scripts, HTTP calls, SSH, sub-DAGs, retries, cron schedules, human approval steps) and Dagu runs it, keeps the logs and run history, and serves a Web UI and a REST API. It is a single binary that stores its state in files, so there is no database or message broker to run.

About Hosting Dagu

This template runs one service, the official Dagu 2.25.7 image (ghcr.io/dagucloud/dagu, pinned by digest), with a volume at /var/lib/dagu. The volume holds the DAG definitions, the run history and logs, the user store and the queue, so everything survives a redeploy. The start command fixes the ownership of the volume (Railway mounts it as root, Dagu runs as uid 1000), turns on built-in authentication with the generated password and hands over to the stock entrypoint. Dagu listens on the port Railway injects. Allow about a minute for the first deploy to turn healthy.

Agent contract

Public URL: https:// plus the RAILWAY_PUBLIC_DOMAIN of the dagu service, used below as DAGU_URL. It serves the Web UI at /, the REST API under /api/v1 and an MCP endpoint at /mcp.
Private URL: http://dagu.railway.internal:8080
Credentials: user admin with the password in DAGU_ADMIN_PASSWORD. Tokens are signed with DAGU_AUTH_TOKEN_SECRET, which stays the same across redeploys, so sessions survive them.
Auth: POST {"username":"admin","password":"..."} to /api/v1/auth/login, then send the returned token as Authorization: Bearer TOKEN on every other API call. Unauthenticated API calls return 401.
Health: GET /health returns 200 with no credentials

# run with DAGU_URL and DAGU_ADMIN_PASSWORD set; needs curl
N="agent-check-$(date +%s)"
curl -s -o /dev/null -w 'health %{http_code}\n' "$DAGU_URL/health"
curl -s -o /dev/null -w 'anonymous %{http_code}\n' "$DAGU_URL/api/v1/dags"
T=$(curl -s -H 'Content-Type: application/json' -d "{\"username\":\"admin\",\"password\":\"$DAGU_ADMIN_PASSWORD\"}" "$DAGU_URL/api/v1/auth/login" | grep -o '"token":"[^"]*"' | cut -d'"' -f4)
if [ -n "$T" ]; then echo 'login ok'; fi
A="Authorization: Bearer $T"
curl -s -H "$A" -H 'Content-Type: application/json' -d "{\"name\":\"$N\",\"spec\":\"steps:\\n  - name: hello\\n    command: echo agent-ok\\n\"}" "$DAGU_URL/api/v1/dags"; echo
curl -s -H "$A" -H 'Content-Type: application/json' -d '{"dagRunId":"run1"}' "$DAGU_URL/api/v1/dags/$N/start"; echo
sleep 5
curl -s -H "$A" "$DAGU_URL/api/v1/dag-runs/$N/run1" | grep -o '"statusLabel":"[a-z_]*"' | head -2
curl -s -o /dev/null -w 'delete %{http_code}\n' -X DELETE -H "$A" "$DAGU_URL/api/v1/dags/$N"

A fresh deploy prints health 200, anonymous 401, login ok, {"name":"agent-check-..."}, {"dagRunId":"run1"}, "statusLabel":"succeeded" twice (the step and the run) and delete 204. Open DAGU_URL and sign in as admin to see the run history, or keep calling the API to add DAGs, start runs and read logs.

Why Deploy Dagu 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 Dagu 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.

Agent-ready - a generated admin password and signing secret, a contract block and one working script; no /setup page to open.
Login on from boot - built-in authentication is enforced, so nobody else can define a workflow that runs shell commands on your container.
State survives redeploys - DAGs, run history, logs and users live on a volume with the right ownership.
One service - no database, broker or workers to run.
Pinned image - pinned by digest, so a redeploy never changes the server version underneath you.

Common Use Cases

Replace cron with something you can see - schedules, retries, dependencies and a log for every run.
Self-hosted workflow automation for scripts and agents - an agent writes a YAML DAG through the API, starts it and reads the result.
Lightweight Airflow or Temporal alternative - ETL steps, backups, report jobs and health checks without a scheduler, database and worker fleet.

Dependencies for Dagu Hosting

Nothing else: Dagu keeps its state in files on the volume at /var/lib/dagu.

Deployment Dependencies

dagucloud/dagu - upstream project
Dagu documentation - YAML reference, executors and REST API