Websites
The sites and full-stack applications an employee has built and published.
Where
Employee sidebar → Work → Websites.
What it does
Sites and applications published by this employee, with a count, 0 sites
until there is one.
Publication is not done from this screen. As the screen says: employees can
publish a folder via the web-publish skill. So the sequence is:
- give the employee the web-publish skill, in Skills;
- ask it to publish a folder;
- the site appears here.
This screen is the list of what is live, and where you go to check what an employee has put online.
Full-stack applications
Since v2.8.0 an employee does not only publish pages. It can build and deploy a complete application: the interface, the server and the database, live at an address, from one conversation. A published project runs on Node.js, so it does real work: it calls an API, reads and writes its data, reacts to events.
| Part | What it gives you |
|---|---|
| Interface | The pages visitors and your team use, on a phone or a laptop. |
| Server | Node.js code that keeps running: checks, calculations, calls to other services. |
| Database | One SQLite database per project: parameterised queries, raw SQL, transactions, triggers, temporary tables and full-text search. |
| Webhooks | The raw request body is preserved, so a signature can be verified, a payment notification for instance. |
| Realtime | WebSocket connections, broadcasting across workers, and channels a browser subscribes to with a short-lived, scoped token. Messages are encrypted at rest. |
| Domain | Your own domain, with its certificate issued and renewed (see below). |
Asking for one
Describe the result, not the stack. For example:
We rent three meeting rooms. Build a booking page where clients pick a slot and pay a deposit, and a screen for us that shows today's bookings as they come in.
The employee writes the interface, the server code and the database schema, publishes the project and gives you the address. Changes are asked for in the same conversation: the application is updated at the same address.
What this is typically used for: a booking page that confirms when the payment arrives, an order tracker that follows delivery updates, a quote calculator that keeps every request, event registrations that close at a set number, a stock register the team updates live, a search over product sheets.
Keeping the data safe
The database belongs to the project and is isolated from other projects. The CLI can take a consistent snapshot, check integrity and swap the database atomically, so a restore never leaves a half-written database live.
Realtime performance
Since v2.8.1 a WebSocket connection keeps one warm worker for its lifetime: the function loads once, every event of that connection runs in the same process, in order, and module-level variables stay set. Throughput went from about 2 messages per second to 106, and a warm call running three SQL statements takes about 6 ms. Activating a new version starts the next event with fresh state; past a ceiling of 256 warm workers by default, events fall back to one process per event rather than failing. Two workers on the same project can write to the database at the same time.
Your own domain
A three-step assistant in the dashboard puts a published site on your own domain: enter the domain, add the DNS records it gives you, verify. The certificate is issued and renewed automatically, and a failed configuration is rolled back.
From the command line: domain add, domain list, domain verify,
domain remove.
A site served under /web/<slug> shares the platform origin, which can expose
tokens kept in browser storage. A site on your own domain does not have this
problem: prefer it as soon as a site handles sensitive data.
The workspace view
All sites, across employees: Websites.
The default
No site published, and no web-publish skill on a new employee.