Escaping Heroku & Render: Zero-Downtime `git push` Deploys on Your Own Server

Developers stay on Heroku, Render, and Railway because they love the git push workflow, automatic database migrations, and zero-downtime health checks. They don't realize Railyard gives them that exact pipeline on their own cheap DigitalOcean or Hetzner VPS.

Every developer eventually hits the PaaS wall. You start a project on Heroku, Render, or Railway because git push deployments are magical. Fast forward six months: you add a couple of background workers, a Postgres database with pgvector, and a Redis cache. Suddenly, you are paying $180/month for less than 4GB of total RAM.

You want to move to a $10 DigitalOcean or Hetzner VPS, but you don't want to give up automatic builds, release hooks, and zero-downtime deploys.

Here is how to replicate the exact Heroku git push pipeline on your own cloud server using Railyard.

How Railyard's Build Pipeline Works

Whether your repository uses a Dockerfile, a Procfile, Nixpacks, or nothing at all (where Railyard defaults to railpack), Railyard turns your code into an OCI image and runs it through a strict production release pipeline on your own server:

1. Build-Time Config Vars: Environment variables are exported into the build environment (crucial for Next.js builds or Rails assets:precompile steps that inspect DATABASE_URL).
2. Release Hooks: Database migrations run in an isolated step before the new container takes live traffic. If a migration fails, the deploy halts immediately.
3. Readiness Probes: Traffic only swaps to the new container after your health check endpoint returns HTTP 200.

Step 1: Connect Your Server and Provision Addons

1. Connect any Ubuntu server from DigitalOcean, Vultr, or Hetzner to Railyard.run.
2. Inside your Railyard project, provision your backing services in one click: Postgres (with pgvector pre-installed) and Redis.
3. Railyard spins these up on the same server (or a dedicated database server in your fleet) and automatically injects DATABASE_URL and REDIS_URL into your application environment.

Step 2: Configure Your Release Hook & Health Check

If you are deploying a Ruby on Rails, Django, or Node.js app, you want migrations to run automatically on every deploy.

• If you use a Procfile, define your web and release commands just like Heroku:

release: bundle exec rails db:migrate
web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq

• Configure your health check path in Railyard (e.g., GET /up or GET /healthz).

Step 3: Push Your Code to Production

You can connect your GitHub account for automatic deploys on commit, or push directly from your terminal using Git:

$ git remote add railyard https://git.railyard.run/your-app.git
$ git push railyard main

Watch the terminal output as Railyard builds the app on your server, runs the migration hook, verifies the health check, and swaps traffic with zero dropped requests:

Enumerating objects: 12, done.
remote: Building storefront (Dockerfile)
remote: #7 RUN bundle install
remote: #9 RUN bin/rails assets:precompile
remote: Release: bin/rails db:migrate
remote: Health check passed (GET /up 200)
remote: Live, traffic moved to the new release.
To https://git.railyard.run/storefront.git
   a1b2c3d..e4f5a6b  main -> main

Step 4: Persistent Storage Without AWS S3 Headaches

Unlike ephemeral PaaS dynos that wipe the filesystem on every restart, Railyard lets you attach named persistent volumes directly to any path in your container (e.g., /rails/storage or /app/uploads) that survive across redeploys.

Bonus Growth Tip: Use Your "README Badge" Feature!

On your /templates/ and /deploy-methods/ pages, Railyard already has a built-in feature for a "Deploy to Railyard" README badge that opens a pre-filled deploy screen.

• Whenever you write a tutorial about any of the 337 apps (like Typebot, Windmill, Typesense, or SuperTokens), put that markdown badge at the very top of your Dev.to and Medium articles so readers can click it and land directly in your signup flow!