Publish a wiki space as a public website, and let visitors ask it questions

Folio 0.2 can serve a wiki space as a public website. The pages stay in the space your team edits every day, and anyone can read them without an account. Product documentation, a candidate handbook, a policy that customers must be able to find: the text already lives in the wiki, and the alternative is a second tool and two copies that drift apart. Here there is one copy.

Below: what publishing does, how an admin turns it on, the shared Folio AI key, the question box for visitors, and the limits.

What publishing does

A space is private, open to every signed-in person on your Folio, or now public. A public space is a read-only website: the page tree, the pages (tables update live), search inside the space, images and attachments. Nothing is copied. The site is the space, and the publishing settings live in the database, not in your Git repository. Visitors cannot edit or comment, and signed-in people keep the roles they had. Pages restricted with a lock, the assistant's rule pages and templates are never published.

Three kinds of address

• A path on your Folio, live as soon as the space is public.
• A subdomain, such as handbook, under a parent domain that the operator has set aside for sites.
• A custom domain, such as docs.example.com, which needs a DNS alias and a route in your proxy.

What visitors can do

Two abilities are off until an admin switches them on. A Download button saves a page as Markdown, PDF or Word. An Ask AI about this space button opens a panel whose answers come from the pages of that space only.

That limit is built in and not requested of the model. The assistant runs in read-only Ask mode as a built-in user called Public visitor, whose rights stop at the public pages of one space. It cannot see other spaces, locked pages, templates, page history or people's names, and no tool that writes is offered. The space's own assistant rules still apply. Space admins see these conversations in assistant analytics under that name; the onboarding post shows the screen.

Rate limits protect your key. By default one visitor address can ask 20 questions an hour, a whole site 200, and one address can download six PDF or Word files a minute.

How an admin turns it on

• Open the space menu in the sidebar and choose Publish as website.
• Set Who can read this space to public, and confirm that anyone on the internet will be able to read it without signing in.
• In the Website block, add a subdomain or a custom domain if you want one, tick the two checkboxes (downloads, asking Folio AI) as you need, and press Save.

Only an admin of the space or instance can do this, from a signed-in browser, so an access token cannot publish a space. Switching the space back to instance-wide or private takes the site down within about ten seconds and keeps its settings.

The shared Folio AI key

Folio AI runs on a Cursor key, and until 0.2 every person connected their own. Now an instance admin can store one key for the whole instance, and a space admin one for a single space (Folio AI key in the space menu). A key is stored encrypted and never shown again; the screen shows its name, its Cursor account, and who set it and when.

Folio takes the first key it finds: your personal key, the space key, the instance key, then a key set on the server itself. Personal keys are allowed by default. An instance admin can switch them off, and then everyone uses the shared key. Assistant settings show a Key source line that says which one is in use.

Visitors have no personal key, so their questions run on the space key, then the instance key, then the server's key. With none of them the panel says Folio AI is not set up for this site yet.

What the operator sets up

The path address needs nothing beyond a configured public address for the instance. The other two need the proxy in front of Folio.

• Subdomains. Set aside a parent domain for sites, such as sites.example.com, not your company domain: a wildcard would catch your other services. Add a wildcard DNS record and a wildcard certificate, and have the proxy pass those hosts to Folio with the original host name and live connections allowed, or tables will not update.
• Custom domains. The owner of the domain adds a DNS alias to your Folio's host name, which the publish dialog shows. The proxy accepts that host, routes it to Folio and holds a certificate for it.
• Behind a proxy, tell Folio so. Otherwise every visitor looks like the proxy, and the limits are shared by all of them.

Where it stops in 0.2

• No sitemap, no robots file, no noindex. Search engines may index the pages. To keep one out, lock it or unpublish the space.
• A lock is not inherited. The child pages of a locked page stay public. Lock each page that needs it, and look through the tree before you publish.
• Downloads are a convenience, not a guard. The checkbox controls the button. The source text of a public page can also be fetched as a plain file.
• Rate limits are per server process. They sit in memory, reset on restart and do not add up across processes, and they cover only questions and PDF or Word downloads. Put a proxy or CDN in front if you expect a rush.
• Questions go to Cursor. The question and the pages the assistant reads leave your server for Cursor, the only assistant provider for now.
• Visitors are anonymous. A form on a public page cannot be filled in, and on a subdomain or custom domain a visitor stays anonymous even when signed in on the main address.

Try it

The public demo has publishing and the assistant switched off, so it cannot show a published site. To see one, run Folio yourself and start with the install guide. The code is on GitHub under the MIT license, and the full list of changes in 0.2 is in the release notes.

All posts