Summary
Heroku supports heroku run --detach which starts a one-off dyno in the background and returns immediately, with output going to the app's logs instead of the terminal. We should support equivalent functionality.
Current architecture
Our run command works via direct SSH connection to the app's SSH server, which spawns an ephemeral dyno. This is inherently an attached/interactive model — there's no separate "create dyno" step that could be made detached.
Heroku's approach works because their API has a two-step flow: POST /dynos (with attach: true/false) followed by an optional rendezvous attach. We don't have that separation.
What's needed
This requires server-side support before the CLI can implement it. Options:
- New API endpoint (e.g.
POST /api/v1/apps/{id}/run) that creates a one-off dyno without requiring an SSH session, returns a dyno ID, and routes output to logs.
- Extend
exec_dyno if it can be adapted to create one-off dynos rather than only targeting existing running dynos.
Once the backend supports detached runs, the CLI changes are straightforward: add a --detach flag to the run command, call the API instead of opening an SSH session, and print the dyno identifier so the user can check logs.
Expected UX
$ bld run --detach --app myapp rake db:migrate
Running rake db:migrate on myapp... up, run.1234
Use `bld logs --dyno run.1234 --app myapp` to view the output.
Summary
Heroku supports
heroku run --detachwhich starts a one-off dyno in the background and returns immediately, with output going to the app's logs instead of the terminal. We should support equivalent functionality.Current architecture
Our
runcommand works via direct SSH connection to the app's SSH server, which spawns an ephemeral dyno. This is inherently an attached/interactive model — there's no separate "create dyno" step that could be made detached.Heroku's approach works because their API has a two-step flow:
POST /dynos(withattach: true/false) followed by an optional rendezvous attach. We don't have that separation.What's needed
This requires server-side support before the CLI can implement it. Options:
POST /api/v1/apps/{id}/run) that creates a one-off dyno without requiring an SSH session, returns a dyno ID, and routes output to logs.exec_dynoif it can be adapted to create one-off dynos rather than only targeting existing running dynos.Once the backend supports detached runs, the CLI changes are straightforward: add a
--detachflag to theruncommand, call the API instead of opening an SSH session, and print the dyno identifier so the user can check logs.Expected UX