Public Hosting Use Cases

Public Hosting serves files and static web content through HTTPS URLs. It fits software downloads, manuals, media libraries, and browser-based reports or tools. Select the audience and access controls before publishing the folder.

Public Documents and Assets

Use an open hosted folder for material intended to be publicly accessible, such as product manuals, press kits, release packages, or event resources. A descriptive URL makes the content easy to distribute. An opaque URL may be harder to discover, but anyone who obtains it can still access an open folder.

Enable index pages when visitors should browse its contents. Otherwise provide direct links to the files. Disabling directory listings does not make those direct file URLs private.

Static Applications and Generated Reports

Public Hosting serves HTML, CSS, JavaScript, and other static assets. JavaScript executes in the visitor's browser and can call external APIs that permit it. Server-side code, private application logic, and server-side credentials belong on a separate system.

A reporting process can upload a new HTML report to a stable path. The Files.com API, CLI, or an AI tool using the MCP server can supply the file. Review the generated output and its audience before placing it in a hosted folder: publishing a new file can make it immediately available through that folder's URL.

When serving a custom HTML page, link to the page's actual filename. With index pages disabled, requesting the folder itself fails; the presence of an index.html file does not change that behavior. See Index Pages.

Content for All Site Users

The site-login requirement lets you limit hosted content to active users registered on your Files.com site. It can serve general training materials or a runbook intended for every such user.

This is a site-membership gate, not enforcement of the underlying folder's permissions. Active Partner Users are also site users. Do not use this option to promise an employee-only audience on a site containing external users, or to keep one Partner's dashboard private from another Partner.

For files whose access must follow individual, group, Workspace, or Partner permissions, use authenticated file access. Partner File Exchange describes that arrangement. Share Links offer a separate set of controls for a specific exchange.

Shared Password Access

A hosted folder can require one shared username and password through HTTP Basic authentication. Everyone using that password has the same hosted access; it does not identify each visitor as a separate account. Site login and password protection can both be required.

Use the method whose audience matches the material. For content that needs individual access management, use accounts or an appropriately configured sharing feature instead of distributing a common password.

Domains, Browser Access, and Delivery

An Additional Custom Domain can provide your own hostname. An edge platform can add routing or caching when required. Public Hosting itself is not a CDN; consider a CDN for large-scale static-asset distribution.

If JavaScript on another website must read the hosted content, configure CORS. For password- or login-protected content, name the trusted origins rather than enabling unrestricted cross-origin reads. CORS governs browser scripts' access; it does not replace authentication or prevent ordinary direct downloads.

Test the published URL as an anonymous visitor and as representative site users before distributing it. Check direct file URLs as well as directory listings, and verify the effect of removing the hosting setting when the material should no longer be available.