Sharing a single note usually just takes one link. But when what you're publishing is a tutorial, a series, or project documentation, dozens of standalone links quickly become unmanageable: readers can't find a table of contents, and the relationships between pieces stay invisible.
Abox Note's "publish site" feature turns a set of content within a space into a static website. The author picks the scope and a theme, previews the site, and then either exports the static files or deploys them through the app's guided flow. Readers end up on an ordinary webpage—no need to install Abox Note.
More importantly, the exported site doesn't require Abox Note to keep running. Authors can keep the files themselves, or choose their own static hosting. The notes app helps content take shape, but it doesn't have to be the only place that content lives.
Starting from a space, not copying page by page
Turning a set of content into a website takes more than converting each Markdown file into HTML one at a time.
A tutorial needs previous/next navigation, documentation needs a table of contents, pieces may link to each other, and images and other assets need to travel along with them. The site also needs a consistent theme, so the homepage, listing pages, and article pages all feel like one reading space.
Abox Note uses a "space" to define the overall scope of what gets published, with further filtering available on top of that. That way, an author can keep a project, a tutorial series, or a set of public notes within a fairly stable scope, instead of re-selecting every single piece each time they publish.
The current basic flow looks like this:
- Choose the space and content scope to publish;
- Pick a theme and preview the site;
- Check navigation, links, and how pages render;
- Export the static files, or continue on to deployment.
Preview isn't a decorative last step. It lets the author check the site from a reader's point of view before going public, rather than discovering broken navigation, links, or styling only after everything's already uploaded.
Why "static" doesn't mean "bare-bones"
"Static" describes how the site is delivered, not how simple the pages look.
The export produces ordinary website files—HTML, styles, scripts, images. When a visitor opens a page, there's no connection to the author's note database, and nothing waiting on Abox Note to generate content in the background. As long as the hosting platform can serve those files, the site runs on its own.
This fits blogs, public notes, user manuals, and project docs well. Pages can have themes, navigation, and internal links, and they load normally in any browser. It doesn't fit sites that need login, real-time collaboration, or complex server-side queries—those still need a dynamic backend.
Static publishing solves "how do I ship content I've already organized," not "turn a notes app into a site builder for every possible use case."
Why preview comes before export
What an author really cares about: will the site they saw in preview keep the same structure once it's exported?
Abox Note has preview and export share the same page-resolution logic. Themes, navigation, internal links, and assets already work in preview; export then packages the reachable pages and resources into static files the same way. That cuts down on the "it looked fine in preview but turned into something else after publishing" problem.
The trade-off is that a larger site needs to process more pages step by step; if one of those pages can't be generated correctly, export can stop rather than quietly ship a site that looks complete on the surface but is missing pages underneath.
For an author, that strictness is worth it. A site isn't finished just because the homepage opens—every entry in the table of contents deserves a clear outcome.
Export and deploy are two separate things
Export gives you static files you can save and move around; deploy puts those files on the internet. Keeping them separate means an author isn't locked into any one hosting provider.
You can use the deployment path built into the app, or take the exported result and publish it with your own domain and hosting. Even if you switch tools or services later, the site files you've already generated remain plain, ordinary web content.
That's the key to static publishing not locking content inside an app. Openness isn't just "you can export the Markdown"—it also means the finished, public result can keep existing outside the editing environment it was made in.
A single link is still the right tool for a quick share; a space-based site is the right tool for a structured, ongoing body of content. They're not a lesser and greater version of the same feature—they answer two different questions: "how does one piece go out," and "how does a body of content keep existing over time."
A notes app can be the workbench where content takes shape before it reaches the internet—it doesn't have to be the internet's final destination.