Beam vs Daytona (2026)

Code on Beam reaches other systems through what the customer writes. Secrets hold credentials, S3 buckets mount into apps and custom registries supply images. Task callbacks POST results to the customer's server, and sandbox ports expose services. Beam has no catalog of connectors, OAuth actions or tool gateway of its own, and the tools are the customer's code.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

An agent in a Daytona sandbox reaches outside systems through what runs inside it. Git operations clone and push repositories, secrets hold credentials and external storage can be mounted. Firewall allow lists decide which hosts the agent may reach. Daytona has no catalog of connectors, OAuth actions or tool gateway of its own. The tools are the customer's code.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

An agent framework ships in the SDK (Bot, BotLocation, BotContext) and is built on a Petri net model. Locations hold typed state, and transitions consume inputs from locations and write outputs to others. Transitions can be driven by a model or by plain code, run concurrently in isolated containers and keep state synchronized between them. Task queues add retries and timeouts, and map fans work out. Deterministic steps mix with agent steps, and branching and retries are built in. Beam says it is launching the framework and does not say how mature it is beyond the example it gives.

Sourcedocs.beam.cloud/v2/agents/introductionread 2026-09-22

The platform manages sandboxes. It creates and resizes them, applies lifecycle rules and runs warm pools and fleet scaling. It does not sequence, branch, retry or route an agent's steps. In Daytona's guides, agents built in LangGraph, the OpenAI Agents SDK and other frameworks do that, and Daytona has no workflow logic that mixes fixed steps with agent steps.

Sourcedaytona.io/docs/en/sandboxesread 2026-09-22

The schedule decorator runs a deployed job on a schedule, and web endpoints and task queues boot containers from zero when requests or tasks arrive. One app can send events to another through signals, for example to reload a model when retraining finishes. Task callbacks also notify the customer's server when a task finishes.

Sourcedocs.beam.cloud/v2/function/scheduled-jobread 2026-09-22

Events go outward. Webhooks notify the customer's endpoint when sandboxes are created or change state and when snapshots and volumes change. Automated lifecycle rules stop, pause, archive or delete idle sandboxes. An agent's work starts only when the customer's code starts it. There is no schedule, and a stopped sandbox does not wake on an inbound request.

Sourcedaytona.io/docs/en/webhooksread 2026-09-22

Any retrieval system on Beam is one the customer builds. Beam maintains no retrieval structure of its own over the customer's content for an agent to query. Volumes, durable disks, Maps and mounted S3 buckets store data but return no search results, and nothing Beam provides indexes, refreshes or permissions the customer's sources.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

The agent's code runs on Daytona, but there is no retrieval structure over the customer's content. Volumes and mounted external storage hold files the agent's code reads, and there is no index to query. The language server in a sandbox serves code intelligence for the files there. Nothing in Daytona indexes, refreshes or sets permissions on the customer's sources.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

State carries across runs. Sandbox snapshots capture filesystem and memory as an immutable artifact to fork from or restore, and distributed volumes and durable disks on each node persist data. Distributed Queues and Maps share it across tasks, and the agent framework synchronizes state between transitions, so an agent's code can read that state and carry on. Snapshot state is the machine's own state, which a customer can restore or delete but not review or edit. Beam names no memory layer for agents.

Sourcedocs.beam.cloud/v2/sandbox/snapshotsread 2026-09-22

Persistence is on by default at three layers. The filesystem survives stop, start and archive. On VM sandboxes, memory (running processes and loaded state) survives pause and resume and hot snapshots. Volumes and mounted external storage outlive any one sandbox. Sandboxes can also be forked, and the agent's code reads the restored state to carry on. Paused process state belongs to the machine, so the customer can resume or delete it but cannot review or edit it. There is no separate memory layer that sets what an agent keeps or for how long.

Sourcedaytona.io/docs/en/persistenceread 2026-09-22

For work running on Beam, including agents built with its framework, Beam names no approval step, consent checkpoint or escalation to a person. The platform isolates workloads with containers per customer, network separation and scoped secrets.

Sourcedocs.beam.cloud/v2/security/securityread 2026-09-22

Work in a sandbox has no approval step, consent checkpoint or escalation to a person. VNC, a web terminal and SSH let a person watch a sandbox and step in by hand. A firewall on each sandbox (allow lists or block all, with organization tiers that sandbox settings cannot override) restricts what an agent's code can reach. Nothing holds an agent's action for a person to review.

Sourcedaytona.io/docs/en/network-limitsread 2026-09-22

A SOC 2 Type II audit by Advantage Partners covers Beam, with the report under NDA, and Beam offers HIPAA BAAs for Enterprise customers and a GDPR DPA. Data is encrypted in transit and at rest, and containers and networks are isolated per customer. The customer scopes, rotates and deletes its encrypted secrets, and workspace API tokens can be created, rotated and revoked. All members of a workspace currently have the same permissions, and single sign on is not yet available.

Sourcedocs.beam.cloud/v2/security/securityread 2026-09-22

Organizations sign in through OpenID Connect providers such as Google Workspace, Microsoft Entra ID and Okta, with provisioning and membership handled at sign in on the Enterprise plan. Collaborative organizations have owner and member roles plus granular assignments by resource, such as SSO Admin and access to the audit log.

API keys carry permissions and scopes, with managed child keys. An audit log covers user and system activity, and each sandbox has firewall allow lists or block all. Daytona says it meets HIPAA, SOC 2 and GDPR standards and has a Trust Center, but it names no report type or auditor.

Sourcedaytona.io/docs/en/ssoread 2026-09-22

