Preview and publish workflow
Fern gives you four ways to see a docs change, each trading build time for site performance and audience. The recommended path is to move through them in order: iterate locally, share a preview link for review, publish to a staging instance for a production-faithful check, then publish to production.
Local development
Run fern docs dev while you write. The server renders your docs at http://localhost:3000 with hot reload, so edits appear as you save. Some features (search, SEO metadata, authentication) are disabled locally, so use the later steps to verify them.
Preview links
Run fern generate --docs --preview to get a URL you can share with reviewers. Preview links aren’t indexed by search engines and don’t expire.
Previews skip the static build that production and staging sites get: pages render on demand when a visitor requests them. This makes the preview link fast to generate, but navigating between pages is slower than on a published site. Preview links are for checking content and layout, not for judging site performance.
Staging instance
Publish to a staging instance when you want to see the change exactly as production will serve it. This requires multiple instances in docs.yml, for example a staging. prefix on your production domain:
A staging publish runs the full static build, so it takes longer than a preview link, but the resulting site loads and navigates as fast as production. Use it to check search, authentication, performance, and anything else previews don’t cover before going live.
Production
Publish to production when the change is ready for the public. Run fern generate --docs, or pass --instance with your production URL if docs.yml defines more than one instance.
Most teams automate the last three steps in CI: preview links on every pull request, staging on every merge, and production on a manual trigger.