Deploying a Fontdue site is taking the reference template you’ve been running locally and putting it on a host that builds it and serves it on your domain. Nothing about the site itself changes – it reads from the same store over the same GraphQL endpoint. What’s new is that the store URL, the revalidate token, and your live domain now have to be configured outside the code, in the host and in your Fontdue settings.
These pages use Netlify as the host throughout, for all four frameworks, so the flow is the same wherever you started.11Next.js deploys to Vercel just as readily – Netlify runs it through its own Next.js runtime, which supports the same on-demand revalidation, so the steps are identical on either and only the dashboard differs. See Other hosts. None of it is Netlify-specific in shape, so the same three moves carry over to any host.
Deploy the template
Push the template to a Git repository, then create a site from it on Netlify, which detects the framework and fills in the build command and publish directory. You set the environment variables and deploy.
Netlify detects Next.js and runs it through its own Next.js runtime, installed for you – there’s no adapter to add.
The template already includes the Netlify adapter in its Next.js build config, so Netlify reads it to pick the build command and the serverless functions that render your pages and run the revalidate route.
Push your clone to GitHub, GitLab, or Bitbucket – whichever you connect Netlify to.
In Netlify, choose Add new site → Import an existing project and pick the repository. The build command and publish directory come from the template’s config, so there’s nothing to fill in by hand.
Add the same variables you set locally during setup, with their production values:
NEXT_PUBLIC_FONTDUE_URL=https://your-site.fontdue.com
PUBLIC_FONTDUE_URL=https://your-site.fontdue.com
REVALIDATE_TOKEN=a-long-random-string
VITE_FONTDUE_URL=https://your-site.fontdue.com
REVALIDATE_TOKEN=a-long-random-string
VITE_FONTDUE_URL=https://your-site.fontdue.com
REVALIDATE_TOKEN=a-long-random-string
Trigger the first build. Netlify serves the site at a your-site.netlify.app address, which you can later swap for a custom domain.
REVALIDATE_TOKEN is the shared secret the revalidate route checks before it purges the cache – set it to any long random string, and reuse the same value in the deploy hook URL when you connect it.
Allow your live domain
Your site fetches data from the browser as well as on the server – the Store Modal, type testers, and buy buttons all reach your store directly from the visitor’s browser. Those requests are cross-origin, so your live domain has to be on the cross-origin allowlist for them to succeed, exactly as localhost did during setup.
In the admin, open Settings → Integration and add your production URL – the your-site.netlify.app address, plus your custom domain once you’ve connected one.22Each entry is an absolute origin with no path – https://your-site.netlify.app, not https://your-site.netlify.app/shop. A request from an origin that isn’t listed is refused, so add every domain the site is served from.
Refresh on content changes
A deployed site caches its pages, so an edit in the admin won’t show until the site is told to refresh. With the site live, set the Deploy hook URL in Settings → Integration to your deployed /api/revalidate endpoint, so Fontdue calls it after each change. Revalidate data covers the endpoint and the exact URL to enter.
Other hosts
Netlify isn’t a requirement – the site runs anywhere your framework deploys. The configuration is the same shape on any host: set the store URL (and REVALIDATE_TOKEN) as environment variables, add the deployed domain to the cross-origin allowlist, and point the deploy hook at /api/revalidate.
The one host-specific piece is cache revalidation, and Next.js handles it for you: the revalidate route calls revalidateTag, which both Netlify’s Next.js runtime and Vercel honor, so it works on either with no change.
The one host-specific piece is cache revalidation: the revalidate route purges the CDN with purgeCache from @netlify/functions. On another host, swap that single call for its platform’s cache-purge equivalent – the rest of the route, and every other step here, stays the same.