Hatchet

Why deploy on Railyard

Railyard provisions postgres alongside it automatically — zero-downtime deploys, automatic backups and scaling come from the same platform, on a server you already pay for.

Deploying Hatchet is one piece of a bigger stack you can keep building — add a database, a worker, a cache, or another app, all on the same servers you already pay for.

Good for

• Durable background jobs and workflows with automatic retries across a fleet of workers
• A self-hosted alternative to Temporal/Inngest for distributed task orchestration
• Scheduling and fan-out/fan-in step functions triggered from your own app code

Good to know

• Postgres is wired up automatically; this uses Postgres itself as the message queue (no separate RabbitMQ needed)
• Default login is admin@example.com / Admin123!! — change it immediately after first login
• The gRPC port (7077) that SDK workers connect to isn't this app's public port — workers need to run as other apps on the same Railyard team, reaching this app's private domain on 7077. External workers outside Railyard can't connect