Skip to main content

Making Use of Publicly Served Folders

Public Hosting, also referred to as Publicly Served Folders, gives any folder on your Files.com site a public HTTPS URL. You can serve any file type, from documents and media to software packages and marketing materials. The same folder can also host fully functional web applications and dashboards. Public Hosting serves HTML, CSS, and JavaScript; the code executes in the visitor's browser. No server-side code runs inside the hosted folder.

What You Can Host

Publicly Served Folders serve any file type over HTTPS. Common content includes:

  • Documents and PDFs: contracts, forms, manuals, compliance documents, onboarding kits, and regulatory filings.
  • Images and media: product photography, logos, brand assets, promotional images, and graphics.
  • Video and audio: training videos, product demos, podcasts, webinars, and recorded presentations.
  • Software and downloads: installers, update packages, firmware, SDKs, and release archives.
  • Spreadsheets and data files: price lists, product catalogs, data exports, and reporting templates.
  • Marketing materials: press kits, campaign assets, event guides, and digital catalogs.

The same folder can serve interactive content:

  • Static HTML pages with embedded JavaScript, no build step required.
  • Single-page applications built with React, Vue, Angular, or Svelte: compiled locally and uploaded to a folder. The app bundle is static; the app itself can be dynamic via external API calls.
  • Jamstack sites that fetch live data from external APIs at runtime and render it in the browser.
  • Embedded dashboards using charting libraries such as Chart.js, D3, or Observable Plot, pulling data from a BI tool or data warehouse API on page load.
  • AI-generated reports and dashboards: an LLM or data pipeline generates an HTML page on a schedule and uploads it to a Publicly Served Folder via the Files.com API. Anyone with the URL sees the latest version at the same address every time.

Jamstack applications fit this model well: static assets are served from the hosted folder while dynamic content is fetched from external APIs at runtime in the browser. If your app requires server-side rendering or per-user session state beyond the Files.com login gate, that logic needs to run on a separate server. Public Hosting can still serve the static assets for such an application while the server-side layer lives elsewhere.

Publishing AI-Generated Content Directly from Your AI Tool

AI platforms increasingly generate reports, dashboards, websites, knowledge bases, and other artifacts that need to be shared with customers, partners, or employees. By directing AI tools to write output directly to Files.com, organizations can instantly publish generated content through Public Hosting. Access can be fully public, password-protected, or governed by existing site authentication with SSO and two-factor authentication, allowing AI-generated content to be distributed securely without deploying additional web infrastructure.

The Files.com MCP serverExternal LinkThis link leads to an external website and will open in a new tab connects Files.com to AI tools such as Claude Cowork, Claude Desktop, and ChatGPT Desktop. When that connection is in place, an employee can ask their AI tool to generate a dashboard, report, or document and have it published to a Publicly Served Folder in the same conversation, with no manual download or upload step.

The workflow is straightforward. An employee asks their AI tool to build a dashboard or generate a report. The AI writes the content and uses the Files.com MCP to upload the file directly to the designated hosted folder. The result is live at the folder's public URL immediately. Other team members access it at the same stable address, gated behind site login so only staff can reach it.

Publishing Content for Internal Teams and Employees

Configuring a folder to require site login makes its content accessible only to users already registered on your Files.com site, without exposing anything to the open internet. Access is governed by your existing site login, including SSO and two-factor authentication. No separate identity system is needed.

Use this method for:

  • Policy documents, SOPs, runbooks, and compliance materials that employees need at a stable internal URL without VPN or a separate intranet.
  • Onboarding kits, training materials, and HR guides that stay current because they update in place.
  • Executive and operations dashboards showing financial, pipeline, or headcount data, generated automatically and uploaded to a login-gated folder on a schedule.
  • AI-authored summaries (weekly briefs, budget reports, customer health snapshots) written to a login-gated folder and accessible to the team without distributing attachments.
  • Product and design prototypes: single-page apps built for internal review before any public release.

