Sites and web services

A project’s site

A container project with a domain has a site: its domain, over HTTPS, leads to port 3000 of the project’s container. The project’s application must listen on that port; ProjectStart doesn’t build or run it. The project page shows the site’s link. A project without a repository has no domain and no site (see Projects).

A container on a remote server can have a site too, served through ProjectStart or by the server itself (see Remote hosts).

Web services

A project in a container can serve web pages besides its site (a desktop in the browser, an editor, a notebook, a dashboard), each at a name of its own over HTTPS. Nothing else in a project is reachable from outside: ProjectStart opens no other ports.

• Names: a web service is a short name (lowercase letters, digits and hyphens), the container’s port it is served from, and an optional one-line note. It is reached at https://<name>.<container>.<base domain>: for example vnc.fedora.projects.example.com is the vnc service of the container fedora. www, and a name already taken in the project, are refused.
• DNS: one record, *.<base domain> pointing at the host, covers every project’s services, as long as <container>.<base domain> has no record of its own. A project with a site needs *.<container>.<base domain> too; the Web services tab says so when it is missing.
• The list: a project’s Settings › Web services tab lists its services: the name, its address as a link, the container port and the note. Add web service (a name and a container port) adds one that is already running; each can be changed or removed. A change takes effect at once and is a History entry. Moving the project to the Trash removes them; renaming the container moves their names with it.
• Asking an agent: Run a new web service in an agent’s Actions asks the agent to set something up (“Run an RDP desktop”, “Run VS Code in the browser”, “Run a Jupyter notebook”). The agent starts it, asks you only whether the address it picked is fine, adds it, and replies with the link. Its card in the chat links to the address and has Remove.
• Projects running directly on a remote server have no web services.

Linked projects

Agents of different projects can talk to each other only when you have linked their two projects.

• Linking: a project’s Linked projects panel (in its Settings › Details) lists the projects linked to it. Link a project links another active project; Unlink removes a link, after you confirm. A link joins two projects both ways, and only directly: when A is linked to B and B to C, A’s agents can’t reach C’s. Agents can’t link projects themselves. Each link and unlink is a History entry.
• In the sidebar: each link has its own colour, and a linked project’s row shows a small mark of that colour for each of its links, so two rows sharing a colour are linked. A link mark shows how many projects the row is linked to and names them when you point at it, highlighting their rows; clicking it opens the Linked projects panel.
• In the chats: linking or unlinking puts a card in every agent’s chat of both projects: Linked with or Unlinked from the other project.
• Addressing: agents list a linked project’s agents as name@project, using the project’s name as you set it (for example Master@Shop), so you can tell an agent exactly whom to talk to. In the chat, a message from another project shows its sender’s project and links to the sender’s chat.
• What crosses: messages and the files sent with them, files a linked project’s agents read from a working folder, and the text of chats they read. No tool output, tasks, questions, logins or write access cross. Each project’s container or server, logins and secrets stay its own.
• Trust: linking is your decision to let the other project’s agents ask this project’s agents to do work and read their chats and working folders. Agents are told never to send secrets to a linked project.
• Unlinking, trashing or purging a project stops its messages and reads at once.