Released July 27, 2023. Link to PyPI.
beam run
We are introducing a new primitive called beam run
.
beam run
is used to run one-off functions remotely, without having to deploy an API.
For example, let’s say you wanted to run some code on Beam, but you don’t want to run it in a dev session. And you don’t want to deploy it as an API. You just want to run it once, remotely, on the cloud.
You can accomplish this by adding a decorator to your function. Here’s what that will look like:
You can run this code remotely on Beam by running:
Now, transcribe()
will be executed on Beam remotely. Logs will be streamed to your terminal, and you can also view logs, outputs, and task status in the dashboard. beam run
also support the use of Outputs and Volumes.
Triggers are now decorators on functions. This supports the new syntax for beam run
, and it also makes it easy to switch between Runs, REST APIs, and Task Queues very easily.
Volumes are mounted directly to apps. This allows you to reuse app definitions across your different projects.
Outputs are now added directly to triggers. We’re doing this for composability and ease-of-use. It is easier to add an output directly to a trigger, instead of having a separate method outside the trigger.
beam.Types
from deployment triggers.Outputs
will automatically infer the file type. You no longer need to specify whether the output is a file
or a dir
./task
API to query the status of any job running on Beam. Previously, one could only query the status of async jobs.Webhook
has been renamed to task_queue
.We’ve noticed that loaders are not currently supported in beam run
. This
will be fixed in a future SDK update.
Released July 27, 2023. Link to PyPI.
beam run
We are introducing a new primitive called beam run
.
beam run
is used to run one-off functions remotely, without having to deploy an API.
For example, let’s say you wanted to run some code on Beam, but you don’t want to run it in a dev session. And you don’t want to deploy it as an API. You just want to run it once, remotely, on the cloud.
You can accomplish this by adding a decorator to your function. Here’s what that will look like:
You can run this code remotely on Beam by running:
Now, transcribe()
will be executed on Beam remotely. Logs will be streamed to your terminal, and you can also view logs, outputs, and task status in the dashboard. beam run
also support the use of Outputs and Volumes.
Triggers are now decorators on functions. This supports the new syntax for beam run
, and it also makes it easy to switch between Runs, REST APIs, and Task Queues very easily.
Volumes are mounted directly to apps. This allows you to reuse app definitions across your different projects.
Outputs are now added directly to triggers. We’re doing this for composability and ease-of-use. It is easier to add an output directly to a trigger, instead of having a separate method outside the trigger.
beam.Types
from deployment triggers.Outputs
will automatically infer the file type. You no longer need to specify whether the output is a file
or a dir
./task
API to query the status of any job running on Beam. Previously, one could only query the status of async jobs.Webhook
has been renamed to task_queue
.We’ve noticed that loaders are not currently supported in beam run
. This
will be fixed in a future SDK update.