Any active user already on your Files.com site can access the content the moment they sign in. No additional provisioning is needed. Removing a user's account revokes access immediately.

When the folder serves a web app with its own index.html, disable index pages. Index pages show a directory listing, which is useful for file distribution but unnecessary and potentially confusing for app folders.

Content for Partners and B2B

Partners are typically Files.com users. Configuring a folder to require site login gives each partner organization access to the content their relationship entitles them to, with individual credentials, SSO, and two-factor authentication all handled through your existing Files.com site. No shared passwords, no separate identity system.

Use this method for:

  • Onboarding kits, compliance documents, integration specs, and technical resources shared with vendors or distributors at a stable URL.
  • Co-branded assets, product data feeds, pricing tools, and reseller materials updated centrally on Files.com and accessed through a dedicated URL.
  • AI-generated account health reports or partner dashboards written to a login-gated folder on a schedule. Each partner sees their own data at a stable address without a dedicated portal build.
  • Staged releases: share a preview with specific partner users through a login-gated folder, then open access more broadly when the content goes live.

If a partner contact does not yet have a Files.com account, create them as a Partner. Partners get an isolated space within your site with their own users, credentials, and root folder, giving external organizations self-service access without exposing your internal environment.

Password protection is better suited to the External Users and Customers pattern below, where the audience has no Files.com account and the content is genuinely public-facing with light access control.

Content for External Users and Customers

Open folders (no password, no login) serve content meant to be publicly accessible. The URL is the only access control: use a descriptive URL for broad access, or an opaque token-style URL for content that is public but not meant to be easily discovered or indexed.

Use this method for:

  • Product manuals, warranty documents, return forms, and troubleshooting guides your customers can reach without an account, reducing inbound support volume.
  • Healthcare intake forms, patient education materials, and appointment preparation guides at clean, memorable URLs.
  • Legal and professional services firms publishing standard contracts, disclosure forms, and regulatory documents for client self-service.
  • Software distribution: installers, updates, and release packages with stable versioned URLs. A /latest/ path can always point to the current release via an edge platform.
  • Customer-facing interactive tools: a mortgage calculator, product configurator, or self-service eligibility checker published to an open folder and updated by uploading a new build, with no deployment pipeline required.
  • AI-generated public reports or dynamically produced content pages served directly from a Publicly Served Folder.

Enable index pages when visitors need to browse folder contents. For folders serving a web app with its own index.html, index pages are not needed. Use CORS headers when the hosted content needs to be fetched by JavaScript running on another domain.

Content for Marketing and Brand

Press contacts, agencies, event vendors, and prospects need access to assets and content without creating accounts. Open Public Hosting folders serve this audience well.

Use this method for:

  • Press and media kits: logos, product imagery, executive headshots, and brand guidelines served from a stable URL shared in press releases and media outreach.
  • Campaign asset libraries giving agencies and production partners direct HTTPS access to approved images, videos, and copy decks, replacing email attachments and consumer file-sharing services.
  • AI-generated campaign briefs, market summaries, or audience reports published to a shared URL and updated each cycle without redistributing files.
  • Event hubs sharing speaker bios, presentation templates, venue maps, and attendee guides.
  • Digital product catalogs updated once on Files.com and immediately reflected for everyone with the link.

For brand consistency across multiple domains or regions, pair Public Hosting with an edge platform to serve the same content under different domain names or localized URLs.

Custom Domains

By default, Publicly Served Folders are served under [subdomain].hosted-by-files.com. To serve content under your own domain (such as assets.yourcompany.com or apps.yourcompany.com), pair Public Hosting with an edge platform such as Cloudflare Workers. The edge layer rewrites requests from your domain to the underlying hosted-by-files.com URL transparently and caches content at the network edge, reducing repeat requests to Files.com.

For large static assets such as video or high-resolution images served at scale, a CDN in front of your Publicly Served Folder handles delivery performance better than Public Hosting alone.