Using render.com instead of Netlify and Heroku

render.com looks the same like netlify to me but comes with a way of having postgresql database, is that not a better choice in the tutorial section as deployment target?

2 Likes

What’s nice about Netlify+Heroku is that it’s free to play around with. render.com seems to charge at least $7/month if you want a database.

Hey that looks pretty cool actually. I think the pricing is reasonable once you’re done playing around with free stuff.

Curious to hear if anyone has used it.

Here are some instructions for self hosting on Render.com:

RedwoodJS is architected as monorepo with two separate sides, an “api side” and a “web side.” The api side is a NodeJS application and the web side is a static SPA (single page app). This works out great when hosting on render.com because hosting a static site is free, and static content is served via super-fast CDN.

So we’re going to setup two sides on Render.com, but first you need to add some things to your RedwoodJS project.

Setup the “api” side.

  1. Install the api-server in your api side.
cd api
yarn add @redwoodjs/api-server
  1. Create a “health” function:

The health function is used by Render to check if your api side is running correctly.

// ./api/src/functions/healthz.js
export const handler = async () => {
    return {
        statusCode: 200
    }
}

On render.com, create a new "web service"

  1. Connect to your repository
  2. Environment is Node
  3. Build is yarn && yarn rw prisma migrate deploy && yarn rw build api
  4. Start is cd api && yarn rw-api-server --port 80
  5. Use a custom domain: “api.raccoon.trade”

On render.com, create a new "static site"

  1. Build is yarn && yarn rw build web
  2. Publish is ./web/dist
  3. Add rewrite and redirect rules:

6 Likes

Perfect. We’ll set up a render.yaml and make this easier. Stay tuned!

4 Likes

Thanks for joining the conversation here @anurag! Looking forward to the .yaml

Finally getting around to deploying my Redwood side-project app! I’m trying to follow the instructions here, but for some reason the static site side isn’t picking up the API server domain from API_PROXY_PATH . I added it to the static site config and deployed, but graphql requests from the static site are still pointing at the static site domain, instead of the separate api server. Any thoughts on what I’m doing wrong?

Ive run into a similar issue and I have had to overwrite the App.js file for now.

if (process.env.VERCEL_ENV === 'STAGING') {
  window.__REDWOOD__API_PROXY_PATH = 'YOUR API URL'
} else if (process.env.VERCEL_ENV === 'PRODUCTION') {
  window.__REDWOOD__API_PROXY_PATH = 'YOUR API URL'
}
1 Like

I had the same issue, but thank to this PR of SEANDOUGHTY I find out that you can use rewrite in Render to replace the proxy path in build.

You can add this to your render.yaml in your web static config

   routes:
    - type: rewrite
      source: /.redwood/functions/*
      destination: https://api.raccoon.trade/*
    - type: rewrite
      source: /*
      destination: /index.html

or go to Redirects/Rewrites in the render.com website and set config like this

Replace https://api.raccoon.trade/* by your API url and /.redwood/functions/* by the same configuration on apiProxyPath in your redwood.toml file.

1 Like

Hey @corbt the value you want to change is actually in the redwood.toml

[web]
  port = 8910
  apiProxyPath = "/.redwood/functions" #<----- this guy

Hope this helps!

1 Like

Thanks for all the solutions! I used @danny 's this time but great to know that Render’s rewrites could work too.

I had to disable CORS on the API server side to get this to work as well – will need to figure out a better way to lock that down again in the future.

1 Like

This is what I’m using in api/src/functions/graphql.ts:

export const handler = createGraphQLHandler({
  /* ... */,
  cors: {
    origin: process.env.NODE_ENV === 'production' ? 'https://app.rwjs.dev' : '*',
    credentials: true,
  },
  /* ... */,
})

P.S. I’ve updated the original instructions to include the redirect rules.

1 Like