Skip to content
Beam Docs

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

InterfaceUse it when
StudioThe 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.
SDKA 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:

TriggerUse it for
On demandOne-off and ad hoc runs.
On a scheduleRecurring syncs and batch jobs.
From an external eventReacting 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.

  1. Sign in. Open Studio and choose Continue with Beam Auth. Studio shows a short code: approve it at auth.b1m.ai/device.
  2. Claim. In Settings → Access, choose your organization, enter the claim code the installer printed (sudo beam-updater claim-code prints it again), and select Claim this Studio. The first claim wins.
  3. 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 uninstall revokes 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.

RequirementDetail
Operating systemLinux with systemd. Windows and macOS are not supported.
Host sizeAt least 2 vCPUs, 4 GB of memory, and 20 GB of free disk.
AccessRoot, through sudo, to run the installer.
Container runtimeDocker Engine with the Docker Compose plugin (docker compose). The installer installs both when they are missing, and starts Docker.
Toolscurl, 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 sh

By 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.

VariableDefaultPurpose
BEAM_STUDIO_PUBLIC_URLhttp://localhost:3004The URL people open Studio at.
BEAM_STUDIO_BIND_ADDRESS0.0.0.0The 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-studioInstallation directory.
BEAM_STUDIO_CONFIG_DIR/etc/beam-studioConfiguration 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:

  1. Point a DNS name, such as studio.example.com, at the host.

  2. 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
  3. 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 original Host header through, because Studio checks it against the host name of its public URL. Caddy does this by default; in nginx, set proxy_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

Decentralized distributed bandwidth infrastructure.

On this page