Skip to Content
Bahama CloudApplications and deployments

Applications and deployments

Your agent should choose a Cloud framework from the live provider guide:

bahama providers bahama-cloud --format agent

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

FrameworkUse it forWhat the project needs
static-siteBrowser-ready HTML, CSS, and JavaScriptindex.html at the application root; no build step
static-bundleOutput built before deploymentindex.html at the root or in dist/, build/, or public/
vite-spaA browser-only Vite applicationpackage.json, Vite, a build script, and one supported lockfile
vite-honoA Vite frontend with a Hono APIThe Vite requirements plus an exported app in server/index.*
hono-apiA Hono API without frontend assetsHono, 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:

server/index.ts
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:

bahama.yaml
application: framework: vite-spa dir: apps/web

The directory must stay inside the repository. It becomes the source root for validation and deployment.

Your agent deploys with:

bahama deploy production

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

Last updated on