SELF-HOSTED APPLICATION BACKPLANE
GIVE IDEAS
A PLACE
TO RUN.
Beamhall is the infrastructure beneath the apps people and AI agents create.
A place to build, provision, run, connect, and use software—with permissions, isolation, and an audit trail built into the path.
SELECT A LAYER TO INSPECT ITS ROLE.
People bring the intent.
Coding agents connect over MCP, authenticated through your identity provider. Employees can use app interfaces or their agents. The person’s identity determines which path is available.
MCP · OAuth / OIDC · browser accessBeamhall does the privileged work.
The MCP surface passes requests to policy checks and the orchestrator. Roles, scope, quota, and lifecycle state govern operations. Decisions and outcomes are recorded in the audit chain.
beamhalld · policy · orchestrator · auditEach app gets a bounded environment.
Your application code runs in an isolated container. It receives provisioned data, identity, storage, and email capabilities. Apps connect to other apps through explicit relay grants.
runc / gVisor · Postgres · secret files · brokersThe whole assembly runs on your terms.
A Linux host, a gateway, build services, backing databases, and your identity provider form the installation. You operate the host, keys, backups, and policies. No Beamhall-hosted control plane is required.
Linux · Caddy · build daemon · registry · SQLite
CREATION SHOULD
NOT REQUIRE
THE KEYS TO
EVERYTHING.
An agent can write an app. Running that app means making decisions about data, identity, networking, deployment, and who gets to use it.
Beamhall gives those decisions a home. A builder describes what the application needs. The platform performs the infrastructure work within rules set by the people operating it.
The result can be a web app, an API, an internal service, or a tool another agent uses. The purpose comes from you. The platform supplies a repeatable way to run it.
One application, with its source, releases, runtime, and capabilities.
A group of apps with memberships, quotas, and a security profile. Called a beamhall in the API.
Write the logic. Choose what it should do.
Build, provision, run, route, and record.
Control access, resources, exposure, and release.
OPEN THE CASE.
MEET THE PARTS.
A Go control plane coordinates a set of supporting services. Your application code runs in separate workloads.
The installation includes more than the binary: a Linux host, build services, a gateway, data services, and an identity provider.
01 Identity & tool surface Who is asking, and what can they ask for?
MCP gives coding agents a defined set of operations. OAuth/OIDC establishes the caller’s identity. Builders, operators, and app users have different paths through the system.
02 Policy & orchestration Turn an allowed request into real infrastructure.
Policy checks permissions. The orchestrator checks resource and lifecycle constraints, provisions capabilities, and reconciles the running app. The control plane’s state is stored in SQLite.
03 Source, build & runtime Your code becomes an isolated workload.
A managed Git repository feeds a dedicated Buildpacks build service and internal registry. The runtime driver starts the app with IT-defined hardening and resource limits.
04 Managed capabilities The app gets facilities, not a pile of setup work.
Postgres, secret files, OIDC sign-in, S3-compatible object storage, and brokered email are provisioned under policy. Provider credentials stay in their appropriate platform boundary.
05 Gateway & relay Reach the app. Control what the app can reach.
Caddy handles app routing and TLS. Workload egress is default-deny. Specific apps may use each other’s tools through an IT-granted relay; they do not receive general network access to their peers.
06 Audit & operation A system you can inspect and take responsibility for.
Policy decisions and operation outcomes go into a tamper-evident audit chain. Operators control identity, policy, host maintenance, backup, keys, and retention.
The parts work together. Expand any row to see its responsibility and where it lives in the project.
FOLLOW
ONE REQUEST.
How does an instruction become an actual change? Pick an operation and follow it through the machinery.
These traces explain the implementation. They do not provision anything or run a live agent.
An app needs somewhere to keep its data. The agent asks for a capability; Beamhall provisions it and delivers the connection to the workload.
The builder asks for a database by name.
The MCP call identifies the workspace, app, and database. It does not ask the model to choose a database provider or invent host credentials.
agent → MCP Check membership before provisioning.
The policy layer checks whether this identity can create a database in this workspace. The orchestrator also checks the app and database quota.
policy → orchestrator Create scoped data infrastructure.
The Postgres provisioner creates the database and role. The orchestrator seals its connection string in the secret vault and records the app resource.
Postgres + secret vault The app gets the connection. The agent gets a reference.
The call returns a secret key such as MAIN_URL. On the next deployment, the workload reads the connection from /run/secrets/MAIN_URL. Preview and live use separate data resources.
reference → agent / secret file → app Keep the decision and outcome inspectable.
Authorization and operation outcomes are recorded with actor, workspace, app, and action. If provisioning fails, the orchestrator attempts cleanup and reports the failure.
audit chain Read the complete operation
- Request: The builder asks for a database by name.
The MCP call identifies the workspace, app, and database. It does not ask the model to choose a database provider or invent host credentials.
- Authorize: Check membership before provisioning.
The policy layer checks whether this identity can create a database in this workspace. The orchestrator also checks the app and database quota.
- Provision: Create scoped data infrastructure.
The Postgres provisioner creates the database and role. The orchestrator seals its connection string in the secret vault and records the app resource.
- Deliver: The app gets the connection. The agent gets a reference.
The call returns a secret key such as MAIN_URL. On the next deployment, the workload reads the connection from /run/secrets/MAIN_URL. Preview and live use separate data resources.
- Record: Keep the decision and outcome inspectable.
Authorization and operation outcomes are recorded with actor, workspace, app, and action. If provisioning fails, the orchestrator attempts cleanup and reports the failure.
Source becomes a running app through a controlled build path. The agent supplies application code; the platform owns the build and runtime wiring.
Ask to deploy the app.
After authorization, Beamhall supplies a one-time Git push remote for the app’s managed repository. The agent pushes its source.
agent → MCP → Git Build an image from source.
A dedicated build daemon runs Cloud Native Buildpacks and publishes an image to the internal registry. The runtime daemon is a separate part of the installation.
source → buildpacks → registry Start the workload inside its boundary.
The orchestrator stages secret files, applies the IT-defined runtime profile, attaches networking, and starts the container through the runtime driver.
orchestrator → runc / gVisor Give the preview an address.
The gateway publishes a preview URL. The agent can inspect scrubbed logs and iterate. Production is a separate live channel, pinned by an authorized promotion.
Caddy → preview URL Track the operation and its result.
Policy decisions and operation outcomes enter the audit chain. Build progress and logs help the builder diagnose a failure without receiving raw host access.
audit + build progress Read the complete operation
- Request: Ask to deploy the app.
After authorization, Beamhall supplies a one-time Git push remote for the app’s managed repository. The agent pushes its source.
- Build: Build an image from source.
A dedicated build daemon runs Cloud Native Buildpacks and publishes an image to the internal registry. The runtime daemon is a separate part of the installation.
- Run: Start the workload inside its boundary.
The orchestrator stages secret files, applies the IT-defined runtime profile, attaches networking, and starts the container through the runtime driver.
- Route: Give the preview an address.
The gateway publishes a preview URL. The agent can inspect scrubbed logs and iterate. Production is a separate live channel, pinned by an authorized promotion.
- Record: Track the operation and its result.
Policy decisions and operation outcomes enter the audit chain. Build progress and logs help the builder diagnose a failure without receiving raw host access.
An employee’s agent can act through tools an app exposes. Building the app and using the app are different permission paths.
Find apps published to this person.
list_apps and describe_app are audience-scoped. A person does not need builder membership in the workspace to discover a published app.
person’s agent → app audience Check the audience and the live channel.
use_app resolves the requested app for the caller and requires it to be live. It fetches the app’s own tool menu or invokes the requested tool.
audience check → live app Tell the app who is calling.
Beamhall creates a short-lived signed assertion bound to the app and tool. The employee’s identity-provider token is not forwarded.
signed caller assertion The app performs its own operation.
The app verifies the assertion and applies its own authorization. Its response passes through the broker’s size limits and secret scrubber before reaching the agent.
app tool → broker → agent Attribute the brokered call.
The call’s result is recorded under the caller’s identity. Rate-limited requests are deliberately handled before per-call auditing to bound audit growth.
actor + tool + outcome Read the complete operation
- Discover: Find apps published to this person.
list_apps and describe_app are audience-scoped. A person does not need builder membership in the workspace to discover a published app.
- Resolve: Check the audience and the live channel.
use_app resolves the requested app for the caller and requires it to be live. It fetches the app’s own tool menu or invokes the requested tool.
- Identify: Tell the app who is calling.
Beamhall creates a short-lived signed assertion bound to the app and tool. The employee’s identity-provider token is not forwarded.
- Invoke: The app performs its own operation.
The app verifies the assertion and applies its own authorization. Its response passes through the broker’s size limits and secret scrubber before reaching the agent.
- Record: Attribute the brokered call.
The call’s result is recorded under the caller’s identity. Rate-limited requests are deliberately handled before per-call auditing to bound audit growth.
Apps can cooperate without gaining a general network path to one another. IT grants a specific relationship; the relay checks it on each call.
One workload calls the relay.
The app uses the connection material Beamhall mounted into its runtime. This path authenticates a workload, not an employee’s MCP session.
app A → relay Verify which app is calling.
The relay checks the injected key and the live container address. A caller cannot gain access simply by naming another app.
workload key + source address Check the explicit peer grant.
IT must have granted the target app to the caller. The target must be live. A missing grant stops the relay path; direct app-to-app networking remains blocked.
IT grant → target live channel Deliver a signed app identity.
The target receives a signed assertion with caller_type set to beam. It verifies that assertion and decides what this app caller may do.
app A → broker → app B Keep cooperation attributable.
The relay records the call with its workload identity and result. Revoking the grant prevents subsequent calls through this relationship.
app identity + target + outcome Read the complete operation
- Request: One workload calls the relay.
The app uses the connection material Beamhall mounted into its runtime. This path authenticates a workload, not an employee’s MCP session.
- Authenticate: Verify which app is calling.
The relay checks the injected key and the live container address. A caller cannot gain access simply by naming another app.
- Authorize: Check the explicit peer grant.
IT must have granted the target app to the caller. The target must be live. A missing grant stops the relay path; direct app-to-app networking remains blocked.
- Relay: Deliver a signed app identity.
The target receives a signed assertion with caller_type set to beam. It verifies that assertion and decides what this app caller may do.
- Record: Keep cooperation attributable.
The relay records the call with its workload identity and result. Revoking the grant prevents subsequent calls through this relationship.
SAME PLATFORM.
DIFFERENT PERMISSIONS.
Being able to use an app does not make you its builder. Being able to build one app does not give it access to another.
Change the condition below. The boundary determines whether the request can proceed.
Can this builder attach a database?
A builder role applies inside the workspace where it was granted.
The builder can request a database in this workspace. The platform still checks the app and resource quota before provisioning.
Switch membership off. The same request stops at authorization, before a database is provisioned.
A teaching model of one boundary at a time. Assumes valid authentication, required token scopes, a running target where relevant, and available capacity. No backend requests are made.
Permission to use a tool is not permission to trust its code.
Apps must verify signed caller assertions and implement their own authorization. Audience checks govern discovery and brokered calls; web URLs need appropriate gateway and app sign-in controls.
Self-hosted apps do not automatically mean local AI.
Your chosen model provider may process prompts and tool results. You still operate the host, review generated code, and decide which outbound destinations are permitted.
Read the boundaries and residual risks ↗
EXPERIMENT HERE.
KEEP LIVE STEADY.
Preview and production are two channels of the same app. Promote a reviewed build, then keep developing without moving production underneath your users.
Promotion is governed by IT policy. Where two-person approval is enabled, a different authorized operator must approve the requested release.
Keep experimenting.
A changing preview URL, its own data resources, and a pause/resume lifecycle.
▤ PREVIEW DATABASEreviewed build IT policy applies
Keep production steady.
A stable address and separate live data. New preview work does not move this pin.
▤ LIVE DATABASE
OWN
THE GROUND
YOU BUILD ON.
Beamhall is free, open-source software for anyone to run on infrastructure they control. No required Beamhall account, subscription, or hosted control plane.
You have the code and the data. Standard foundations—Git, PostgreSQL, OIDC, SMTP, and S3-compatible storage—give you familiar ways to work with them. Moving an app elsewhere means replacing its Beamhall runtime integrations.
Inspect the source.
Modify the platform.
Run it with your provider.
Contribute your changes.
The host and its updates.
Identity and access policy.
Keys, backups, and recovery.
Capacity and audit retention.
What to build.
Which agents to connect.
Who can use each app.
Where your infrastructure runs.
The software is free. Hosting, storage, email, and AI services may have costs from the providers you choose.
BRING A HOST.
MAKE IT YOURS.
Prepare Linux and DNS. Install the appliance. Connect identity, define a workspace, and give an agent its first bounded place to build.
Open the installation guide ↗Ubuntu 24.04+ / Debian 12
4 vCPU / 8 GiB RAM recommended
Wildcard DNS + a TLS strategy
Built. Lab-validated. Still evolving.
Runtime, source deployment, Postgres, secrets, identity, email, storage, app tools, peer relay, approvals, and audit are implemented. Validation in design-partner environments is the next milestone.
Queues, more internal-system connectors, microVM isolation, and further supply-chain and egress controls remain on the roadmap.
Read the changelog ↗