Sites

Sites hosts static HTML files and ZIP archives for reports, prototypes, and documentation previews. A server-side application is not necessary.

Choose who can access a site

New sites from your user account are private by default. Administrator access does not give ownership rights.

The owner can replace content, extend expiration, delete the site, or change visibility. Public content can contain copies that remain outside Lifecycle after you make the site private. Sites has no email invitations or viewer or editor roles.

Upload from the UI

1. Open Sites.
2. Select Add site.
3. Select an HTML file or ZIP archive with the required entry file.
4. Add an optional display name.
5. Select Private or Public.
6. Examine the visibility and file.
7. Select Upload private site or Publish site.
8. Open the returned URL.
9. Make sure that the content and assets are correct.

My sites shows sites that you own. Public shows public sites. Search matches the site name or ID. Search and pagination do not expose other users’ private sites.

From an owned site’s actions menu, you can replace content, change visibility, or delete it. The visibility dialog requires confirmation before publication. When you change visibility, the site ID and content URL stay the same. New requests to a private site require owner access.

Upload a directory with the CLI

The CLI accepts a ZIP, HTML file, or directory:

Omitting --visibility uses the server’s default for your credentials. With user sign-in, that default is private. An explicit public upload requires confirmation or --yes. The CLI uses user sign-in and has no dedicated API-key input.

For a directory, lfc creates a ZIP locally. It excludes .git, node_modules, cache directories, and coverage output. Use .lfcsiteignore for additional exclusion patterns. Before an upload, the CLI checks the deployment’s upload policy and allowed visibility.

Prepare and replace content

• Build the site locally.
• When your site generator supports relative asset URLs, use them.
• Include the entry file that the upload policy requires.
• Remove credentials, internal data, source maps, and unnecessary output.
• Before publication, check navigation and assets.

A content replacement or visibility change preserves the current content URL. The API’s openUrl opens the current site through Lifecycle. The contentUrl identifies the current content host. Neither URL grants access to a private site.

Deletion or expiration stops new content requests. Deletion cannot be undone. Content already downloaded or displayed can remain on a user’s device.

Private access and logout

Sign in as the owner to open a private site. Browser access expires within five minutes and no later than the authorizing JWT. If content stops loading after access expires, reopen the stable Site link. A valid user session can obtain access again after an ownership check.

Ordinary UI logout does not immediately revoke issued access. There is no guaranteed fixed cutoff measured from logout. An unrelated signed-in user cannot open your private site.

Private content compatibility

Private sites block Web Workers, SharedWorkers, and new service workers. Features that require these workers, including some offline features, do not work. Use a site build that works without browser workers. Private sites also block display inside an iframe. If a site was public, a service worker installed in a visitor’s browser can remain after you make it private. For sensitive content, upload a new private site instead of changing the public site’s visibility.

Expiration

When the operator enables Sites TTL, new sites receive the configured expiration. The owner can extend expiration through the CLI or API. When TTL is disabled, a site can have no expiration. Use the displayed expiration instead of assuming a fixed number of days.

API access

Management routes require authentication and the applicable scope. A scope permits an operation only when the caller also has the required ownership.

Capabilities contain enabled, upload, defaultVisibility, allowedVisibilities, and canCreate. Capabilities do not expose administrator configuration or storage credentials. List requests accept view=mine|public|all, q, page, and limit. Results use the pagination fields items, total, current, and limit.

Create and content-replacement requests use multipart/form-data. Creation accepts optional visibility. A personal API key defaults to private sites. A service API key can create only public sites and defaults to public. The service key owns its sites through that exact key identity.

Use an existing API key with sites:write in LIFECYCLE_API_KEY. Set LIFECYCLE_URL to your Lifecycle API origin. To upload an HTML file with the key’s default visibility, run:

Visibility changes require JSON fields visibility and expectedAccessRevision. For replacement, send expectedAccessRevision and expectedContentRevision as multipart fields. Delete and extend requests accept expectedAccessRevision as a query parameter. Older replacement clients can also receive 409 after a concurrent change.

For 409, fetch the site again before you decide whether to retry. Do not automatically overwrite another change. Use permissions to show available actions and currentRole to identify ownership. Public results hide unrelated creator and updater identities.

See API overview and API keys.

Troubleshooting