Guides

Server-Side Rendering

Enterprise Feature

Dev Portal Server-Side Rendering is available as an add-on as part of an enterprise plan. If you would like to purchase this feature, please contact us at sales@zuplo.com or reach out to your account manager.

Most enterprise features can be used in a trial mode for a limited time. Feel free to use enterprise features for development and testing purposes.

By default, the Zuplo-hosted Dev Portal is statically prerendered (SSG). Setting devPortal.serverSideRendering: true in zuplo.jsonc builds and serves the portal server-side for each deployment. Zudoku's protected routes are enforced on the server, so protected content leaves the public bundle and unauthenticated requests cannot fetch it, as described in Server-side Content Protection. SSR applies to preview and production deployments only—never the working copy.

Prerequisites

  • The SSR enterprise add-on enabled on the account.
  • The latest version of Zudoku. See Updating the Dev Portal.
  • For protected content, authentication configured and protectedRoutes set in the Zudoku configuration.
  • The standard zudoku build build script in docs/package.json, which the scaffold includes by default. Zuplo appends the SSR build flags automatically. A custom build script that doesn't forward CLI arguments produces a static build instead.

Enable SSR

Add the devPortal object alongside any existing settings in zuplo.jsonc at the project root:

JSONCode
{ "version": 1, // Other project settings... // Enable server-side rendering for the Dev Portal. "devPortal": { "serverSideRendering": true, }, }

No build-script changes are required. SSR takes effect on the next deployment.

Example: protect partner documentation

Suppose partner documentation is available under /partners/* and should only be available to signed-in users. With authentication already configured, add the route pattern to zudoku.config.ts:

TypeScriptzudoku.config.ts
{ // ... protectedRoutes: ["/partners/*"], }

Enable SSR in zuplo.jsonc as shown above, then deploy a branch. In the preview environment, a signed-out request to /partners/getting-started shows the login prompt instead of the page content. After signing in, the user can access the page.

If the account doesn't have the SSR add-on, the deployment fails with an error that directs you to contact support or remove the flag.

Test on a preview environment

The working copy always uses static rendering

SSR takes effect on preview and production deployments only. The working copy builds statically regardless of the flag, so protected routes are not enforced server-side there.

Deploy a branch to create a preview environment and validate SSR there. While signed out, request a protected route and confirm that the login prompt appears instead of the protected content.

Caching

Responses to anonymous visitors are cached at the edge, so public pages stay fast. Requests with a Dev Portal authentication session always render on demand and are never cached.

Reverting to static rendering

Remove serverSideRendering or set it to false, then redeploy. The portal reverts to static prerendering, and the server infrastructure is torn down automatically.

Next steps

Last modified on