Verdict

Heroku v dFlow

Finding

Your nodes

Keep the app. Drop the dyno bill.

Stay on Heroku when you want them to run the fleet. Move to dFlow when you want production without the SKUs.

Connect a server Join the community

Runbook

Keep the app. Change who runs it.

Same app model. Production without the dyno bill.

cutover · runbook

01 / 5

01 · builder

Keep the builder

BuildPacks is the Heroku-shaped path — not a promise that every third-party pack runs unchanged. Railpack, Dockerfile, and Static ship beside it.

− leave

Heroku: Heroku buildpack

+ take

dFlow: BuildPacks · Railpack · Dockerfile · Static

Patch

What you keep. What you leave.

Same app model. The machines, the network, and the bill are the only real edits.

a/heroku → b/dflow

3 files · +12 −12

@@ shipping @@

Keep the release habit

Git still ships the app. The host is a worker node you attach, not a dyno fleet.

Where the app runs
Heroku: Fully managed platform
dFlow: dFlow Cloud on a worker node you attach
Push-to-ship flow
Heroku: Built in
dFlow: GitHub and GitLab auto-deploy on push
Custom domains and SSL
Heroku: Supported
dFlow: Let's Encrypt, custom Nginx, default up.dflow.sh

Auto-deploy on push is GitHub and GitLab only. BuildPacks is a shipped builder, not full Heroku-pack parity.

Tickets

Move the workload, not the habit

Web, workers, private mesh, and data are the workloads teams actually run on Heroku. They map onto a worker node.

01Build
Buildpack apps without the dyno bill
Teams moving production Heroku apps onto owned infrastructure
Keep a BuildPacks-shaped deploy while the app lands on your own servers or cloud VMs. Railpack, Dockerfile, and Static are there when a pack is the wrong tool.
Heroku: Heroku buildpack on dynos
dFlow: BuildPacks on a worker node
BuildPacks · Dokku · Docker · GitHub · Next.js
02Workers
Workers with CPU, RAM, and replicas you can name
Products with sustained background job throughput
Run worker and scheduler process types with CPU, memory, and replicas you set. Not a dyno size per process.
Heroku: Dyno-per-process billing
dFlow: CPU · RAM · replicas 1-5
Redis · Docker · Dokku · PostgreSQL · BuildPacks
03Mesh
Private service paths without a Spaces SKU
Teams isolating services without a Spaces SKU
Encrypted control-plane to node traffic over Tailscale, without Heroku Private Spaces pricing.
Heroku: Private Spaces
dFlow: Tailscale mesh
Tailscale · Cloudflare · Docker · PostgreSQL · Dokku
04Data
Data engines without marketplace sprawl
Teams cutting add-on sprawl
Run Postgres, Redis, MySQL, MongoDB, or MariaDB on the worker node, or keep an external provider without per-add-on platform margin.
Heroku: Add-on marketplace
dFlow: Engines you run, or bring your own
PostgreSQL · Redis · MySQL · MongoDB · MariaDB · Docker

cutover · authorization

ready

Keep the app. Drop the dyno bill.

Same app model. Production without the SKUs.

Connect a server

Heroku: Dyno hours

dFlow: The node you already pay for

Heroku: Private Spaces

dFlow: Tailscale

Heroku: Add-on margin

dFlow: Engines on the node

Keep the app. Change who runs it.

Same app model. Production without the dyno bill.

cutover · runbook

01 / 5

01 · builder

Keep the builder

BuildPacks is the Heroku-shaped path — not a promise that every third-party pack runs unchanged. Railpack, Dockerfile, and Static ship beside it.

− leave

Heroku: Heroku buildpack

+ take

dFlow: BuildPacks · Railpack · Dockerfile · Static

What you keep. What you leave.

Same app model. The machines, the network, and the bill are the only real edits.

a/heroku → b/dflow

3 files · +12 −12

@@ shipping @@

Keep the release habit

Git still ships the app. The host is a worker node you attach, not a dyno fleet.

Where the app runs
Heroku: Fully managed platform
dFlow: dFlow Cloud on a worker node you attach
Push-to-ship flow
Heroku: Built in
dFlow: GitHub and GitLab auto-deploy on push
Custom domains and SSL
Heroku: Supported
dFlow: Let's Encrypt, custom Nginx, default up.dflow.sh

Auto-deploy on push is GitHub and GitLab only. BuildPacks is a shipped builder, not full Heroku-pack parity.

Move the workload, not the habit

Web, workers, private mesh, and data are the workloads teams actually run on Heroku. They map onto a worker node.

01Build

Buildpack apps without the dyno bill

Teams moving production Heroku apps onto owned infrastructure

Keep a BuildPacks-shaped deploy while the app lands on your own servers or cloud VMs. Railpack, Dockerfile, and Static are there when a pack is the wrong tool.

Heroku: Heroku buildpack on dynos

dFlow: BuildPacks on a worker node

BuildPacks · Dokku · Docker · GitHub · Next.js

02Workers

Workers with CPU, RAM, and replicas you can name

Products with sustained background job throughput

Run worker and scheduler process types with CPU, memory, and replicas you set. Not a dyno size per process.

Heroku: Dyno-per-process billing

dFlow: CPU · RAM · replicas 1-5

Redis · Docker · Dokku · PostgreSQL · BuildPacks

03Mesh

Private service paths without a Spaces SKU

Teams isolating services without a Spaces SKU

Encrypted control-plane to node traffic over Tailscale, without Heroku Private Spaces pricing.

Heroku: Private Spaces

dFlow: Tailscale mesh

Tailscale · Cloudflare · Docker · PostgreSQL · Dokku

04Data

Data engines without marketplace sprawl

Teams cutting add-on sprawl

Run Postgres, Redis, MySQL, MongoDB, or MariaDB on the worker node, or keep an external provider without per-add-on platform margin.

Heroku: Add-on marketplace

dFlow: Engines you run, or bring your own

PostgreSQL · Redis · MySQL · MongoDB · MariaDB · Docker