Use cases · Internal tools
Internal tools in productionNo second setup
The admin app gets the same production path. You do not invent a side stack.
source
build
live
storefront
Customer app
app.up.dflow.sh
admin
Internal tool
admin.up.dflow.sh
In the product
The admin app is a normal app.
Create it next to the customer app. Same deploy. No side stack.
Before
The leftover server becomes the dependency.
The dashboard shipped in a week. Payroll still depends on 10.0.1.14.
leftover
10.0.1.14
No deploy history. Shared password.
workspace
ops-dashboard
Same workspace as the customer app.
Same path
The admin app gets the same production.
The internal tool does not get a weaker production path.
Same release history as storefront.
Access
Workspace roles. Not a shared password.
Owner, member, and viewer already exist. The internal app uses them.
Billing and members
Deploy and operate
Read logs and status
Handoff
The next person can see the last release.
When the first author leaves, the deploy history is still on the service.
v8
11m ago
live
v7
2d ago
previous
v6
last week
kept
internal
Launch the tool.Keep it maintainable.
admin.up.dflow.sh
Use dFlow when an internal app should be quick to ship and still clear six months later.