roast logo

FAQ

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
prerenderclouddisable=true
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 usually means your index.html is trying to load a JavaScript file but got another HTML file instead - and because roast.io serves index.html for all files not found (as opposed to 404), this means you may not have uploaded your js files. This is common when forgetting to build/compile your project

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.