See the product in action. ― Book a free demo →
All guides
Browse all guides
Documentation
Developer tools

Build and publish with the Neopress runtime

Understand supported page code, CMS and form bindings, and the separate steps that make a draft visible to visitors.

Neopress development connects page code to managed site resources. A reliable workflow starts by reading the runtime contract, creating the required resources, compiling the page, reviewing pending changes, and checking the published URL.

Read the runtime contract first

Ask your MCP assistant to call neopress_get_runtime_contract before generating TSX, collection schemas, dynamic pages, references, or forms. Use the returned contract together with the current CLI help. It describes allowed imports, injected data, and publication requirements.

The shared site layout owns the header, footer, global CSS, and 404 content. A page component supplies that page's content. Keeping these responsibilities separate avoids duplicate navigation and inconsistent site-wide styling.

Work within the supported page environment

Page TSX runs in the Neopress sandbox. Use the modules allowed by the current runtime contract. Arbitrary npm packages, environment variables, filesystem access, server actions, and direct database access are not available as general page capabilities.

Supported patterns include marketing pages, portfolios, CMS lists and detail pages, interactive presentation elements, and managed forms. Visitor accounts, member-only areas, carts, checkout, payment processing, customer subscriptions, and order management are not supported visitor features. When a project needs these services, use an appropriate external destination rather than presenting a nonfunctional login or checkout inside the site.

Bind CMS content and forms

  • Create a collection schema and use its numeric collection ID for page bindings and filters. Entry data keys must match schema field IDs.

  • For a detail page such as /articles/[slug], bind the collection and configure the page query. Each query label becomes a page prop. Entry fields are flattened, so a prop named article exposes article.body.

  • Use injected query props for the initial content. The optional entryClient supports interactions such as loading more results after the page loads.

  • Render a managed form with NeopressForm from @neopress/forms, a numeric form ID, and the injected formClient. The form owns its fields and submission behavior.

Know which changes need publication

Page and layout code, translation dictionaries, global CSS, collection schemas, and form drafts have separate live versions. A page's edited URL becomes its production URL when the site is published. Compiling a page validates its code; it does not publish it.

Not every setting follows this draft process. Site settings, including its name and locale configuration, are saved directly. Metadata updates also use their own fields. Read the current value and preserve unrelated values when updating a settings document.

CMS entries have a separate publish operation. Publishing an entry creates the version used by the live site; further edits stay outside that version until the entry is published again. Site publication alone does not publish entry drafts. If entry references change, publish the source entry again and ensure the referenced entries are published.

Review and publish in order

Use IDs returned by your commands. The numbers below are placeholders; include only the entry and form steps relevant to your change.

neopress --site 123 forms publish 789
neopress --site 123 pages compile 456
neopress --site 123 publish preview
neopress --site 123 entries publish 654
neopress --site 123 publish

Entry and form publication can affect an existing live page before the final site publication. Review them before running their publish commands. Also review other pending changes: the CLI's site publish command publishes the pending site set.

Finally, open the production URL. Check the default and intended secondary languages, CMS details, images, and forms. Publishing against a local or staging API does not update production. A page translated in the draft must also be enabled for that public language and included in a site publication.

Related guides