Agents can build and deploy web applications for you. Ask an agent to create a dashboard, a data visualization tool, an API endpoint, or any interactive application. It writes the code, proposes a deployment, and with your approval, runs it on the platform.
What you can ask agents to build
- "Build a dashboard that shows my project metrics"
- "Create a simple API that serves this data as JSON"
- "Make a web page that visualizes this CSV data with charts"
- "Set up a static site with this HTML and CSS"
Two types of apps
Services
Long-running programs like web servers, APIs, or backend processes. The agent writes the code, specifies a start command, and the platform runs it as a background process with its own port.
Static sites
Pre-built HTML, CSS, and JavaScript files served directly by the platform. No running process needed. The agent builds the files and the platform serves them.
The approval workflow
You always control what gets deployed:
- The agent builds the app. It writes code and prepares a manifest describing what the app needs: the start command, network access, file permissions, resource limits, and any credentials.
- You review the manifest. The platform shows you exactly what the app will do and what access it needs.
- You approve or deny. If you approve, the platform starts the app in a sandboxed environment.
TIP
Approval is required when deploying a new app or when changes affect security-relevant settings (command, network access, credentials). Simple updates like changing the app name don't require re-approval.
Accessing your apps
Once running, apps get a dedicated URL at /apps/{app-id}/. Access is authenticated, so only you can reach your apps.
Example: building a data dashboard
You: "Take this CSV of sales data and build an interactive dashboard with charts."
Here's what happens:
- The agent reads your CSV and plans the dashboard
- It writes the HTML, CSS, and JavaScript (or a Python/Node.js backend if needed)
- It proposes a manifest: "Static site, no network access needed, no credentials"
- You see the manifest and approve it
- The platform deploys the site and gives you the URL
- You open the dashboard and interact with your data
App lifecycle
| State | What it means |
|---|---|
| Starting | App is launching, waiting for it to become healthy |
| Running | App is active and responding to requests |
| Serving | Static site is being served (no process to manage) |
| Stopped | You or the agent stopped the app |
| Failed | App crashed and couldn't be restarted |
| Hibernated | App paused due to inactivity (wakes up when you visit) |
Hibernation
Apps automatically hibernate after 3 days of inactivity to save resources. When you visit a hibernated app, it wakes up automatically. There's a brief delay while it restarts, then it serves your request normally.
Crash recovery
If a service app crashes, the platform attempts to restart it (up to 2 times by default). If all attempts fail, the app is marked as failed and you're notified. The agent may also try to diagnose and fix the issue.
Safety
Apps run in a sandboxed environment:
- Network. Apps can only reach destinations declared in the manifest.
- Filesystem. Apps can only access paths specified in the manifest.
- Resources. Memory and CPU usage are limited.
An app can't access your other data or make unexpected network connections unless you've approved it.
Tips
- Start simple. "Build a web page that shows X" is easier for agents than complex multi-service architectures.
- Review the manifest carefully. Check what network access and credentials the app requests. If it doesn't need external access, it shouldn't have it.
- Use static sites when possible. They're simpler, faster, and don't consume resources when idle.
Next steps
- App Manifests. Understand manifest fields and manage deployed apps.
- Sandbox. How sandboxing protects your system.