Applications and deployments
Your agent should choose a Cloud framework from the live provider guide:
bahama providers bahama-cloud --format agentThe framework identifier in bahama.yaml tells Bahama how to validate, build,
route, and verify the application. It is an execution contract, not a marketing
label.
Supported application shapes
The Bahama Cloud is in alpha and supports this minimal set of frameworks that cover most static sites, React, and Hono as a backend. Many more frameworks including Next.js and Python are in development.
| Framework | Use it for | What the project needs |
|---|---|---|
static-site | Browser-ready HTML, CSS, and JavaScript | index.html at the application root; no build step |
static-bundle | Output built before deployment | index.html at the root or in dist/, build/, or public/ |
vite-spa | A browser-only Vite application | package.json, Vite, a build script, and one supported lockfile |
vite-hono | A Vite frontend with a Hono API | The Vite requirements plus an exported app in server/index.* |
hono-api | A Hono API without frontend assets | Hono, one supported lockfile, and an exported app in server/index.* |
Supported lockfiles are package-lock.json, pnpm-lock.yaml, and yarn.lock.
Vite builds must produce dist/index.html.
If the application does not fit one of these shapes, your agent should explain the mismatch and recommend another provider.
Hono applications export an app
The server entry exports the Hono application rather than starting a Node server:
import {Hono} from "hono";
const app = new Hono();
app.get("/api/status", (c) => c.json({ok: true}));
export default app;Do not call serve, import a Node server adapter, or depend on a persistent
production filesystem in this entry. Keep any Node-only local adapter in a
separate file.
For vite-hono, /api/* requests reach the Hono app and other routes serve
the frontend with SPA fallback. Bahama reserves /api/health for deployment
verification. A hono-api project sends all application requests to Hono.
Keep browser and server values separate
Anything whose name begins with VITE_ is included in browser code. API keys,
project secrets, database access, and development tokens belong in server-side
code only.
On Cloud, server code receives project secrets on its environment object:
type Env = {
OPENAI_API_KEY: string;
};
const app = new Hono<{Bindings: Env}>();Deploy the application directory
If the app lives inside a larger repository, your agent records its relative directory:
application:
framework: vite-spa
dir: apps/webThe directory must stay inside the repository. It becomes the source root for validation and deployment.
Your agent deploys with:
bahama deploy productionBahama packages the current source directly from the workspace. It excludes Git metadata, dependencies, environment files, package-manager credentials, Bahama state, and symlinks. The final source archive must be 25 MB or smaller.
For static-site, every packaged file is public. Keep private notes, source
credentials, and unrelated repository files outside the application directory.
The first deployment waits for you
The first deployment produces a consequential plan. Your agent explains the account, framework, source directory, and deployment step; you approve it; the agent applies the exact plan ID.
Bahama then validates the source, installs and builds when the framework needs it, publishes the application, and checks the public URL. A deployment is not complete until the live application responds successfully.
Later code-only deployments to the same verified project are routine. A framework change, resource change, new binding, or other infrastructure change pauses for another review.
Deployment errors identify the stage that failed—source validation, dependency installation, build, publication, or live verification. Give the complete error to your agent; it should fix that stage and retry through Bahama rather than publishing around it.