Provisioning and deploys
An agent that can only write code is a demo. Ultron builds an app in the workspace, stands up the backing services it needs — a database, storage, a key-value store, an AI gateway — and ships it to a live URL you own, with a real backend, in one motion. No third-party account to wire up, no keys to paste, no console to visit. It provisions, deploys, and then checks its own work.
Overview
- Provision
- A database, object storage, a key-value store, an AI gateway
- Deploy
deploy_wfp- Live URL
- An owned address with no login wall and no third-party account
- Modes
- Static site, or a full app with a real server-side backend
- Secrets
- Three tiers, all keeping the value away from the browser, the logs, and the model
- Ownership
- Every app and resource belongs to one account; cross-user access is refused
Provisioning and deploys are native tools the agent runs from the workspace. They run server-side: the credentials that actually create infrastructure never enter the build environment, so a built app can never read or leak them.
Provisioning services
Four idempotent tools, one backing service each.
| Tool | Stands up | For |
|---|---|---|
provision_db | A SQL database | Relational data for the app |
provision_bucket | Object storage | Files, uploads, generated assets |
provision_kv | A key-value store | Fast lookups, sessions, caches |
provision_ai | An AI gateway | Model calls with caching, rate limiting, and cost tracking |
Deploying an app
One tool ships the built workspace to a live URL.
deploy_wfp takes the app built in the workspace and ships it live to an address you own, with no authentication wall in front of it and no third-party account involved. It has two modes.
| Mode | What ships |
|---|---|
| Static | A built single-page app or site — the compiled front end, served directly. |
| Full app | The static front end plus a self-contained backend that serves your API routes server-side. Real-time and stateful features (per-room objects, live connections) are supported without a separate provisioning call. |
Provisioned resources attach at deploy time and the backend reads them as named handles — the app never holds raw connection strings. After shipping, the deploy verifies itself: it polls the live URL and reports the real response status rather than assuming success.
The secret model
Three tiers, each keeping the value further from anything that could leak it.
| Tier | How the secret is handled |
|---|---|
| Server-side bound secret | Attached to the backend at deploy time and readable only server-side. It is never shipped to the browser. |
| Secret reference | The app references a secret by name; the real value is resolved server-side from the operator store or your integration vault. The raw value never flows through the model or the logs. |
| Egress-boundary injection | The app calls an external API with no token at all; the credential is injected at the outbound edge. The secret never enters the app environment. |
Ownership and isolation
Every app and resource has exactly one owner.
Each app and each provisioned resource is recorded in an ownership registry against your account. A name belongs to one account only. A deploy or delete that targets something owned by another user is refused. Your apps and their data are yours alone.
Build discipline
Hard gates keep a broken build from going live.
- 01Typecheck before commitThe workspace will not commit code that does not typecheck.
- 02Commit and push before deployA deploy ships committed, pushed work — never an uncommitted local state.
- 03No deploy while a build is still runningA deploy is held until the build that produces the artifact has finished, so a half-built app never ships.
Lifecycle
Inventory and teardown.
| Tool | What it does |
|---|---|
list_apps | Lists the apps you own |
delete_app | Removes an app's backend and its secrets, and leaves its data intact |
delete_resource | Irreversibly deletes a provisioned resource and its data, after an ownership check (a non-empty bucket must be emptied first) |