Workspace

A workspace is a directory holding one or more Noemata projects — each with its own noemata.json, database, and set of integrations. A project’s files (frames, pages, templates, Markdown) live in its file store: virtual, versioned, and searchable, readable directly on disk as ordinary files. The noemata CLI reads a project’s config and starts the services it needs. noemata publish sends changes from a checkout on disk to the deployment, and noemata fetch writes the deployment’s changes to the checkout.

This section covers the mechanics behind that: how projects are laid out, where files actually live, what happens when disk and the store disagree, and how you move content deliberately between them.

In this section

• Projects — one project per directory, or several registered under one workspace.
• Storage modes — fs.local and fs.remote: where the deployment and the drafts are stored.
• Publishing & fetching — moving content between disk and the store by hand.
• Resolving conflicts — what it means for disk and the store to disagree, and how to settle it.
• Ownership & version control — what’s gitignored, what’s committed, and who owns installed content.

For the conceptual pitch — why everything is a file — see The file store.

Browser file cache

The browser retains file contents in IndexedDB with a 64 MiB budget per origin. Entries larger than 4 MiB bypass retention. These budgets estimate content and key sizes; browser storage overhead is additional. Eviction removes the least recently accessed entries across all workspace scopes.

The authenticated startup response supplies a stable workspace scope. Frame reads use paths and hashes from the existing authorized listing to check (scope, path, hash) in IndexedDB. Misses fetch current contents through the existing HTTP API and store the returned revision. Reads without a known hash always fetch current contents. The cache adds no metadata map, refresh loop, or extra metadata requests. Server API requests and CLI commands do not use this browser cache.

Cached files are plaintext browser storage, scoped to the tenant, namespace, and backing store. Scope remains stable across users and ordinary restarts; it does not authorize access. Login and logout request deletion of persisted contents. Clear the site’s browser storage to remove retained files manually. This cache does not provide an offline workspace or protect files from someone with access to the browser profile. If IndexedDB is unavailable, reads use HTTP.