Deploy and Host Kestra on Railway

Kestra is an open-source, event-driven workflow orchestration platform that lets you build data pipelines, ETL jobs, and infrastructure automation as declarative YAML — no Python DAG boilerplate, no Spring beans, no DSL to learn. Self-host Kestra on Railway with a Postgres-backed standalone server, persistent storage volume, and basic-auth out of the box, and get a production-ready alternative to Airflow, Prefect, and Dagster in a single click.

This Railway template deploys Kestra in standalone mode (executor + scheduler + worker + indexer in one JVM) backed by a managed Postgres database, with persistent storage mounted at /app/storage and basic authentication pre-configured so the UI is locked down from the first request.

Getting Started with Kestra on Railway

After the deploy turns green, open the public Railway URL in your browser. You'll be prompted for the basic-auth credentials defined during template setup ([email protected] and the password you set in KESTRA_CONFIGURATION). The first time you log in, six "Getting Started" tutorial flows are auto-loaded under the tutorial namespace — open hello-world to see the YAML, click Execute to run it, and watch the live logs and Gantt chart in the execution view. From there, jump into the Blueprints tab to clone any of 600+ pre-built flows for ETL, monitoring, AI agents, or DevOps.

About Hosting Kestra

Kestra defines workflows in YAML — every task is a plugin (Python, shell, SQL, dbt, AWS, Slack, Snowflake, Kafka, etc.), and the entire flow is git-versionable, code-reviewable, and diffable. The standalone server bundled in this template runs all four core services (executor, scheduler, worker, indexer) inside one container, which is the recommended layout for small-to-medium workloads on a PaaS like Railway.

Key features:

• 600+ plugins spanning AWS, GCP, Azure, dbt, Snowflake, BigQuery, Kafka, Slack, GitHub, Terraform, and more
• Real-time triggers — schedule, webhook, file-watch, message-queue, S3, Kafka, polling
• Built-in UI with live execution logs, Gantt charts, blueprint marketplace, and a no-code form-based flow editor
• Declarative YAML that's git-friendly, lintable, and PR-reviewable — no Python DSL lock-in
• KV store, secrets, namespaces, labels for multi-team and multi-environment workflows
• Pluggable task runners — process (in-container), Docker, Kubernetes, AWS Batch, GCP Cloud Run

Why Deploy Kestra on Railway

• One-click standalone deploy — no docker-compose, no Helm chart
• Managed Postgres provisioned and wired up automatically
• Persistent volume keeps execution artifacts across restarts
• Basic auth pre-configured — no insecure default
• HTTPS terminated at the Railway edge — zero TLS config
• Pay-as-you-use pricing, scale memory/CPU on a slider

Common Use Cases

• Data pipelines — orchestrate dbt, Airbyte, Spark, BigQuery, and Snowflake jobs from one declarative YAML file
• Business automation — vacation approvals, alerting, report distribution, Slack-driven workflows with human-in-the-loop pauses
• DevOps & infra — chain Terraform, Ansible, Docker builds, and Kubernetes deploys with retries and approvals
• AI agent orchestration — sequence LLM calls, tool invocations, and human review steps with full observability

Dependencies for Kestra

• Kestra — kestra/kestra:latest (verified on 1.3.11)
• Postgres — ghcr.io/railwayapp-templates/postgres-ssl:latest (managed by Railway)

Deployment Dependencies

• Runtime: Java 21 / Kestra 1.3.x
• Docker Hub: kestra/kestra
• GitHub: kestra-io/kestra
• Docs: kestra.io/docs

Hardware Requirements for Self-Hosting Kestra on Railway

The standalone JVM defaults to ~3.8 GB max heap on a 4 GB Railway container. For workloads with hundreds of concurrent executions, bump to 8 GB and consider splitting into separate webserver + worker services.

Self-Hosting Kestra with Docker

The template uses the official Docker image and runs Kestra in standalone mode against a managed Postgres:

docker run -d \
  --name kestra \
  -p 8080:8080 \
  -e KESTRA_CONFIGURATION="$(cat application.yml)" \
  -v kestra-data:/app/storage \
  kestra/kestra:latest \
  /app/kestra server standalone

Where application.yml configures the Postgres datasource, basic auth, and storage path:

datasources:
  postgres:
    url: jdbc:postgresql://postgres:5432/kestra
    driverClassName: org.postgresql.Driver
    username: kestra
    password: kestra
kestra:
  server:
    basic-auth:
      username: [email protected]
      password: ChangeMe123
  repository:
    type: postgres
  queue:
    type: postgres
  storage:
    type: local
    local:
      base-path: /app/storage

How Much Does Kestra Cost to Self-Host on Railway?

Kestra OSS is free and Apache-2.0 licensed — you only pay Railway for the underlying compute, Postgres, and storage. A typical 2 vCPU / 4 GB Kestra instance with 5 GB Postgres lands around $15–25/month on Railway's usage-based pricing. Kestra Enterprise (RBAC, SSO, audit logs, multi-tenant, worker groups, secret backends) is a separate paid tier sold by Kestra; nothing in this template requires it.

FAQ

What is Kestra and why self-host it on Railway? Kestra is an open-source workflow orchestration platform — think Airflow, but with declarative YAML instead of Python DAGs. Self-hosting on Railway gives you full control of your data, no per-task billing, and one-click HTTPS without writing any infra config.

What does this Railway template deploy? A single Kestra standalone container (executor + scheduler + worker + indexer in one JVM) backed by a Railway-managed Postgres database, with a persistent volume mounted at /app/storage for execution artifacts.

Why does Kestra need a Postgres database on Railway? Postgres stores flow definitions, executions, logs, KV pairs, and the scheduler queue. Kestra can also run with H2 in-memory for local dev, but H2 loses everything on container restart — useless on a PaaS.

Can I run Docker tasks in self-hosted Kestra on Railway? No — Railway containers don't expose the Docker socket, so any flow using io.kestra.plugin.scripts.runner.docker.Docker will fail. Switch task runners to Process (runs inside the same Kestra container) or wire up a remote Kubernetes runner for isolated workloads.

How do I change the Kestra admin password after deploy? Edit the KESTRA_ADMIN_PASSWORD variable on the Kestra service and redeploy. The password must include uppercase letters, numbers, and be at least 8 characters — Kestra silently rejects weaker passwords (no error in logs; basic auth just never initializes).

Why is my Kestra on Railway deploy returning 502 or basic auth never initializing? Two Railway template quirks to watch for when self-hosting Kestra: (1) ${{OtherService.VAR}} references inside multi-line env var values don't always survive template publishing — keep cross-service refs on single-line env vars like DATASOURCES_POSTGRES_URL; (2) ${{secret(N)}} can generate passwords that violate Kestra's policy (uppercase + number + 8 chars) — use a regex-validated template input (KESTRA_ADMIN_PASSWORD) instead. Hyphenated YAML keys (base-path, tmp-dir, basic-auth) also can't round-trip through flat env vars because Micronaut splits on _ — keep them inside the KESTRA_CONFIGURATION YAML block.

Can I scale Kestra horizontally on Railway? The bundled standalone mode is single-container by design. To scale out, redeploy as separate webserver, worker, executor, scheduler, and indexer services — each with its own kestra server start command — and add a Redis queue for cross-service coordination.

How does Kestra compare to Airflow and Prefect for self-hosting? Kestra's YAML-first approach makes flows reviewable in PRs without Python knowledge, and the bundled standalone server is lighter than Airflow's webserver + scheduler + worker + Celery broker setup. Prefect 2.x requires its own cloud orchestrator or a self-hosted Prefect Server; Kestra is fully self-contained.