Yes the app is hosted/served from multiple locations: California, Oregon, Ohio, Frankfurt, Sydney and Tokyo in Amazon Web Services' datacenters.

Correct, Roast.io is a CDN and negates the need for CloudFront (or CloudFlare, or any other CDN). Note, you can also use prerender.cloud with CloudFront if you would prefer to use the CloudFront CDN over the Roast.io CDN. Roast.io is meant to be a full featured hosting solution for single-page applications, a one-stop shop.

  1. if _ssr.json has {"lazyLoad": true}, on the first page load
  2. if _ssr.json has {"paths": null}, or {"paths": ['/some-path-1', '/another-path-2']} then it happens in the background during deploys
  3. when hitting the API
So, for example, if you deployed 1 month ago, all your SSR content will be 1-month old. Update it with a new deploy, or using the API.

Set the CI environment variable to anything (just use 1 if not feeling creative). Run roast deploy --help to see more info/options.

The CLI tool tries to be smart and use a config file to save your token and build path but you can handle things manually:

ROAST_TOKEN="mySecretToken" CI=1 roast deploy -s SITE_ID -p dist

Yes - and indeed this is a very popular use-case. Roast.io will drop any cookies and/or auth tokens while server-side rendering, so if you try to server-side render /some-secret-page/my-dashboard it will end up server-side rendering whatever the SPA renders when there's no auth (probably a sign-in screen) - see next section on "How do I disable the server-side rendered content for logged-in users of my single-page app?" so you can coerce Roast.io to return non server-side rendered content when a user is logged in (so logged in users don't see a flash from the sign-in form to their authed page while the client re-renders the SSRd content)

Set the
key/val for the local cookie of logged in users. The flow would look like:

on login: document.cookie = 'prerenderclouddisable=true';

on logout:document.cookie = 'prerenderclouddisable=false'(or just delete it)

react-helmet needs the defer option to be set: <Helmet defer={false}>

React more about react issues here.

This is the most common issue, and it's due to the og:url meta tag. If you have an og:url meta tag on your page, with the content attr set to example.com, then Facebook will consider that (example.com) as the canonical URL and check that instead.

If you have a staging and production environment for your site, AND you have an og:url meta tag, chances are, your og:url is pointing at your production site (which when you're first getting started, may not have Prerender.cloud configured)

You can just remove the og:url tag. If you think you need it, just make sure it's pointing to the URL that prerender.cloud is configured for.

This usually means your index.html is trying to load a JavaScript file but Roast.io returned another HTML file instead. This can happen if your site is using a _redirects file to rewrite 404s to index.html and you haven't uploaded all your files.

At the moment, our CLI doesn't support hidden directories/files (directories/files starting with a dot), so the work-around is the _redirects file with a line pointing the path in a hidden directory to a real file:
/.well-known/apple-developer-merchantid-domain-association /my-actual-apple-merchantid-file.txt 200
and then put a file with the name my-actual-apple-merchantid-file.txt in the root of your deployment directory.
There are 3 ways for a page to be server-side rendered:

  1. if _ssr.json has {"lazyLoad": true}, on the first page load
  2. if _ssr.json has {"paths": null}, or {"paths": ['/some-path-1', '/another-path-2']} then it happens in the background during deploys
  3. when hitting the API
The most common failure scenario is a timeout of 10s - and usually that timeout is due to a AJAX/XHR/Websocket request(s) that took longer than 10s.

In all 3 situations it will be retried once, immediately - and if the retry fails, then any additional attempts to SSR (or lazyLoad SSR) will be ignored for a 5 minute grace period.

So, for example, if you had lazyLoad enabled, you'd see the first request take 20s (to attempts with a 10s timeout), then the 2nd request would complete immediately but would not be server-side rendered. 5 minutes later you'd get another 20s request. The user will never see an error.



Modern Web Hosting