Application logs are kept 30 days on Developer and Team plans and one year on Growth, and log export is included. Task status can be queried by ID, with callbacks on completion. Prompts, tool calls, retrieved knowledge and outputs can be inspected step by step only as far as the customer's code logs them. Beam names no audit log of workspace actions separate from the runtime logs.

Sourcebeam.cloud/pricingread 2026-09-22

Each step an agent takes in the sandbox is recorded. SDK tracing instruments every Daytona API operation and SDK call from the customer's application, such as each command run, file written or process started. Sandbox telemetry collects traces, logs and metrics from inside the sandbox.

Both export over OpenTelemetry to the customer's own collector, and Daytona keeps sandbox telemetry for three days. A separate audit log records user and system activity with the user, action and time, and logs can be streamed. The model's reasoning runs outside Daytona. Audit export is not available yet, and Daytona says it is coming soon.

Sourcedaytona.io/docs/en/observability/otel-collectionread 2026-09-22

There are three ways to run Beam. The managed cloud runs on AWS and Google Cloud. With bring your own cloud, Beam runs the control plane and compute in the customer's AWS or GCP account for a flat management fee, and the compute bills to the customer's cloud. The pricing plans add Azure as a bring your own cloud option.

Beta9, the engine that powers Beam, is open source under AGPL 3.0 and can be self hosted on a local machine or Amazon EKS. Compute pools can also run Beam workloads on the customer's own machines. The beta9 repository is actively maintained. Beam names no region selection for the managed cloud.

Sourcedocs.beam.cloud/v2/self-hosting/overviewread 2026-09-22

Sandboxes run in two shared regions, the United States and Europe, chosen per sandbox. Under Bring Your Own Compute, an organization instead creates custom regions and attaches its own runner nodes, with an optional proxy and snapshot manager for each region, for control over data locality and compliance.

Daytona's control plane manages them, and BYOC is sold on the Enterprise plan. The platform sold today cannot be self hosted from open source. Core development has moved to a private codebase, and the public github.com/daytonaio/daytona repository gets no further updates. Its last release, v0.190.0, stays public under AGPL 3.0.

Sourcedaytona.io/docs/en/bring-your-own-computeread 2026-09-22

Ready made starting points ship as end to end examples for model serving (Llama, DeepSeek, Qwen and Hugging Face models, plus an OpenAI compatible vLLM server), for media (ComfyUI, Whisper and text to speech), and for fine tuning and web scraping, plus a research assistant agent built on the agent framework. Developers build from these examples, and Beam offers no browsable catalog of agents a customer can adopt as they are.

Sourcedocs.beam.cloud/v2/examples/overviewread 2026-09-22

Ready made starting points for running agents include default sandbox snapshots in several sizes, a Declarative Builder for images and an agent skill for coding agents. More than forty guides run coding agents (Claude Code, Codex, Devin, Gemini CLI, OpenClaw, OpenCode), as well as framework agents and reinforcement learning setups, in sandboxes, and a reference implementation runs Cursor's Cloud Agents on self hosted Daytona sandboxes. Developers build from these environments and walkthroughs. There is no browsable catalog of agents a customer can adopt.

Sourcedaytona.io/docs/en/agent-skillsread 2026-10-23

Customers choose the model, and Beam runs any model on the GPU the customer picks. Examples serve Hugging Face models such as Llama 3.1, DeepSeek R1 and Qwen through vLLM, including an OpenAI compatible vLLM server, or through SGLang, and others fine tune Gemma and Llama. Customers can bring their own deployments and providers.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

The customer chooses the model. Guides run agents on Claude, OpenAI Codex and the Agents SDK, Gemini, Kimi and AWS Kiro, and on open models through OpenCode and other frameworks. GPU sandboxes serve the customer's own LLMs with vLLM or SGLang. Daytona imposes no model, and customers bring their own providers and keys, with guides on setting them up.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

Outside callers reach Beam through Python and TypeScript SDKs, a CLI, and a REST API with published Swagger specifications for the gateway and pods, covering tasks, pods and sandboxes. Web endpoints expose the customer's code as HTTP APIs, the open source Beta9 engine can be extended, and a docs MCP server serves Beam's documentation to coding tools.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

Outside callers reach Daytona through SDKs in five languages (Python, TypeScript, Ruby, Go and Java), a REST API with published OpenAPI specifications, and a CLI. The specifications cover the Daytona API, the Toolbox API inside the sandbox and an Analytics API. An MCP server lets Claude, Cursor and Windsurf manage sandboxes, and an agent skill serves coding agents.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

Code, experiments and fine tuning jobs run on Beam with retries and logs. Beam names no fixtures, scoring or quality gates for a customer's agent workflows, and no way to compare agent runs.

Sourcedocs.beam.cloud/llms.txtread 2026-09-22

Evaluations and reinforcement learning run on Daytona, but it does not score them. Its guides run training with HUD, TRL, veRL and OpenEnv in sandboxes, along with a benchmark agent across several languages. The datasets, reward functions and scoring belong to those frameworks. Daytona offers no fixtures, scoring or quality gates for a customer's agent workflows, and no way to compare agent runs.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

Sandboxes run any code with GPUs, networking and storage and can expose ports for web services. Beam names no browser or desktop for an agent to operate and no API for screenshots, clicks or typing.

Sourcedocs.beam.cloud/v2/sandbox/overviewread 2026-09-22

The Computer Use API gives an agent programmatic control of a desktop in the sandbox, from mouse and keyboard to screenshots, screen recording and display operations, on Linux and Windows. VNC lets a person watch or take over. The desktop runs remotely on Daytona's infrastructure. macOS sandboxes run on Mac hardware reserved for the customer through use.computer, with their own API key, and the Daytona SDKs, CLI and API do not manage them.

Sourcedaytona.io/docs/en/computer-useread 2026-10-23