Beam Studio
Beam Studio is a self-hosted app for visual data transfer workflows: move data between S3, R2 and HTTP endpoints on demand, on a schedule or from a webhook.
Beam Studio is a self-hosted application for designing and operating data movement visually. Instead of writing transfer code, you compose transfers, transforms, checks, and control flow as a graph, then let Studio run it and show you what happened.
Studio is a client of Beam, exactly like the SDK. It sends transfers through the same network, against the same organization credits, and the transfers it creates appear in the Console alongside every other transfer.
When to use Studio
| Interface | Use it when |
|---|---|
| Studio | The work is a pipeline, not a single transfer — several steps, conditions, retries, or a schedule. You want your team to read the process without reading code. It is also how you run a single transfer without writing code. |
| SDK | A transfer is one step inside an application you already maintain. |
Studio is not a replacement for the SDK. Reach for it when the interesting part is everything around the transfer.
What you can build
A Studio workflow is a graph you assemble from a catalog of Beam operations, storage connectors, webhooks, and data transformations. That lets one workflow cover a whole job:
- Move bytes between any supported connectors.
- Transform data between steps.
- Assert conditions before continuing, and branch on the result.
- Call out to your own systems with webhooks.
How work runs
Studio turns a workflow into a durable runtime plan, and its workers carry each step to completion. Because the plan is durable, a workflow survives restarts and resumes rather than starting over.
Every step reports state, so you can see what is queued, running, waiting, failed, or complete without following terminal output. This is the main practical difference from driving transfers yourself: the run is inspectable after the fact, not just while your process is alive.
Workflows start in three ways, all with the same execution model:
| Trigger | Use it for |
|---|---|
| On demand | One-off and ad hoc runs. |
| On a schedule | Recurring syncs and batch jobs. |
| From an external event | Reacting to something in your own systems. |
Connect Studio to your organization
Studio does not take a pasted API key. You sign in with your Beam account, claim the installation for your organization, and approve an API key that Beam issues to that installation.
- Sign in. Open Studio and choose Continue with Beam Auth. Studio shows a short code: approve it at auth.b1m.ai/device.
- Claim. In Settings → Access, choose your organization, enter the
claim code the installer printed (
sudo beam-updater claim-codeprints it again), and select Claim this Studio. The first claim wins. - Approve the instance key. Studio then asks you to approve its instance key in Beam Auth. Approving needs a role that can create API keys and run transfers: owner, admin, or developer.
Beam creates the instance key and hands it to Studio directly. It is an organization API key, listed in the Console under API Keys as "Studio: ‹your Studio's host›". Studio stores it under Credentials with the same name, marked (instance default), and uses it for new workflows and Beam Transfer steps.
- Settings → Access rotates and revokes the instance key. You can also revoke it in the Console.
- Uninstalling Studio with
sudo beam-updater uninstallrevokes it. If the host is gone, revoke "Studio: ‹host›" in the Console. - Other Beam API keys can still be added under Credentials and chosen instead.
Each workflow runs with the Beam API key selected as its Billing API key,
the instance key unless you choose another. Studio uses that key to authorize
every run and to hold and settle its credits, so revoking the key or removing
its workflows:run permission stops new runs. Every Beam Transfer step uses
the same key as its Beam credential, because a run is charged to one key.
The instance key holds every permission a run needs. A key you add yourself
needs workflows:run and actions:execute for the run and its steps, and
transfers:create for the transfers its Beam Transfer steps start.
Codes are single use and expire. If approval fails, start again in Studio to get a fresh code rather than reusing the old one.
Your First Studio Workflow walks through all of this, then builds and runs a first transfer.
Install
Studio runs on your own infrastructure, which is what lets it hold credentials for your storage providers locally.
| Requirement | Detail |
|---|---|
| Operating system | Linux with systemd. Windows and macOS are not supported. |
| Host size | At least 2 vCPUs, 4 GB of memory, and 20 GB of free disk. |
| Access | Root, through sudo, to run the installer. |
| Container runtime | Docker Engine with the Docker Compose plugin (docker compose). The installer installs both when they are missing, and starts Docker. |
| Tools | curl, jq, and OpenSSL. The installer installs any that are missing with the system package manager (apt, dnf, yum, or zypper). |
The hosted installer sets up the release updater, pulls the signed images, and starts the stack:
curl -fsSL https://cdn.b1m.ai/studio/install.sh | sudo shBy default Studio is served at http://localhost:3004, for a browser on the
host itself. To open it from other machines, see
Reach Studio from other machines before you
install.
| Variable | Default | Purpose |
|---|---|---|
BEAM_STUDIO_PUBLIC_URL | http://localhost:3004 | The URL people open Studio at. |
BEAM_STUDIO_BIND_ADDRESS | 0.0.0.0 | The host address Studio's port 3004 listens on. Set 127.0.0.1 when a reverse proxy on the same host serves Studio. |
BEAM_STUDIO_INSTALL_DIR | /opt/beam-studio | Installation directory. |
BEAM_STUDIO_CONFIG_DIR | /etc/beam-studio | Configuration and release key. |
Set these on the first install. A rerun of the installer keeps the values it wrote the first time.
Reach Studio from other machines
Give Studio a DNS name and serve it over HTTPS through a reverse proxy on the same host:
-
Point a DNS name, such as
studio.example.com, at the host. -
Install Studio with that HTTPS URL as its public URL, listening only on the loopback address so that nothing but the proxy reaches it:
export BEAM_STUDIO_PUBLIC_URL=https://studio.example.com export BEAM_STUDIO_BIND_ADDRESS=127.0.0.1 curl -fsSL https://cdn.b1m.ai/studio/install.sh | sudo -E sh -
Configure a reverse proxy with a TLS certificate for that name, such as Caddy or nginx, to forward requests to
http://127.0.0.1:3004. Pass the originalHostheader through, because Studio checks it against the host name of its public URL. Caddy does this by default; in nginx, setproxy_set_header Host $host;.
People then open https://studio.example.com, and the installer prints that URL
and the claim link with it.
Room file delivery between an agent member and a bucket member also depends on
this URL, from Studio v1.0.24. Beam workers fetch storage access from Studio at
it, so it must be HTTPS, with a certificate from a public CA, and reachable from
the internet. Studio checks that route at its own public URL before each such
delivery, so the host must also reach its own DNS name. Without that, the
delivery fails at once with room_storage_route_unreachable. Deliveries between
agent members don't use this route.
Each release is verified against a pinned signing key before it is applied, so an unsigned or tampered release is rejected rather than installed.
Updating
Studio updates from signed manifests, with health checks, a backup policy, and rollback, so an update that fails its checks does not leave the installation broken.
Next steps
- Your First Studio Workflow — From a fresh install to a verified transfer.
- Connectors — Configure the storage Studio moves data between.
- How Transfers Work — What happens once a Studio step starts a transfer.
- Billing & Payments — The credits Studio workflows consume.
- Beam Studio — Product overview and access.
Agent Data Sales
Sell or buy a dataset between AI agents that do not trust each other: a Beam Room delivers it encrypted, and an escrow contract on Bittensor EVM pays the seller only for the bytes it committed to.
Your First Studio Workflow
Go from a fresh Beam Studio install to a completed, verified transfer between two buckets.