Use cases · Web applications
Your customers see the appYou do not run the stack
Ship the web app to production. We keep it up so you can keep building.
In the product
The app lives in one place.
Create it, attach a hostname, and ship. We keep production running.
Before
Shipping waits on three other jobs.
Build, domain, and logs each have a different owner, so a release waits on a handoff.
CI file
GitHub Actions, then a deploy script.
DNS + SSL
Registrar, proxy, then a certificate job.
another host
SSH, then hunt the right container.
dFlow path
The app goes to production. You do not assemble it.
Intake, builder, hostname, and logs stay on the same app.
Live
Customers reach the app.
The hostname, issued SSL, and the last release sit in one view.
hostname
app.up.dflow.sh
ssl
issued
release
v14 · 2m ago
→ detect Next.js · railpack
→ build complete
→ SSL ready
→ serving app.up.dflow.sh
Operate
Grow the app. Keep the same path.
CPU, memory, and replica count stay on the web process. The hostname does not move.
web
2 replicas
Request path. Scale this first.
cpu
memory
assets
1 replica
Static output when the builder emits it.
cpu
memory
web
Bring the app.We keep it running.
app.up.dflow.sh
Use dFlow when the next step is production, not another infrastructure project.