Fronty documentation
Check, publish, verify, and recover a website
Understand drafts and releases, resolve the complete readiness checklist, publish safely, and know the current rollback boundary.
Last verified
Availability
Limited rolloutReadiness scanning and immutable release infrastructure exist; immutable revisions are enabled per site and forms/translations still have release limits.
- Plans
- Readiness is part of the publishing workflow; other allowances depend on plan.
- Roles
- A role with publish permission. Operations controls immutable-release enrollment.
- Before you start
- Saved pages, representative data, configured metadata, and access to the public URL.
On this page
Draft, preview, and published are different states #
A draft is the editor's saved work. Preview is an authorized view of unpublished content. Published is what an anonymous visitor receives. Do not use an editor or preview URL as evidence that the public release works.
The newer release path stores immutable page revisions in a signed manifest. Publishing moves the active release pointer; it does not rewrite the historical manifest. Enrollment is currently controlled per website rather than enabled universally.
Know what the readiness scan checks #
The Rails readiness definitions check core conditions including a home page, failed or locked pages, route conflicts, page titles and descriptions, item bindings, readable content, placeholders, navigation, images and alt text, public responses, metadata, robots and sitemap behavior.
The release gate requires a current completed scan and can block on findings, warnings or unfinished manual review items. The hosting probe checks the rendered site but does not currently certify database row availability, every form, third-party services, accessibility, mobile behavior or Core Web Vitals.
Complete the manual review #
- Use every important interaction: menus, dropdowns, modals, forms, filters and item links.
- Review at phone, tablet and desktop widths and zoom to 200%.
- Complete the main path with a keyboard and inspect focus visibility.
- Read the content for accuracy, placeholders, legal requirements and broken promises.
- Verify form destinations and representative database content on the public origin.
- Run measured performance and accessibility tools; record their date and URL.
Publish and verify the release #
- Wait for the editor's save state to finish and run readiness.
- Open the full checklist, not only the first visible finding. Resolve blockers and complete manual reviews with evidence.
- Publish, then open the public URL in a separate anonymous session.
- Check the release identifier or visible change, navigation, one database list, one item page, metadata, robots, sitemap and any supported form.
- Monitor application and edge logs after a significant release.
Recover without making the failure worse #
The backend can repoint an immutable site to a retained release after verifying its manifest and page revisions. Use a user-facing rollback control only where the dashboard exposes and authorizes it; backend capability alone is not a promise that every account can self-serve rollback.
If publishing reports an unknown network result, check the actual public state before retrying. Rare ambiguous database responses still need stronger compensation logic, so repeated clicks are not the first diagnostic step.