Vision apps aren’t static pages. Every project includes a fully managed backend: server code, APIs, scheduled jobs, and workers, running alongside your frontend without any infrastructure to set up.
What the backend can do
Ask for it in plain language, and the agent builds the server side:
- APIs — endpoints your app (or other tools) call
- Scheduled jobs — “every morning at 8, refresh the report and post it to Slack”
- Background workers — long-running processing that shouldn’t block the UI
- Talking to the outside world — call third-party APIs, fetch or scrape external sites, receive webhooks
Combined with the built-in database and integrations, this is a complete stack — not a frontend with a toy data layer.
Apps and services
A project can run several services side by side — say a web app, an admin panel, and a worker. Project settings → Apps lists them all with their run commands, ports, and status; the agent updates this manifest as your project grows.
- Each web service gets its own live address when published (and can carry its own custom domain).
- Workers run in the background with no public address.
- Browser-facing settings (like an API base URL) should point at the addresses shown in the Publish tab’s App addresses card.
Apps
What this project runs, and which app the preview shows.
npm run build && npm start production npm run dev:admin dev command npm run worker production
[worker] processed 214 stock events · [web] ready on :3000
Logs
When something misbehaves, open the app logs in the workspace to see exactly what the server printed — in dev and on the live deployment. The fastest fix is usually pasting the interesting lines straight into chat and letting the agent take it from there.
Dev vs production
In your workspace, services run in development mode with hot reload. On the live app, services with a production command run optimized builds — the Publish tab shows exactly what the live app runs per service.