Site settings¶

This guide describes the settings that site administrators can see or change in the Hub. The available fields depend on the site type, site status, and your permissions. Platform administrators manage some settings.

Open your site in the Hub. The Overview, Access, and Configuration sections contain the settings described here. You need to be a site administrator to edit them, and the site must be enabled. If a setting is unavailable, contact a site or Hub administrator.

Select the edit icon beside a setting, make the change, then save it. Some changes trigger a site update and can take time to appear.

When you create a site, the form offers an optional Site Template selector. Templates are presets provided by the platform deployment or by a platform administrator; if the selection doesn't offer any, sites are created from the plain defaults. A template presets the form: it fills fields you left empty, keeps values you typed yourself, and can't set fields reserved for platform administrators, such as the owner or the site type. Check the presets before you create the site.

Overview¶

The Overview section contains the site's address, visibility, storage, retention, and description.

Changing the space or site name changes the site URL. Update bookmarks, integrations, and links that use the old URL.

Private and public sites¶

Use a private site while content is being prepared or when it must be restricted. Private sites require at least one allowed user or group. Public sites can be read by anyone, but you can still restrict individual paths with .htpasswd; see Managing access.

Site administrators can request publication from the site's Overview when the request option is available. A Hub administrator can change the site type. The deployment may restrict public sites that use a custom application.

Storage quota¶

Site administrators can increase the quota up to the maximum set by the service. They cannot reduce a quota after it has been increased. If the current quota is at the service maximum, a Request option may be available to ask for more storage. Availability depends on the deployment.

Retention date¶

Keep this date current. The service sends reminders as it approaches. The site may be archived after the date passes and deleted later. By default, the service archives an expired site after 183 days and deletes it after 365 days; the service administrator can change these intervals.

Use the date control to set a new date, or use the one-year extension action if it is available. Site administrators cannot set a date more than one year ahead; ask a Hub administrator if you need a longer period.

Access¶

The Access section controls which people can administer or view a private site:

• Administrator Users and Administrator Groups can manage site content and settings.
• View-Only Users and View-Only Groups can view a private site but cannot administer it. These fields are shown for private sites.

Use groups for long-lived team access where possible. A private site needs at least one allowed user or group. Public sites do not use the view-only list to decide who can read the site. See Managing access for access rules and path protection.

Configuration¶

Tokens and temporary links¶

• Master Token grants full administrative access to the site's content. Treat it like a password. Regenerating it invalidates previously generated HTTP access tokens, signed URLs, and session URLs.
• HTTP Access Tokens grant time-limited site access. Choose read (r) or read/write (rw) permission, add an identifier, and set an expiry date. The default expiry is 90 days. The token history lists tokens that have been used at least once. You can revoke a token from the list. Expired entries are removed from the history 7 days after the token's expiry date.
• Signed URLs provide time-limited access to a specific URL.
• Session URLs provide time-limited access to a folder in the browser, with optional write access.

Signed and session URL controls are shown for private sites. Anyone with a token or link may use the access it grants until it expires or the master token is regenerated. See Signed and session URLs for safe sharing for link permissions, scope, and sharing advice.

Custom error pages¶

Custom Error Page Handling controls the pages shown for HTTP errors. When NGINX default error pages are enabled, you can override selected codes with redirects. Each redirect has its own row, added with Add redirect: the status code, such as 404, and its target, such as /errors/not-found.html. The path must be part of your site, or you can provide an HTTP or HTTPS URL. Custom redirects apply only when NGINX default error pages are enabled. Otherwise, the service uses its standard error pages. The accepted codes are in the 300–599 range.

Response headers¶

These settings affect browser behaviour. They do not replace site access controls.

CORS controls browser cross-origin access; it does not grant a user access to a private site. The Hub shows which domains the service trusts by default. Add extra hostnames as individual rows in the CORS dialog. Do not include a URL scheme or path.

Applications¶

• Enable Built-in Applications selects optional applications that the service makes available for your site. The list depends on the deployment. Essential applications are managed by the service.
• Custom Application Deployment can run a container image as part of your site. The fields let you set the image, environment variables, proxy mode (HTTP proxy or FastCGI), and URL path (Site path prefix or Root (/)). Those three settings take effect once the site has an image, and the dialog says so while the image field is empty. The page shows the state of the application while the site restarts. The service may restrict which image registries are allowed. Public sites cannot use custom applications unless the service allows them. The service rejects a new image on a public site. When a public site already has an image, the next change to that site makes it private, and the Hub asks you to confirm this change. A custom application on a public site answers read-only requests only: the platform rejects POST, PUT, PATCH, and DELETE with 403.

See Custom applications for the container contract, examples, and troubleshooting. Environment-variable values are part of the site configuration: site administrators can read them, and platform backups store them.

Monitoring and resource limits¶

These settings are managed by a Hub administrator:

• Operational Monitoring Alerts includes the site in the Hub's operational health checks. It does not define a service-level objective.
• Application Resource Limits selects the normal, medium, or high CPU and memory limit profile for applications on the site. The profile sets limits; it does not guarantee that the cluster has that capacity.

Contact the platform team if monitoring or a different resource profile is needed.

Related guides¶

• Managing access
• Publishing content
• Signed and session URLs for safe sharing
• Day-to-day operations