Navigation
ELOWEN · Documentation

Last updated: October 27, 2026

Browse documentation · Sites
Computers, terminal and Git

Sites

Give an application that already runs in a Project its own web address, and decide who may open it.

Open Sites in the main navigation to see the addresses you own and the ones shared with you. Every Project also has a Sites tab, and the sites plugin does the publishing.

Each entry shows the address, Project, target port, last publish, visits, access and named guests. A page picture appears once the browser capture service is installed, and a failed new capture keeps the previous picture.

Publish a Project application

  1. Start the application inside a managed Project or on a paired computer and note the port it listens on.
  2. Ask the agent to create a Site for that port and publish it. Sites checks that the application answers before the address goes live.
  3. Open the address from the Sites list or the Project tab.

Sites does not copy, build or start the application. If the Project or service stops, the Site stays listed but cannot answer until the application runs again.

Publishing is a proxy to the Project service, which must listen on 127.0.0.1 at the selected port. The full walkthrough is in Publish an application from a Project, and a temporary address without publishing is described in Preview without publishing.

Addresses that were published from files before this release serve a maintenance page until you republish them from a running service. See Sites in maintenance.

Admin: Computer Project members may publish from their computer, and an administrator must also be a member to do so. Keep the computer connected with elowen connect; while it is offline its Site stays published and shows the unavailable response.

Note: If publishing asks for a newer client, update the Chetty CLI on that computer and reconnect it. Host Projects cannot publish Sites.

Who can open a Site

A Site is private to its owner, open to Project members, open to any signed-in account, or public. New Sites start from the instance default.

A Site never becomes public on its own: someone must confirm Make public. If Allow public sites is off, the public option is unavailable. SiteShare and SiteUnshare add or remove a named account whatever the visibility says.

Visibility governs the published address only. Access to the Project, its source and its files stays with Project access.

Who can open your website explains the four levels and what removal does.

Delete a Site

Deleting a Site removes it from the list and starts removal of its address and any preview. Deleting the Project removes all of that Project's Sites, previews and retained release files.

The Project confirmation lists the affected Sites and addresses. Custom-domain bindings are detached, but your DNS records are left untouched. If cleanup cannot finish immediately, Chetty completes it after a restart.

Add a custom domain

  1. Open the Site's details and select Add domain.
  2. Create the TXT record and the routing record that Chetty shows, at your DNS provider.
  3. Select Check again until ownership, routing and HTTPS are ready.
  4. Select Make primary when HTTPS is ready. The generated Chetty address stays available as a fallback.

A Site can hold up to 10 custom domains, and each must be one complete hostname without a scheme, path, port or wildcard. Root domains need ALIAS or ANAME records when your provider offers them, otherwise the address records Chetty shows; for a subdomain, CNAME is usually simplest.

For example, connect app.example.com, add the displayed TXT and CNAME records, then make it primary once HTTPS is ready.

While setup is open, Chetty checks the domain every 20 seconds and shows the countdown and the current step. Checks stop once the domain is connected or removed, or when you close the window, and a connected domain shows its certificate validity instead of instructions.

The step-by-step version is in Connect a custom domain.

Sites tools

SiteCreate, SitePreview, SitePublish, SiteGet, SiteList, SiteUpdate, SiteShare, SiteUnshare and SiteDelete create, preview, publish, inspect and manage Sites. SiteDomainAdd, SiteDomainCheck, SiteDomainSetPrimary and SiteDomainRemove manage custom domains.

SiteList and SiteGet only read and are safe to use while Chetty plans work. File publication and SiteRollback are gone, so a Site always points at a running application.

Install and configure Sites

  1. Install Sites from Settings → Available plugins. The registry lists its minimum Chetty version.
  2. Enable a plugin that provides the Sandbox control first; Chetty refuses to enable Sites without it.
  3. Choose who may publish under Who may publish in the plugin settings.

Sites is not user-grantable, so there is nothing to assign per account. Restricting publishing does not stop people from opening Sites shared with them.

Enabling, disabling, installing or changing a plugin restarts Chetty, and the settings screen says that the change is saved and Chetty is restarting. Administrators are also alerted when the Sites worker, the HTTPS gateway or a published address stops working; each alert clears when the problem is resolved.

Publishing settings

The publishing groups control who can publish, the starting visibility of a new Site and how many Sites one account may hold. That last limit is 20 by default.

All four values are listed in Configure Sites.

Reverse proxy settings

Upload size, response size, the inactivity and connection timeouts, protocol upgrades such as WebSocket, gzip compression and the HTTPS policy apply to every Site served through the proxy, with no per-Site override.

The defaults and valid ranges are in Configure Sites.

Visitor access and certificates

Sign-in validity decides how long a visitor stays signed in, and access removal still applies immediately. A contact email is required before a certificate can be issued.

The DNS destination must reach this Chetty host directly; an external proxy needs its own TLS. See Configure Sites for the exact fields.