Forem: Render

How Render Scaled Knative to Support 100k+ Free-Tier Apps

Stephen Barlow — Tue, 03 Oct 2023 18:37:29 +0000

By Hieu Nguyen - October 3, 2023

In November 2021, Render introduced a free tier for hobbyist developers and teams who want to kick the tires. Adoption grew at a steady, predictable rate—until Heroku announced the end of their free offering ten months later:

Render's free-tier adoption rate doubled immediately and grew from there (awesome), causing our infrastructure to creak under the load (less awesome). In the span of a month, we experienced four incidents related to this surge. We knew that if Free usage continued to grow (and it very much has—as of this writing, tens of thousands of free-tier apps are created each week), we needed to make it much more scalable. This post describes the first step we took along that path.

How we initially built Free

Some background: unlike other services on Render, free-tier web services "scale to zero" (as in, they stop running) if they go 15 minutes without receiving traffic. They start up again whenever they next receive an incoming request. This hibernation behavior helps us provide a no-cost offering without breaking the bank.

However, this desired behavior presented an immediate development challenge. Render uses Kubernetes (K8s) behind the scenes, and K8s didn't natively support scale-to-zero (it still doesn't, as of September 2023). In looking for a solution that did, we found and settled on Knative (kay-NAY-tiv). Knative extended Kubernetes with serverless support—a natural fit for services that would regularly spin up and down.

In the interest of shipping quickly, we deployed Knative with its default configuration. And, until our growth spurt nearly a year later, those defaults worked without issue.

Where we hit a wall

With the free-tier surge, the total number of apps on Render effectively quadrupled. This put significant strain on the networking layer of each of our Kubernetes clusters. To understand the nature of that strain, let's look at how this layer operates.

Two networking components run on every node in every cluster: Calico and kube-proxy.

Calico mainly takes care of IP address management, or IPAM: assigning IP addresses to Pods and Services (we're using capital-S Service to refer to a Kubernetes Service, to distinguish from the services that customers create on Render.). It also enforces Network Policies by managing iptables rules on the node.

kube-proxy configures a different set of routing rules on the node to ensure traffic destined for a Service is load-balanced across all backing Pods.

Both of these components do their jobs by listening for creates, updates, and deletes to all Pods and Services in the cluster. As you can imagine, having more Pods and Services that changed more frequently resulted in more work:

More work meant more CPU consumption. Remember, both Calico and kube-proxy run on every node. The more CPU these components used, the less we had left to run our customers' apps.
More work meant higher update latency. As the work queue grew, each networking change took longer to propagate due to increased time spent waiting in the queue. This delay is defined as the network programming latency, or NPL (read more about NPL here). When there was high NPL, traffic could be routed using stale rules that led nowhere (the Pod had already been destroyed), causing connections to fail intermittently.

To mitigate these issues, we needed to reduce the overhead each free-tier app added to our networking machinery.

"Serviceless" Knative

As mentioned, we'd deployed out-of-the-box Knative to handle free-tier resource provisioning. We took a closer look at exactly what K8s primitives were being provisioned for each free-tier app:

One Pod (for running the application code). Expected.
2N + 1 Services, where N is the number of times the app was deployed. This is because Knative manages changes with Revisions, and retained resources belonging to historical Revisions. _Un_expected.

We figured the Pod needed to stay, but did we really need all those Kubernetes Services? What if we could get away with fewer—or even zero?

We dove deeper into how those resources interacted in a cluster:

And learned what each of the Knative-provisioned Services (in purple above) was for:

The Placeholder Service was a dummy service that existed to prevent naming collisions among resources for Knative-managed apps. There was one for every free-tier app.
The Public Service routed incoming traffic to the app from the public internet.
The Private Service routed incoming cluster-local traffic based on whether the app was scaled up.
- If scaled up, traffic was routed to the Pod.
- If scaled down, traffic was routed to the cluster's Knative proxy (called the activator), which handled scaling up the app by creating a Pod.

Armed with this newfound knowledge, we devised a path to remove all of these Services.

Step by step

We started simple with the dummy Placeholder Service, which did literally nothing. There was no risk of naming collisions among our Knative-managed resources, so we updated the Knative Route controller to stop creating the Placeholder Service. ❌

Next! While the Public Service (for public internet routing) is needed for plenty of Knative use cases out there, in Render-land, all requests from the public Internet must pass through our load-balancing layer. This means requests are guaranteed to be cluster-local by the time they reach Pods, so the Public Service also had nothing to do! We patched Knative to stop reconciling it and its related Endpoint resources. ❌

Finally, the Private Service (for cluster-local routing). We put together the concepts that Services are used to balance load across backing Pods, and that a free-tier app can have at most only one Pod receiving traffic at a time, making load balancing slightly unnecessary. There were two changes we needed to make:

Streamline traffic to flow exclusively through the activator, as we no longer had a Service to split traffic to when the app is scaled up. With a little experimentation, we discovered that the activator could both wake Pods and reverse-proxy to a woke Pod, even though that behavior wasn't documented! We just needed to set the right headers.
Patch the activator to listen for changes to Pod readiness states, and route directly to Pod IP addresses (thanks, Calico!). By default, the activator listens for changes to EndpointSlices, but those are tied to the Services we were hoping to delete.

And just like that, the Private Service was no more. ❌

Want to go deeper under the hood? Check out an abridged version of the design doc for removing the Private Service.

At the end of this entire optimization pass, the networking architecture for a free-tier app had been simplified to the following:

Zero Kubernetes Services per free-tier app! Predictably, K8s Service counts plummeted across our clusters:

With these improvements, Calico and kube-proxy's combined usage fell by hundreds of CPU seconds in our largest cluster.

With compute resources freed up, free-tier network latency and stability improved dramatically. But even so, we knew we had more work to do.

A moving target

Our Knative tweaks bought us some much-needed breathing room, but ultimately, free-tier usage began to put a strain even on this optimized architecture. The time was quickly approaching for us to rip out Knative entirely, in favor of a home-grown solution that was tailor-made for Render's needs.

But that's a story for another post!

Migration Guide: Heroku to Render

Audrey Maldonado — Thu, 25 Aug 2022 20:43:00 +0000

This guide will help you migrate a Heroku app, Heroku Postgres database, and Heroku Redis instance to Render. Using Render to run your web services and databases is very similar to running them on Heroku. Additionally, many users have found that Render saves them money and provides additional functionality not available from Heroku. Read more about the differences between Render and Heroku.

This guide and associated Heroku CLI plugin covers most migration use cases. It supports migrating a Heroku app and its Heroku Postgres and Heroku Redis add-ons. You may continue using other Heroku add-ons while your app is running on Render by copying over the appropriate environment variables -- e.g., if you are using Heroku's Sengrid add-on, set SENDGRID_USERNAME and SENDGRID_PASSWORD in the Render Dashboard. Please contact us at support@render.com if you experience any problems migrating from Heroku to Render.

Requirements

Heroku app is using one of Heroku's official buildpacks¹
Heroku app is not using multiple buildpacks²

Migration Steps

Generate a Dockerfile.render and render.yaml using Render's Heroku CLI Plugin
Create Resources on Render
Configure Environment Variables
Copy Data From PostgreSQL
Update DNS Configuration

Concept Mapping

Before you start the migration, review the following table to understand how some Heroku concepts map to Render concepts.

Heroku	Render
Web Process (within a Heroku app)	Web Service
Worker Process (within a Heroku app)	Background Worker
Dyno	An instance of your service on Render
Heroku Postgres	Render PostgreSQL
Heroku Redis	Render Redis
Heroku Scheduler	Cron Job
Config Vars	Environment Variables

Step 1: Generate a `Dockerfile.render` and `render.yaml`

Install Render's Heroku CLI Plugin

Render has created a plugin for the Heroku CLI to reduce some of the manual migration steps. Install the plugin with the following command.

The CLI plugin will not modify your Heroku app. It only performs read operations.

heroku plugins:install @renderinc/heroku-import

Run CLI Plugin

The CLI plugin will read information about your app and its add-ons and create two files: Dockerfile.render and render.yaml. Here is what the process looks like. Run it from the root of the repository containing your app's code.

You will then be prompted to select the Heroku Postgres and Heroku Redis add-ons you would like to migrate to Render. After making your selections, a Dockerfile.render and render.yaml will be created for you, and instructions will be shown.

Excluded Environment Variables

DATABASE_URL
HEROKU_
KEY
PASSWORD
REDIS_URL
REDIS_TLS_URL
SECRET
TOKEN

Add `Dockerfile.render` and `render.yaml` to Source Control

The CLI plugin has now created two files: Dockerfile.render and render.yaml. The Dockerfile.render defines how to build your app on Render using a Heroku buildpack. The render.yaml is Render's Infrastructure-as-Code file. It can be used to define multiple services and databases running on Render and their relationship to each other.

Now, add these two files to source control with the following commands.

git add Dockerfile.render render.yaml
git commit -m 'Prepare app for deploy to Render'
git push origin

Step 2: Create Resources on Render

From the Render Dashboard, select New + and then Blueprint. Connect your GitHub or GitLab account to Render if you haven't already, and then search for and select your repository.

Render will create a plan to build and deploy your service along with a Render PostgreSQL database and Render Redis service if your Heroku app was using these and you selected them for import in the Run CLI Plugin step above.

Review the plan and click Apply, and Render will create your resources.

If all resources were created successfully, continue to the next step. If there was an error you cannot resolve, please contact us at support@render.com. We're here to help!

Step 3: Configure Environment Variables

You may need to manually create environment variables that contain secrets like passwords or API tokens using the Render Dashboard. The CLI plugin excluded environment variables with names containing values indicating they may contain secrets.

To create or update environment variables using the Render Dashboard,

Select Dashboard on the left
Select the service you just created from the list
Select the Environment tab and create or update environment variables (check the CLI plugin output if you'd like to copy from your Heroku Config Vars)

Step 4: Copy Data from PostgreSQL

PostgreSQL

If you have created a Render PostgreSQL database, you may want to copy the data from your Heroku Postgres database to Render.

Put your Heroku app into maintenance mode so that no new data is written to the database during the copy. <HEROKU APP NAME> is the Heroku app that owns the Heroku Postgres add-on.

This data migration process requires some downtime.

heroku maintenance:on --app <HEROKU APP NAME>

Create a backup of the data in you Heroku Postgres database.

heroku pg:backups:capture --app <HEROKU APP NAME>

Download the backup. This will download a file named latest.dump to your local computer.

heroku pg:backups:download --app <HEROKU APP NAME>

Import latest.dump into your Render PostgreSQL database. The value for <EXTERNAL CONNECTION STRING> can be found on the Render Dashboard page for your database.

pg_restore --verbose  --no-acl --no-owner -d <EXTERNAL CONNECTION STRING> latest.dump

If your database is larger than 20GB or under heavy load, use Heroku's instructions to create a backup of your data. After that has completed, you can use the same pg_restore command above to import the data to your Render PostgreSQL database.

Consider using the --jobs flag available to both the pg_dump and pg_restore commands to reduce the time required for backup and restore.

Step 5: Update DNS Configuration

If your Heroku app is using a custom domain, follow the instructions to update your DNS configuration to point to Render instead of Heroku. Note that some downtime may be required between when your DNS changes propogate and when Render provisions a TLS certificate for your domain.

If you would like to migrate a Heroku app to Render that is not using an official Heroku buildpack please contact us at support@render.com for assistance. ↩
We are working on supporting migration of Heroku apps that use multiple buildpacks. ↩

...It Works Fine Locally

Audrey Maldonado — Fri, 19 Aug 2022 17:40:15 +0000

Our latest blog post, by Support Engineer Alan Pinnell-Smith.

When you're ready to deploy to production, it can be frustrating to find that your project that worked perfectly on your machine is now throwing errors in the cloud. As you can imagine, the Support Engineering team at Render helps customers fix these issues on a regular basis, so we’ve created a checklist to help prevent them in the first place and save us all some time.

Writing Code

Deploying a project can feel tough, especially when you're starting out.

Web development used to be so straightforward. Open up a text editor, write some HTML, add a few images, FTP it all up to a server and you have a website live on the Internet! Simpler times — boring, non-dynamic, table-layout, under-construction-GIF, “best viewed on Netscape Navigator”, hit-counter times, but certainly a lot simpler.

Fast-forward to today, and the number of languages, frameworks, tools, design patterns and a multitude of other aspects surrounding web development are staggering and overwhelming. I've been tinkering on the web since the mid-90s (as you can probably tell from the references above) but the sheer number of choices available to the modern-day web developer makes me wonder how anyone can ever know where to start. In addition to the flood of choices, the pace at which these things evolve can be very hard to keep up with (I'm looking at you, JavaScript!).

Luckily, there are also a huge number of helpful resources out there: guides, video courses, the obligatory blog/to-do list tutorials, and our very own Render Quickstarts and Examples. There's also the ever-helpful Stack Overflow when you hit that brick wall of an unexpected error message. Tools like project scaffolding, ORMs, and development servers all make it easier to get started with a new project on your machine. But when it comes to deploying your code, there isn’t enough help online.

Deploying Code

When I made the change in my career from being a web developer (mainly Ruby) to a Support Engineer a few years ago, one phrase quickly became apparent as a common sign-off: "… it works fine locally". Along with its bedfellows "works for me" and "works on my machine", these are phrases we hear often in development, and especially in developer support.

Don't get me wrong: it's certainly good to know that there are no glaring code issues preventing a project from spinning up at all. However, the considerations required to deploy a project in the cloud are an essential part of being a web developer these days. Even if it works fine locally, chances are it’s not going to work fine when you put your shiny new project on someone else's machine or platform.

We're all keen to get our work out there on the web as soon as possible, but environments will differ — sometimes by a lot. You may develop on Windows or macOS or something more exotic, but almost always, you will deploy to some flavor of Linux. Every language, framework and tool will have a particular version and likely a sprawling list of dependencies (each with its own version, dependency and compatibility requirements) goes all the way down. Again, we're lucky to have some great package management tools to keep all that in check for us.

Render Native Environments help the most commonly used project configurations get up and running as quickly as possible, and we inspect your code to supply some defaults along the way. But because every project is different, the required configuration can be too.

Here's a checklist that, while focused on Render, will help you regardless of where you're deploying your project.

A Deployment Checklist

This list won't apply to every case, but being mindful of these points may make deploying your application, and debugging any issues with that deployment, a little more tractable.

Versioning: Explicitly define versions. Language, package manager and packages. Render has default language versions for native environments, but we'd still recommend you set your own version, e.g. Node, Python, Ruby, etc. This way, you can be sure it's the same as the one you developed on and will continue to stay the same if the default changes in future.
Configuration: Keep configuration in the environment. That may sound familiar if you've ever looked at The Twelve-Factor App. External service URLs, API keys/tokens, SMTP config, etc. will be easier to manage per environment if stored in environment variables or as secret files. And if you need to share these across services, check out Render’s Environment Groups.
Add a Health Check: Create an HTTP endpoint in your app to check if your application is live. Web Services on Render allow you to specify a health check path that's used to check that a new deploy is working as expected before transitioning requests to it. It is also used to check if your app is still up after a deploy; Render automatically restarts your app if the health check endpoint is unresponsive.

A health check endpoint should touch critical parts of your app, for example, include a simple database connection in it or ping an API endpoint. If your checks pass, return a response code between 200-399 and the deploy will be put live. If the health check responds with a code 400+ the deployment will be marked as a failure and will not proceed.
Production Builds: Verify the dependencies being installed when you build your app in the cloud. Use the same tools you did for development, e.g. npm/Yarn (Node), pip/Poetry (Python), Bundler (Ruby), etc. These tools can also have dependency groups, like devDependencies/dependencies in Node's package.json; make sure your packages are in the right group and be aware that production mode may not install development group packages.

Many frameworks also have dev tooling that does things like hot code reloading or just-in-time compilation. The Rails asset pipeline or a Webpack dev server are good examples of this. These development helpers are usually unsuitable for production, so you should build/precompile/transpile as your particular project requires.

To keep your Render build command(s) tracked along with your code, it can be handy to put it in a shell script and use that to set up the environment. A simple Node based example would be:

# render-build.sh

#!/usr/bin/env bash
# exit on error
set -o errexit

npm install
npm build

Booting your application: Make sure you start your app in production mode and are not using a development server. If you're having trouble with a deploy it can sometimes help to try starting your app in production mode on your dev machine to see if it still works fine locally.

For Web Services in particular ensure the app server has its host & port set to 0.0.0.0 and the PORT environment variable, respectively. You may also want to consider concurrency settings appropriate for your chosen service plan, e.g. worker counts in Throng (Node), Gunicorn (Python), Puma (Ruby), etc.
File Storage: Service runtime instance filesystems are not persistent. Render service filesystems (and most platforms) are ephemeral, meaning files written after they’re started do not persist after a restart/new deploy. If you need to persist uploaded/generated files between deploys you will need a Render Disk.

While an ephemeral filesystem may feel counterintuitive at first – "why can't I just save my uploads to my instance?!" – it makes scaling and recovery from outages much more straightforward. Cloud-deployed instances benefit from being readily disposable/recreatable.

When you do need to store longer-term data, you can add a Render Disk for file persistence. Depending on your data storage needs, it may be also worth considering a dedicated database like PostgreSQL or an object storage service like AWS S3. It’s easy to forget about this during development and end up with your application relying on local filesystem storage.
Custom domains and SSL/TLS: Configure and secure your custom domain. You're unlikely to be running a dev environment on a custom domain or over HTTPS, so you may need to make some configuration updates to ensure your app is aware of how it may receive requests (like ALLOWED_HOSTS in Django, etc.). You may also want to set up a redirect in your code to 301 from the default service-name.onrender.com to your custom domain to keep it canonical.

SSL/TLS Certificates are fully managed on Render and redirection of HTTP requests to HTTPS is automatic. You may need to ensure your assets use HTTPS in production if using a full URL and not just a relative path, to avoid any mixed-content errors.

With all that said, using Docker can sometimes help reduce the burden of thinking about many of the above items by making your dev environment more closely match the production environment, but using Docker also adds a bunch of additional complexity, and that's a post for another day...

We've touched on a lot of areas to get your project deployed successfully, but it’s hard to cover everything in a blog post. If you find you're still having trouble deploying things on Render, we're here to help and you can reach us at support@render.com or post on community.render.com.

Migrate a Django App from Heroku to Render (and get it ready for prod)

Audrey Maldonado — Fri, 01 Jul 2022 19:12:51 +0000

By Rosalind Benoit - June 27, 2022

Picture this: you run a hefty Django app, an online store for your company. It’s a collection of services – an API, a shiny frontend, a database, an in-memory datastore, worker nodes, a GUI for admins, a bunch of scheduled jobs…the whole shebang – all tuned to perform quickly for your customers. You’re ready to kick into high gear as the busy season approaches and the team preps new product launches.

Then suddenly, your cloud provider is struggling with operational challenges. You can’t deploy updates. You’re channeling #HugOps, but your apps must continue to #JustWork.

// Detect dark theme var iframe = document.getElementById('tweet-1527293265149513736-877'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1527293265149513736&theme=dark" }

While our migration guide explains the process for moving any kind of app over, I often like to have a detailed example to follow. As a Python developer and a former Drupal and Magento admin for a retail chain, I wanted to share a migration post that could help someone in a time of need like the one described above. With this guide, I will help you move your Django app to Render so that it's production-ready : ) If you’re looking to start fresh instead, check out our guide for quickly deploying a new Django app.

// Detect dark theme var iframe = document.getElementById('tweet-1527307407466106880-856'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1527307407466106880&theme=dark" }

This post will walk through a practical example of migrating an application from Heroku to Render using Saleor, a popular open-source e-commerce system. Based on Django and Python, Saleor has served high-volume companies in retail sectors like publishing and apparel since 2012 and is still growing rapidly. The latest major update introduces a modular front end powered by a GraphQL API and written with React and TypeScript.

Why Saleor, Why Render?

Lots of Render users may encounter real-world use cases in which they need to deploy a full-featured storefront, and Saleor provides a flexible API-first solution. The framework appeals to us at Render because it’s developer-first, actively maintained, and receptive to community feedback and contribution.

You may wonder why you would want to migrate your Django app from Heroku to Render. Our comparison page explains all the benefits you'll get – like private networking, HTTP/3, and DDoS protection, among many other things. Running a production-grade instance of Saleor on Heroku gets complicated really quickly. This guide explains how we addressed much of that complexity in the Render environment.

There is one more reason we chose the Saleor project for this guide. We often hear questions about Docker Compose from our users interested in taking advantage of Render’s implementation of IaC (infrastructure-as-code). Within on of its repositories, the Saleor project maintains code and documentation for deploying all components of Saleor using Docker Compose. This guide will also discuss how we translated that docker-compose.yml into a Render Blueprint.

Before embarking on a migration, it helps to understand how some high-level concepts map from Heroku to Render. Check out the helpful concept mapping my coworker Chris put together.

Deploy Saleor on Render

In the first part of this post, we’ll migrate a demo instance of Saleor from Heroku to Render. In the second half, we’ll productionalize Saleor on Render. If you want to follow along on our journey interactively, fork the saleor repository.

We’ll start by creating a render.yaml file at the root of our repository. If our deployment is a Bob Ross creation, this is our blank canvas – the Blueprint that defines and integrates all the components of the working production application. You can certainly use the Render Dashboard to deploy services and databases individually, but we’ll codify the architecture in a render.yaml so we can:

Reduce the chance of human error
Reduce repetitive point-and-click configuration
Define a source of truth for the architecture with version control and git blame

Saleor’s README invitation to deploy their demo on a Heroku instance acts as our entry point for this post. We’ll first walk through each stage of migrating the demo to Render, and then illustrate steps for making the Django app production-ready. Saleor consists of three components: the Saleor Core backend server, the Saleor Dashboard GUI, and the Saleor React Storefront. Here's a preview of the architecture we'll deploy:

We’ll paint each happy little tree at a time 🌳, but you can peek at the final creation on Github.

Part One: Migrate a Django App from Heroku to Render

Create a Web Service for the API
Add a Database
Add Redis
Add Build Steps
Add a Frontend React App
Add a Static Dashboard

Part Two: Productionalize a Django App on Render

Add a Secret File
Add a Background Worker
Add a Cron Job
Update Build Steps
Add Runtime Steps
Add a Message Broker
DRY It Up
Help! (a Helper File for Derived Variables)
Next Steps

A note on using other application manifests to generate Blueprints:

If your application has been deployed on Heroku or with an infrastructure provisioning tool, you likely have other infrastructure-as-code files, like a Procfile or docker-compose.yml, to refer to while setting up a deployment to Render. These files can act as useful tools for creating Blueprints. This post will reference several alternative application manifests to demonstrate how they were used.

The saleor and saleor-dashboard repositories both contain app.json files for Heroku deployment. The Saleor project also includes the saleor-platform repository, which combines the Saleor API, saleor-dashboard, and the react-storefront. Both saleor-platform and the Heroku deployments are intended for local development and demo purposes and do not reflect productionalized Saleor environments. Still, we’ll use app.json and Docker Compose files as guides for getting started with a Blueprint that describes the Saleor services and their attributes. These resources are particularly helpful in pointing us to the environment variables and commands necessary to build and run an app.

Migrate a Django App from Heroku to Render

To begin, we will deploy the Saleor Core API server using Render’s native Python environment. We maintain native environments to make deploying to production similar in complexity to running code locally. Like Buildpacks in Heroku, they provide common language runtimes and minimize the need to provision utilities used to build and deploy; native environments aim to provide more control and customization capability while requiring fewer steps to use and understand than Buildpacks. Let’s jump in to creating a render.yaml to set up our demo Django app!

Create a Web Service

We’ll begin by defining a Web Service for the Django app’s GraphQL API in a brand new render.yaml. This service is described in an app.json file and corresponds to the api service in the saleor-platform docker-compose.yml.

services:
  - name: saleor
    type: web
    env: python
    repo: https://github.com/render-examples/saleor
    buildCommand: pip3 install -r requirements.txt && python manage.py migrate --no-input
    startCommand: ALLOWED_HOSTS=".onrender.com" gunicorn --bind :$PORT --workers 4 --worker-class uvicorn.workers.UvicornWorker saleor.asgi:application
    envVars:
      - key: DJANGO_SETTINGS_MODULE
        value: saleor.settings
      - key: DEBUG
        value: True
      - key: NPM_CONFIG_PRODUCTION
        value: false
      - key: DEFAULT_FROM_EMAIL
        value: noreply@example.com
      - key: ENABLE_ACCOUNT_CONFIRMATION_BY_EMAIL
        value: False
      - key: SECRET_KEY
        generateValue: true
      - key: PYTHON_VERSION
        value: 3.9.0

Let’s make sure each line is clear.

name is a name for our service to make it easy to find on the Render Dashboard. It’s interchangeable with the name in app.json and is also used to generate an .onrender.com URL.
type tells Render that we’d like to create a Web Service. When we’re deploying an API, the type may be either web or pserv (Private Service), depending on the use case.
env specifies that we’d like to use Render’s native Python environment. This environment includes OS packages that common Python libraries need in addition to Python 3 specific environment variables.
repo specifies which repository we'll deploy from; update this if you're deploying your own fork of Saleor Core.
buildCommand tells Render which commands or files to run to build the Django app. Read more about render-build.sh below. Heroku buildpacks often handle build elements behind the scenes, but Render encourages being more transparent and provides more control. Use the RUN commands from builds described in Dockerfiles as a guide for build commands to include in a blueprint.
startCommand tells Render which commands or files to run to start the Django app. This command is specified in the Procfile for a Heroku build. We'll prepend the command with the ALLOWED_HOSTS environment variable. Referencing the standard RENDER_EXTERNAL_HOSTNAME variable will add our API's hostname to the list of allowed hosts.
DJANGO_SETTINGS_MODULE is an environment variable that Django requires to determine which settings to use.
DEBUG is an environment variable that Django requires, and should never be set to TRUE in production deployments. We’ll use DEBUG=True for our first demo deployment.
DEFAULT_FROM_EMAIL is an environment variable that Saleor uses to set a default email address for outgoing email.
ENABLE_ACCOUNT_CONFIRMATION_BY_EMAIL is an environment variable that Saleor uses to control whether new account registration should require email confirmation.
SECRET_KEY is an environment variable that Django requires to provide cryptographic signing.
PYTHON_VERSION is an environment variable used to customize the Python version for a project on Render if a version other than Render’s current default of 3.7 is required.

Add a Database

Now we need a PostgreSQL database for the app. Let's add that to our render.yaml.

# …snip…
databases:
  - name: saleor-db
    ipAllowList: [] # only allow connections from services in this Render account

That was simple, but how do we connect this database to the Web Service?

services:
  - name: saleor
    type: web
    env: python
    repo: https://github.com/render-examples/saleor
    buildCommand: pip3 install -r requirements.txt && python manage.py migrate --no-input
    startCommand: ALLOWED_HOSTS=".onrender.com" gunicorn --bind :$PORT --workers 4 --worker-class uvicorn.workers.UvicornWorker saleor.asgi:application
    envVars:
      - key: DJANGO_SETTINGS_MODULE
        value: saleor.settings
      - key: DEBUG
        value: True
      - key: NPM_CONFIG_PRODUCTION
        value: false
      - key: DEFAULT_FROM_EMAIL
        value: noreply@example.com
      - key: ENABLE_ACCOUNT_CONFIRMATION_BY_EMAIL
        value: False
      - key: SECRET_KEY
        generateValue: true
      - key: PYTHON_VERSION
        value: 3.9.0
      - key: DATABASE_URL
        fromDatabase:
          name: saleor-db
          property: connectionString

databases:
  - name: saleor-db
    ipAllowList: [] # only allow internal connections

The highlighted lines create an environment variable whose value is the connection string for the database.

Add Redis

This Django app uses Redis for caching, so let's add Redis.

services:
  # …snip…
  - name: saleor-redis
    type: redis
    ipAllowList: [] # only allow connections from services in this Render account

And similar to the database, we now need to tell the API how to access the Redis instance.

services:
  - name: saleor
    type: web
      env: python
      repo: https://github.com/render-examples/saleor
      buildCommand: pip3 install -r requirements.txt && python manage.py migrate --no-input
      startCommand: ALLOWED_HOSTS=".onrender.com" gunicorn --bind :$PORT --workers 4 --worker-class uvicorn.workers.UvicornWorker saleor.asgi:application
      envVars:
      - key: DJANGO_SETTINGS_MODULE
        value: saleor.settings
      - key: DEBUG
          value: True
      - key: NPM_CONFIG_PRODUCTION
          alue: false
      - key: DEFAULT_FROM_EMAIL
        value: noreply@example.com
      - key: ENABLE_ACCOUNT_CONFIRMATION_BY_EMAIL
        value: False
      - key: SECRET_KEY
        generateValue: true
      - key: DATABASE_URL
        fromDatabase:
          name: saleor-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          type: redis
          name: saleor-redis
          property: connectionString
      - key: PYTHON_VERSION
        value: 3.9.0

databases:
    - name: saleor-db
      ipAllowList: [] # only allow internal connections

The highlighted lines create an environment variable whose value is the connection string for the Redis instance.

Add Build Steps

When Django apps are built and deployed, a few extra commands are commonly run to install dependencies and perform database migrations. Let’s create a render-build.sh file in the root directory of our project. You can use this type of file to run any build steps your Django app requires.

#!/usr/bin/env bash
set -e # exit on error

pip3 install -r requirements.txt

python manage.py migrate --no-input

The value of buildCommand in the render.yaml should be the path to the render-build.sh file. With a build script in place, we can deploy the API, database, and Redis instance to ensure everything works as expected so far. Deploy the repository containing your render.yaml as a Blueprint on Render. When it's done, go to the /graphql/ path of your API's .onrender.com URL to see the GraphQL API Playground.

Add a Dashboard

With the API for our Django app scaffolded, we’re ready to define a frontend service to consume it. The Saleor platform deployed on Heroku includes the saleor-dashboard, so we’ll define this in our Blueprint next. It is a single-page Node.js dashboard app, defined in an app.json file for Heroku deployment, and uses Heroku’s static buildpack.
When we migrate saleor-dashboard to Render, we’ll use Render’s static environment. This component of our infrastructure will run for free, since Static Sites are always free on Render, and Render will serve it over a global CDN with fully managed TLS certificates. Let’s add to our render.yaml.

# …snip…
  - name: saleor-dashboard
    type: web
    env: static
    repo: https://github.com/saleor/saleor-dashboard
    buildCommand: npm install && API_URI="$TEMP_API_URI/graphql/" npm run build
    staticPublishPath: ./build/
    envVars:
      - key: TEMP_API_URI
        fromService:
          name: saleor
          type: web
          envVarKey: RENDER_EXTERNAL_URL
      - key: APP_MOUNT_URI
        value: /dashboard/
      - key: STATIC_URL
        value: /dashboard/
    routes:
      - type: rewrite
        source: /
        destination: /dashboard/index.html

We’ve added the commands for installing dependencies and building the app to add to our buildCommand. The dashboard requires the API_URI environment variable to build successfully. To avoid hard-coding, we'll derive a temporary environment variable from our API service using the fromService attribute, and build our final API_URI as part of our buildCommand.

The Dockerfile provides insight into the staticPublishPath required for this project; we see a COPY of the static contents to the /build/ directory, relative to the working directory. We also see the environment variables required to run the app in the Dockerfile, including the URI for our Saleor API and the URL where the dashboard should be mounted and served.

To translate the configuration found in static.json and the NGINX configuration file to Render, we add a rewrite to route / requests to /dashboard/index.html. When we push these render.yaml changes, Render will automatically create the new Static Site.

Add a React Storefront

If I’m comparing this project to a painting, it's time we added something pretty. The final frontend piece of the Saleor platform, the storefront, is deployed to Heroku as part of the Saleor demo in its original version of the storefront. This storefront is now deprecated because in 2021, the Saleor project added a new storefront service built with Next.js, TypeScript, and Tailwind CSS. The original saleor-storefront can be migrated from Heroku similarly to the API and Dashboard projects, but Heroku deployment hasn’t been added to the new react-storefront repository. The more modern react-storefront contains a development Dockerfile that provides clues to deployment requirements. In this guide, we’ll deploy the react-storefront as the final component of our demo Saleor instance.

Note that we can deploy the react-storefront on Render as-is using the Dockerfile. However, since Render provides an HTTP proxy for all Web Services, using nginx as defined in the Dockerfile is redundant. Instead, we can define our service more simply and use Render’s native NodeJS environment. We’ll use docker-compose.yml, the Dockerfile, and the package.json file as starting points. Let’s add a storefront to our render.yaml.

# …snip…
  - name: saleor-storefront
    type: web
    env: node
    repo: https://github.com/saleor/react-storefront
    buildCommand: >
      pnpm install
      && NEXT_PUBLIC_API_URI=$TEMP_NEXT_PUBLIC_API_URL/graphql/ pnpm run build
      && pnpm run postbuild
    startCommand: NEXT_PUBLIC_API_URI=$TEMP_NEXT_PUBLIC_API_URL/graphql/ pnpm start
    envVars:
      - key: TEMP_NEXT_PUBLIC_API_URL
        fromService:
          name: saleor
          type: web
          envVarKey: RENDER_EXTERNAL_URL
      - key: NEXT_PUBLIC_IMAGE_CONVERSION_FORMATS
        value: image/avif,image/webp

The build command is defined in the Dockerfile. The docker-compose.yml and the Dockerfile only define RUN commands for a development instance, but we’ll run the build, start, and postbuild scripts defined in the package.json using pnpm run commands.

The environment: clause of the docker-compose.yml provides clues to the minimum environment variables required for react-storefront to run. NEXT_PUBLIC_API_URI is required to define the location of the GraphQL API, and we’ve set this to our Saleor API instance’s public URI with /graphql/ added per react-storefront docs. In our testing, the only other environment variable required for successful deployment was NEXT_PUBLIC_IMAGE_CONVERSION_FORMATS.

🎇 Get excited! 🎆 With a Dashboard and Storefront added to our Blueprint, we are ready to deploy our demo instance of Saleor. Pushing these changes will automatically deploy the storefront. Try it out if you're following along in your own repository.

Productionalizing a Django App on Render

As I mentioned earlier, while the deploy-to-Heroku resources that Saleor provides are suitable for a demo application, we would need to modify them to deploy a production-grade instance of the Saleor platform to Heroku. Instead, we’ll walk through productionalizing our Django e-commerce app on Render. We’ll now frame and hang our painting – or maybe you prefer imagining the addition of a majestic mountain or waterfall. Either way, now that we’re beyond Heroku, keep reading to tap some handy Render features, add power, and DRY it up. We'll finish with a hardened Saleor instance impervious to "happy accidents."

Add a Secret File

A production-grade instance of Saleor needs an RSA private key. Render’s Secret Files can help us securely store this key. To begin, we need to generate a key in the specified PEM format. We can do this locally: ssh-keygen -t rsa -b 4096 -m PEM

When generating the key, we should give it a unique name like saleor-key to avoid overwriting any existing SSH keys. No passphrase is required. With the newly-generated private key copied to the clipboard, we can navigate to our Saleor Core (API) Web Service in the Render Dashboard and create a Secret File. In Environment > Secret Files, we can add a Secret File by providing the filename as the key and pasting the private key into Contents.

Now our private key is accessible at the absolute path /etc/secrets/saleor-key.

Add a Background Worker

In processing web requests to your Django app, it’s often useful to offload tasks to an asynchronous background worker. Our Heroku instance of Saleor used a celeryworker dyno, and we can provision a similar celery worker on Render. Let’s add a celery worker to our render.yaml.

# …snip…
- type: worker
  name: saleor-worker
  env: python
  repo: https://github.com/render-examples/saleor
  plan: standard
  buildCommand: ./render-build.sh
  startCommand: celery -A saleor --app=saleor.celeryconf:app worker --loglevel=info -E
  envVars:
    - key: DATABASE_URL
      fromDatabase:
        name: saleor-db
        property: connectionString
    - key: REDIS_URL
      fromService:
        type: redis
        name: saleor-redis
        property: connectionString
    - key: PYTHON_VERSION
      value: 3.9.0
    - key: DJANGO_SETTINGS_MODULE
      value: saleor.settings
    - key: DEBUG
      value: True
    - key: NPM_CONFIG_PRODUCTION
      value: false
    - key: DEFAULT_FROM_EMAIL
      value: noreply@example.com
    - key: ENABLE_ACCOUNT_CONFIRMATION_BY_EMAIL
      value: False
    - key: SECRET_KEY
      generateValue: true

The plan: standard attribute is set because the celery worker requires more memory than what's availabe in free plans. Also, adding the same environment variables that our API process uses creates some duplication in our render.yaml, which we’ll also address in a later section.

Add a Cron Job

Saleor runs a command periodically to update currency exchange rates for sellers doing business internationally. Saleor’s demo app uses the Heroku Scheduler to run this daily. We can use a Cron Job to keep the exchange rates up to date. Let’s create a Render Cron Job to run the python manage.py update_exchange_rates --all command at 1 AM every day.

# …snip…
- type: cron
  name: exchange-rates
  env: python
  schedule: "0 1 * * *"
  startCommand: python manage.py update_exchange_rates --all
  buildCommand: ./render-build.sh
  repo: https://github.com/render-examples/saleor
  envVars:
    - key: DJANGO_SETTINGS_MODULE
      value: saleor.settings
    - key: DEBUG
      value: True
    - key: NPM_CONFIG_PRODUCTION
      value: false
    - key: DEFAULT_FROM_EMAIL
      value: noreply@example.com
    - key: ENABLE_ACCOUNT_CONFIRMATION_BY_EMAIL
      value: False
    - key: SECRET_KEY
      generateValue: true
    - key: PYTHON_VERSION
      value: 3.9.0
    - key: DATABASE_URL
      fromDatabase:
        name: saleor-db
        property: connectionString
    - key: REDIS_URL
      fromService:
        type: redis
        name: saleor-redis
        property: connectionString
    - key: OPENEXCHANGERATES_API_KEY
      sync: false

You may notice that the definition of the Cron Job looks very similar to that of the Web Service for our API. A Render Cron Job is not tied to a parent app or Web Service like Heroku’s Scheduler add-on. It is defined on its own. A Cron Job builds and runs code from any repository on a specified schedule, whereas the Heroku Scheduler can only execute a command using an existing deployed app. In this case, similarly to the background worker, the Cron Job needs to use many of the same environment variables as its fellow services, and we’ll address that duplication below.

A few other things to note about this Cron Job definition:

The schedule property; schedule is a cron expression that defines when to run the job – in this case, we’re running it every day at 1 am UTC.
The OPENEXCHANGERATES_API_KEY is required to get exchange rates from the Open Exchange Rates API. You’ll need to sign up for a free Open Exchange Rates account to enable the integration. The value for your OPENEXCHANGERATES_API_KEY should be your Open Exchange Rates app ID. Read more in the Saleor documentation. Because this value should probably be kept secret, you should define it with the placeholder sync: false so that you can add teh value securely in the dashboard.

With that, our Cron Job is in place to keep prices in local currencies updated, and we are fleshing out a promising landscape.

Update Build Script

Now, let’s update our build script to support the secret key and services we’ve added to get our instance of Saleor ready for production.

#!/usr/bin/env bash
set -e # exit on error

export RSA_PRIVATE_KEY=$(cat /etc/secrets/saleor-key)

pip3 install -r requirements.txt

if [ "$RENDER_SERVICE_TYPE" = "web" ]; then
  python manage.py migrate --no-input
fi

First, we set the RSA_PRIVATE_KEY environment variable to make it available in the build context.

We also add logic that checks the standard Render environment variable RENDER_SERVICE_TYPE to ensure that database migration only runs for the Web Service. This change helps us to avoid a race condition which would prevent one of the services from deploying successfully.

Add Runtime Script

Next, we’ll replace our original startCommand: in the Python services with a start script to accommodate our more complex deployment. We’ll use a subcommand to address the cases of starting the celery worker and cron job.

#!/usr/bin/env bash
set -e # exit on error

export RSA_PRIVATE_KEY=$(cat /etc/secrets/saleor-key)


subcommand=$1
case $subcommand in
  server)
    gunicorn --bind :$PORT --workers 4 --worker-class uvicorn.workers.UvicornWorker saleor.asgi:application
    ;;
  worker)
    celery -A saleor --app=saleor.celeryconf:app worker --loglevel=info -E
    ;;
  cron)
    python3 manage.py update_exchange_rates --all
    ;;
  *)
    echo "Unknown subcommand"
    ;;
esac

We explicitly set the RSA_PRIVATE_KEY environment variable since it is also required in Saleor’s run context. We also need a subcommand to tell the script to start either the web server or the celery worker. To finish this step, we’ll update the startCommand value for our Python services in render.yaml to reference the new start script; for our API, we’ll use ./render-start.sh server, for our worker, ./render-start.sh worker, and for our cron job, ./render-start.sh cron.

Add CloudAMQP

The Heroku deployment of Saleor uses CloudAMQP as an add-on for message brokering. To use CloudAMQP with our Render deployment, we first create a free CloudAMQP instance and note the URL.

Then we set the value of the CLOUDAMQP_URL environment variable to the URL provided by the CloudAMQP dashboard.

# …snip…
- type: worker
  name: celery-worker
  env: python
  repo: https://github.com/render-examples/saleor
  plan: standard
  buildCommand: ./render-build.sh
  startCommand: ./render-start.sh worker
  envVars:
    # …snip…
    - key: CLOUDAMQP_URL
      sync: false

DRY It Up

As I mentioned previously, there’s some duplication in the render.yaml between the Python services. On Render, we can add a happy little cloud to our environment – an Environment Group – to reduce some of this duplication. An Environment Group is a set of environment variables maintained in one place and shared with multiple services. Let’s move the SECRET_KEY, PYTHON_VERSION, DJANGO_SETTINGS_MODULE, DEBUG, NPM_CONFIG_PRODUCTION, DEFAULT_FROM_EMAIL, and ENABLE_ACCOUNT_CONFIRMATION_BY_EMAIL environment variables to an Environment Group. We're also going to add ALLOWED_CLIENT_HOSTS, which is required when we flip DEBUG from True to False in the next section.

# …snip…
envVarGroups:
  - name: saleor-settings
    envVars:
      - key: PYTHON_VERSION
        value: 3.9.0
      - key: DJANGO_SETTINGS_MODULE
        value: saleor.settings
      - key: DEBUG
        value: True
      - key: NPM_CONFIG_PRODUCTION
        value: false
      - key: DEFAULT_FROM_EMAIL
        value: noreply@example.com
      - key: ENABLE_ACCOUNT_CONFIRMATION_BY_EMAIL
        value: False
      - key: SECRET_KEY
        generateValue: true
      - key: ALLOWED_CLIENT_HOSTS
        value: .onrender.com # If using custom domains, change this to a comma-separated list of your storefront and dashboard hostnames

Now we can remove the definition of those environment variables from the Python services and add the following property to their envVars objects:
- fromGroup: saleor-settings

To make the most of our environment group, note that we can also add our saleor-key secret file to our environment group so it’s accessible from each service’s environment. We need to do this in the Dashboard after the Environment Group creation is complete.

Help! (a Helper File for Derived Variables)

Our repetition of the RSA_PRIVATE_KEY export is another source of duplication in our deployment code. In addition to RSA_PRIVATE_KEY, Django apps and Saleor in particular also require a few other security-focused environment variables to run in production: the aforementioned ALLOWED_HOSTS, used to thwart HTTP Host header attacks, and ALLOWED_CLIENT_HOSTS, used to restrict API access to the target clients you define. To continue our DRYing kick and make these parameters centrally available, we can use a helper script and source it in both our render-build.sh and render-start.sh scripts. Let’s create a helper script.

#!/usr/bin/env bash
set -e # exit on error

export RSA_PRIVATE_KEY=$(cat /etc/secrets/saleor-key)
export ALLOWED_HOSTS=$RENDER_EXTERNAL_HOSTNAME

Now we can replace the export lines in both render-build.sh and render-start.sh with source helpers/variables.sh and add any other programmatically derived environment variables to helpers/variables.sh in future.

To complete our de-duplication effort, we should add our RSA_PRIVATE_KEY to the Environment Group we created so it's shared among our Environment Group. We can do this in the Dashboard in Env Groups > saleor > Secret Files.

Drumroll, please: our happy little services, scripts, and tools now depict a complete landscape. With our production-ready environment variables now available in both the build and start contexts for all of our services, we are ready to flip the switch on our Saleor services in render.yaml to DEBUG=False, sync our Blueprint, and deploy!!

Next Steps

Bob Ross warned us, “If you do too much, it’s going to lose its effectiveness." At Render, we do a lot so that you can do just enough to build great things. If you're thinking about migrating your Django project to Render, you’re considering how to translate each component to the new environment, and the amount of work required. This post aims to provide good coverage of those tasks, but there is always room for growth : ) We’ll keep building, and in the meantime, we (and your fellow developers) would love to see your solutions for the following next steps:

You may deploy RabbitMQ as a Private Service on Render instead of using an external RabbitMQ-as-a-service provider. A version of this project with a RabbitMQ instance added to the Blueprint would remove the need to sign up and pay the bill for another service. If you extend the project as such, please post in Render-Examples on the Render Community Site to share your work.
At Render, when we think about what to paint in our next masterpiece, we always start with user feedback. Unsurprisingly, object storage is one of our most common product requests (upvote plz!) While we work on that, you can use S3 to store and serve static files for your Saleor instance.
If you’re migrating an existing Django application from Heroku to Render, you likely have data in a database that you’ll need to export and import. We heard from readers and Render users that a detailed guide for these steps would provide critical context to support real migrations. Given their importance, we will dedicate a full blog post to those steps. Look out for a language and framework-agnostic guide to the data export and migration process in an upcoming post. Feel free to share about your own experience with data migration.
This post touches on translating app.json and docker-compose.yml files to render.yaml, but there’s more to say on the subject. We dream of automating this for our users. In the meantime, our community would love to read about your translation tricks.

I can’t wait to hear from you about whether this guide helped you migrate your application. If you’ve considered moving a Django app over from Heroku, or if you use Saleor or another open source e-commerce platform on Render, we’d love to see what you’ve built out. Post on your channel of choice, reach out on our community site, or hop into my DMs with your big ideas, or the unvarnished truth. We’re joined at the hip with our developer community and trust me, we want to hear from you!

Rosalind Benoit leads Developer Marketing at Render. She enjoys cycling, rock climbing, and Haruki Murakami novels. You can contact Rosalind at @dnilas0r or rosalind@render.com.

Render, Remix, and Strapi: Let's Build a Productivity Tips App

Chris Castle — Mon, 04 Apr 2022 19:55:43 +0000

What are Strapi and Remix?

Strapi is "the leading open-source headless CMS. It's 100% JavaScript, fully customizable, and developer-first." Think of it as an admin GUI to manage your content. That content could be blog posts or product images or videos. And Strapi automatically generates both REST and GraphQL APIs for the content. Render has been an especially popular place to deploy Strapi because it provides one of the quickest paths to get Strapi running in a production environment.

Remix is "a full stack web framework that lets you focus on the user interface...to deliver a fast, slick, and resilient user experience." It comes from some well-known developers from the React ecosystem and has been getting more and more attention since its open source debut at the end of 2021.

Why Strapi and Remix Together?

Strapi and Remix are both popular and growing open source JavaScript projects. In fact, they topped the list of Node.js Framework Rising Stars in 2021.

But more importantly, these two tools complement each other well. Strapi serves as an ideal back end for a Remix front-end. Strapi gives us many things we, as developers, would otherwise have to build ourselves: a clean abstraction on top of a database, a data admin GUI, and an API for the front-end to use. Remix builds upon the vast React ecosystem, letting you quickly create a front-end and scale it up as needed. It addresses a lot of the time-consuming complexity that has become a regular part of a React developer’s work.

A Productivity Tips App

The inspiration for this app came from Render Engineer Shantanu Joshi: "Over time, everyone develops a Swiss army knife of tips, tricks, and hacks to boost productivity. At Render, we created a #productivity-tips Slack channel for anyone to share their best productivity boosters with everyone on the team."

But Slack doesn't provide a great way to discover tips that others have shared in the channel. You can scroll back through the conversation history, but wouldn't it be nice if there was a web page with a simple list? Using Strapi and Remix, we're going to make a web app to catalog all of these tips and share them with others.

Here's a visual overview of what we'll build.

And here are the steps we’ll take to get there:

Set up your development machine
Configure and get familiar with Strapi
Build the front-end with Remix
Deploy everything to Render

Set Up Your Development Machine

You’ll need Node.js, Yarn, git, a Render account, and a Cloudinary account. If you don't have them already, install the tools and create the accounts linked above (everything's free).

Configure and Get Familiar with Strapi

We'll start with an example repository that contains only a few changes from the default Strapi project scaffolding. Following the instructions in the Set up Strapi section of the example repository's README, run Strapi locally to get comfortable with Strapi and understand the minor code changes below.

Here are the changes I made to the Strapi scaffolding. The links will take you to the code for each change.

Use PostgreSQL in production and SQLite for local development.
Use Cloudinary for media storage, resizing, and serving in production, and use the filesystem during local development. No code changes were necessary to use the local filesystem because that is the default built into Strapi.
Tell Strapi what its public URL is when deployed in production.
Create the Tip content type.

Note: Strapi requires you to define Content Types–effectively, the data schema–in code. When you deploy your Strapi service to production, those Content Types are deployed along with the Strapi application code. However, content for each Content Type only lives within the environment in which it's created. You can read more about this in the Strapi documentation.

In our example, we've created a Tip Content Type in development, and we will deploy that to production. However, any content we create in development won't be deployed to production, and any content we create in production won't be available in development.

Once you've completed the instructions to set up Strapi, including adding some sample Tip content in the Strapi Admin GUI, we'll move on to building the Remix service.

Build the Front-End with Remix

Strapi is mostly plug-and-play, requiring you to write code only when you want to customize its default functionality. On the other hand, building a Remix app requires us to write more code. We can start with a Remix scaffolding, but we still need to create the web page views and API requests to to show our productivity tip data. I've broken the process into five steps to guide you through this code. Each step is a separate git branch in the example repository, and the README for each branch explains the changes in that branch.

You can either start with the step-1 branch and work your way through the changes in each branch or skip to step-5, which contains the final example code that we'll deploy to Render. To start at step-1 and work through the branches, follow the README instructions in each branch.

To skip to step-5, fork the example repository, git clone it, switch to the step-5 branch with git checkout step-5, and then install the necessary dependencies with npm install. Now we can connect the Remix app to Strapi's REST API. To do that,

Copy the .env.example file to .env. This file provides our Remix app with two variables it needs to access the Strapi API: STRAPI_URL_BASE and STRAPI_API_TOKEN.
We need to ask Strapi to generate an API token for use in development. In the Strapi Admin GUI, go to Settings --> API Tokens --> Create new API Token. Name it something like Remix Dev and leave it as Read-only.
Copy the token and paste it into .env as the value for STRAPI_API_TOKEN.
Start or restart the Remix dev server by running npm run dev in the Remix app directory, and also make sure the Strapi server is running by running yarn develop in the Strapi app directory.
If you open http://localhost:3000 in a browser, you should see your Productivity Tips app containing any Tip data you've created in the Strapi Admin GUI!

Nice job! Local development is done! Time to deploy our code to Render.

Deploy Everything to Render

We will use Render Blueprints to make deploying and connecting these two services faster and less error-prone. A Render Blueprint is defined using a single render.yaml file. That file lives in the Strapi repository for these two applications.

Follow the instructions in the Deploy to Production on Render section of the Strapi repository's README. You'll make minor changes to the render.yaml file to make sure it deploys the code from your copies of the example repositories. Then you’ll perform the initial deploy, generate a production Strapi API token, and update the deployed production Remix service with that API token.

Now you have your very own Productivity Tips app with which you and your coworkers can collect and share all your best productivity tips! Start adding tips using the Strapi Admin GUI, and then share the Remix service's URL with your team.

Customize

I encourage you to extend the Remix and Strapi applications to customize them for your needs! Here are some ideas for inspiration.

Add a search bar so your coworkers can search for tips about a specific topic or tool. Algolia’s React InstantSearch library might be useful for this.
Add a login page to restrict use of the Remix app to only approved users. Use OAuth with Google or GitHub login so you don’t have to write code to manage user accounts and password resets. Okta has guides for adding Google, GitHub, and many other login providers to a web application. If you don’t want to use a 3rd party login provider, you could store and manage users directly in Strapi.
Make the screenshot thumbnails for each productivity tip clickable and zoomable. Strapi’s Cloudinary plugin that we're using automatically creates small, medium, and large versions of images you attach to a Tip, but I didn’t have time to add more than the thumbnail view to the Remix app.
Replace Pico.css with a different minimal CSS theme, or even add your own styling to match your company or team’s brand colors.

Let me know if you implement any of these! If they would be useful to others, I’ll consider merging them into the example repositories!

Render Redis

Kelley Rivoire — Wed, 23 Mar 2022 20:50:58 +0000

Today, we're announcing the General Availability of Render Redis. You can now set up a Redis instance in just a few clicks and let Render handle the heavy lifting to operate it reliably and securely. Redis, a widely-used, open source, in-memory key-value store, supports high throughput and low latency reads and writes. This makes it a great fit for uses like caching and queueing.

To get started, create a Redis instance directly from your Render account, or read more in our docs. Try our Redis for free, and when you're ready, select a paid plan starting at $10/month to get more RAM and data persistence.

Why we're offering Redis

Prior to this release, if you wanted to run Redis, you needed to set up, configure, and operate Redis yourself using a Render Private Service, taking engineering time away from your core business. Because of this, Redis has been the number one upvoted product requested by Render users. With our Redis service, getting a running instance is simple, and from there, Render takes care of reliability, security, and operations. Render’s Redis also offers our most-requested features out-of-the-box, including:

A URL for connecting to Redis from outside Render
Access to the Redis CLI
Blueprint support so Redis works seamlessly with Render’s infrastructure-as-code
A Redis metrics dashboard showing memory usage, CPU load, and active connections
Configurable eviction policy to support caching, queueing, and other use cases

And this is just the beginning - we'll continue to add features and make improvements.

What Redis enables for Render users

Already, through our Early Access period, hundreds of Render users have found Redis a convenient way to take on a variety of tasks, from caching user sessions, full pages, and template fragments to running background jobs like parsing large data files or sending e-mails. Early Access Redis users have particularly appreciated the easy setup — a new Redis instance can be created in a couple of clicks, and is instantly ready for internal and external connections — while maintaining the flexibility they needed.

"I was very pleasantly surprised by how easy the process was. I followed the instructions to deploy a Redis instance and connect it to Rails and everything worked right away," said Benjamin Houy, Founder of French Together, who is using Render’s Redis with the Sidekiq framework for Ruby. Another Render user, prolific indie builder Marc Köhlbrugge, shared, "Having hosted Redis instances on Render is yet another thing I no longer need to worry about. Having dedicated configs for different use cases like caching takes out the guess work and lets me focus on building my app rather than having to learn another infrastructure service."

Early Access users, like Damian Legawiec, CTO of vendo, have also appreciated the hands-off operation so they can focus on growing their businesses:

"Our product allows businesses to launch an eCommerce marketplace quickly. A key feature of vendo is supplier onboarding where we make extensive use of background queues on Redis to pull product data from various sources and normalize it. We then use another queue to push that data to other tools to make it easily searchable and downloadable. Building on Render’s managed Redis has allowed us to focus on our product roadmap. Setting it up was a breeze, and it has a big impact on scaling of our product."

Other Early Access users created Render Redis instances to manage rate limits for third-party API requests, queue expensive tasks in the background and remove them from the request flow, and cache data from their CMS to make their sites faster.

Getting started

For users who want to use Redis for queueing, check out our guides for processing requests using the Ruby Sidekiq framework and using the Python Celery library. For other use cases, you can learn more in our docs and create a Redis instance to get started.

Remote Debugging with SSH and VS Code

Chris Castle — Mon, 28 Feb 2022 19:48:15 +0000

I was pretty excited when I discovered Telnet back in the 90s. I could access a command line on servers all over the college campus from my tiny dorm room! I no longer had to trudge through feet of snow and frigid temperatures (I went to college in the U.S. state of Maine) only to find all the computers in the lab occupied. I could connect to them from my room -- even if someone else was already using them!

A more advanced version of me is now shocked at how pervasive the unencrypted Telnet protocol was in the 90s. Back then, I didn't even consider encrypting terminal traffic. Fortunately, others did. After discovering a password sniffer had been used on his university’s network, Finnish student Tatu Ylönen created the first version of the Secure Shell Protocol (or SSH) in 1995, and its use has grown continuously since.

SSH is powerful because it can be used not only to get a command line on a remote computer but also to securely encapsulate almost any kind of data flowing between two machines. It can tunnel pixels from a remote machine's X11 server, sync files with rsync, and even mount a filesystem from a remote machine using SSHFS. SSH has understandably become an essential tool in the software developer's toolkit.

We recently announced the ability to SSH into your Render services, so I was excited to see how I could use it to improve my development workflow.

Why SSH?

We primarily built SSH on Render to allow you to get a command line in containers running a service you’ve deployed. We don’t recommend using it in production regularly, but it can be helpful in a pinch, to run a database migration after a deployment or to check the contents of a file being written to disk.

But there’s a lot more you can do with SSH. For example, you can use scp to copy files to or from your service’s persistent disk. For my own needs, I was curious if I could use Render SSH for port forwarding and eventually remote debugging.

Some of the most frustrating bugs I’ve encountered are those I can’t reproduce locally. I get a bug report from a user along with instructions to reproduce it. I can reproduce the bug in production (running Linux) but surprisingly can’t reproduce it on my Mac. How do I investigate and fix a bug if I can’t reproduce it on my development machine?

Debug Node.js Remotely

Remote debugging to the rescue! Here’s the code for a simplified Node.js HTTP server I will debug remotely.

const http = require('http')

const port = process.env.PORT || '10000'
let host = '127.0.0.1'

if (process.env.NODE_ENV === 'production') {
  console.log('NODE_ENV is set to "production"')
  host = '0.0.0.0'
}

http.createServer((req, res) => {
  console.log('request', req.url)

  if (req.url === '/') {
    res.writeHead(200, { 'Content-Type': 'text/html' })
    res.end('Hello, World!', 'utf-8')
  } else if (req.url === '/exception') {
    try{
      // Some code that causes an exception
      null.toString()
    } catch(e) {
      console.log(e)
      res.writeHead(500, { 'Content-Type': 'text/html' })
      res.end(`An error occurred: ${e.message}`)
    }
  }
}).listen(port, host)
console.log(`Server running at http://${host}:${port}`)

As a refresher, to attach a debugger to the node process if it were running locally, I’d start node with the --inspect flag and then attach VS Code (or one of several other debugger clients) to the process.

$ node --inspect server.js
Debugger listening on ws://127.0.0.1:9229/a9ca58f7-e847-4c31-9e49-82f10ee3a5f5
For help, see: https://nodejs.org/en/docs/inspector
Server running at http://127.0.0.1:10000

Now VS Code would show me variable values and the call stack at any point during the program’s execution.

But getting this working when the node process is running on Render is not as straightforward. Render accepts traffic from the public internet for only one port for a Web Service. My Web Service is already listening on port 10000 for HTTP traffic, so I can’t expose the debug port publicly. Moreover, even when Render starts supporting traffic on multiple ports, exposing the debug port publicly is unsafe! Fortunately, the Node.js documentation provides guidance on enabling remote debugging safely.

Configure Render

The first step is to edit the Start Command for the service from the Render Dashboard. Instead of running node server.js, I have to run node --inspect=9229 server.js. 9229 is the default port the Node.js debugger will listen on, but I want to be explicit to avoid confusion. Then I add an SSH key to my Render account. This only needs to be done once for each Render account.

While the service restarts with the new start command, I’m going to configure VS Code.

Configure VS Code

VS Code requires a launch.json configuration file to connect to the node process as a debug client. To create this, open .vscode/launch.json (create this folder and file if needed) and click Add Configuration… in the bottom right.

Configuring VS Code to remotely debug a Node.js process

Select Node.js: Attach to Remote Program, and VS Code will generate a template with some values that need to be filled in. The address and port are where VS Code will try to connect to the node process, and the remoteRoot is the directory to which code is deployed on Render. This path won’t change if you’re using the native Render Node environment instead of Docker. Here is the launch.json I used.

{
  "version": "0.2.0",
  "configurations": [
    {
      "address": "localhost",
      "localRoot": "${workspaceFolder}",
      "name": "Attach to Remote",
      "port": 9229,
      "remoteRoot": "/opt/render/project/src",
      "request": "attach",
      "skipFiles": [
        "<node_internals>/**"
      ],
      "type": "pwa-node"
    },
  ]
}

Create the SSH Tunnel

Now that the Web Service is using the new Start Command, I can create an SSH tunnel between the node process running on Render and my local development machine. First I grab the ssh command for my Web Service from the Render Dahsboard.

The ssh command for a Web Service

I need to modify it so that ssh creates a tunnel between two ports instead of giving me a command line.

ssh -N -L 9229:localhost:9229 srv-c804oa46fj3d2u40bpq0@ssh.oregon.render.com

The -N flag tells ssh to not execute a remote command after establishing the connection. Normally when you ssh into a machine, a command like bash¹ is run. I don’t need that because I only want ssh to forward TCP traffic back and forth.
The -L flag instructs ssh to create a tunnel for TCP traffic such that connections to port 9229 on my local machine are forwarded to localhost:9229 on the remote machine.
Finally, srv-c804oa46fj3d2u40bpq0@ssh.oregon.render.com is the username and domain name ssh will use to create the connection.

Start Debugging

Now I can start the debugging session! In VS Code I’ve opened the project deployed to Render, switched the left side panel to Run and Debug, and then clicked the play button at the top to start debugging.

VS Code connected as a debug client to a remote node process

Let’s walk through everything I can see and do now. On the bottom, a Debug Console appeared, which now shows me the logs from my service (stdout and stderr). On the left within the Loaded Scripts panel, I select the server.js file so that I can add breakpoints and see which line program execution is on.

To confirm that remote debugging is working the same way local debugging does in VS Code, I add a breakpoint on line 15.

Add a breakpoint to line 15

This is part of the code that is executed when a request to / is made. I make a request to that path in a new browser tab, and it looks like everything is working as expected! I can see that execution paused on line 15, and VS Code shows me the state of the req and res local variables and the call stack.

Program execution paused at the breakpoint

Earlier in this post, I said that remote debugging is helpful to investigate an issue observed in production but not on my local development machine. Let’s say the bug causes an exception, but I don’t know which line of code is generating the exception. I can tell VS Code to automatically pause program execution when it hits both caught and uncaught exceptions.

Break on caught and uncaught exceptions

To test this out, I make a request to /exception. VS Code automatically pauses execution on the line that generates the exception. This example is contrived because I purposely wrote this line to generate an exception. Still, it’s a simple demonstration of how you can remotely debug exceptions before you have to handle a real-life (and more complex) scenario.

VS Code pausing program execution on a caught exception

More to Explore

VS Code’s remote debugging feature can also help if you need to investigate CPU or memory use. The Flame Chart Visualizer for JavaScript extension provides a real-time chart of CPU and memory use of the node process and a flame chart to help you identify CPU hotspots in your code.

Example flame chart

And you can use VS Code to debug more than just Node.js remotely: use it to connect to an Elixir cluster, a Go process, a Ruby process, and much more. There are VS Code extensions available for all popular languages that enable remote debugging for that language.

What are you going to use Render SSH for? Let me know in a comment below!

The shell that’s run is configured per user on the remote machine. You can also override the command by appending a command to the end of the ssh command. ↩

Add Password Protection to Any Site with OAuth2 Proxy - Plus Social Logins

Chris Castle — Mon, 14 Feb 2022 19:51:52 +0000

Continuing on the topic of adding password protection to your site, let’s look at using a reverse proxy server to password protect a service you have deployed to Render. The previous post on this topic covered adding password protection to a static site using PageCrypt. Now we’re expanding beyond static sites.

What’s the problem we’re trying to solve? Say you have an existing Ruby, Node.js, or Python web service (it could be one of our native environments or a Dockerized app), and you want to protect it with password authentication. Maybe you don’t want to touch the existing service’s code because it works well, and you’re concerned about inadvertently introducing a bug. Or perhaps you have multiple services to protect, and you don’t have time to implement password protection for each of them.

An interesting way to solve this problem is to put a reverse proxy in front of your existing web service(s).

What’s a reverse proxy server? It’s a server that acts as a gate and traffic cop guiding incoming traffic to the service that can respond to it. Typically that service is not exposed to the public internet. The scenario we’ll look at below shuttles web traffic between the public internet and a Render Private Service, which is protected from the public internet and only accessible to applications you own. NGINX and Apache are examples of general-purpose web servers that can also be used as reverse proxies, but there are many purpose-built ones like Træfɪk and Caddy.

Reverse proxies are commonly used for load balancing or TLS termination but Render already provides these features to you out of the box. In our scenario, we will deploy a reverse proxy specifically for authentication and authorization.

The reverse proxy we’re going to focus on in this post is called oauth2-proxy.

What is it good for?

Adding social login to your site – i.e., login managed by another service like GitHub, Google, or one of the other fourteen supported OAuth providers
Cases in which you can’t or don’t want to change the code of the web service you want to protect
Maintaining clear separation between auth code and your web service code
Language flexibility: your web service doesn’t need to be written in the same language as oauth2-proxy (which is written in Go).

What are the drawbacks?

Deployed as an extra service, which has a cost (but you can use Render’s free plan)
Configuration of OAuth can be confusing, but the oauth2-proxy documentation explains it well

What is it, and how does it work?

A coworker shared oauth2-proxy as part of a previous Render blog post, and I think it’s pretty cool. It does two things. First, it authenticates a user with an OAuth 2.0 flow. Then, after successful authentication, it acts as a reverse proxy, forwarding web requests to a Private Service behind it. The Private Service shouldn’t be exposed to the public internet, otherwise, the user will be able to access it without authenticating.

Are you wondering what OAuth 2.0 is, or do you need a refresher on it? (If not, you can skip to the diagram.) OAuth 2.0 is a standard defined by the IETF OAuth Working Group. It’s a ubiquitous authorization method that lets you delegate authentication and often authorization to another trusted service. For example, you can use Google to log in to the Render Dashboard.

OAuth 2.0 specifies a multi-step, production-hardened flow we can follow to allow Google to authenticate a user’s credentials and securely tell us that the user is, in fact, the owner of a specific email address, say, user@example.com.¹ Armed with the fact that we confidently know this is user@example.com (and not sneakyblackhat@example.com pretending to be user@example.com), we can then show the user the resources they have access to — e.g., a web page, some data, or their daily New York Times crossword puzzle.

Quick detour: You may have noticed I’ve used two different words that begin with auth: authentication and authorization. People often confuse them or mean both when they say one. So what’s the difference? Authentication verifies that a user is who they say they are. Authorization determines the user’s permissions within your app. In the example above, if a user logs in to Render with Google credentials, Google handles the authentication, assuring us the user is who they say they are. After the user is authenticated, Render needs to decide what services and teams to show them. We look up the services and teams they are authorized to manage — those created by them or shared with them by another Render user.

Traffic Flow

So how does oauth2-proxy work? Let’s look at the flow from the perspective of a user trying to access your app. Note that this flow is specific to oauth2-proxy, not a generic OAuth 2.0 flow.

The browser makes an HTTP request to your site, which is directed to the oauth2-proxy service.
oauth2-proxy responds, prompting the user to authenticate themselves with an OAuth 2.0 provider you’ve configured. In this example, we’ll assume it’s Google.²
The browser is redirected to a Google login page.
The user enters their credentials for Google to verify.
Upon successful authentication, Google redirects the user back to your oauth2-proxy service along with a unique token — a query string parameter that Google refers to as an ID token.
oauth2-proxy makes an HTTP request to Google containing the ID token along with a client ID and client secret that Google has uniquely assigned to your instance of oauth2-proxy. This step is a necessary part of the OAuth flow. A malicious user could spoof the request with a made-up ID token. This out-of-band request between oauth2-proxy and Google verifies the ID token was generated by Google from a recent login for this user.
Google responds, verifying the validity of those three values and finally confirming to oauth2-proxy the user is who they say they are!
By default, oauth2-proxy now authorizes all traffic from this user passing it to your Private Service. However, you can configure oauth2-proxy’s authorization rules in several ways. You can restrict access based on membership in a Google Group, GitHub org, or GitLab project. oauth2-proxy can also pass the username to the Private Service which can implement its own authorization logic.

Implementation

I forked the oauth2-proxy repository and made a few changes so that you can deploy a working example to Render for free.

Before the deployment starts, you’ll be asked for three values: an OAuth provider, client ID, and secret. The oauth2-proxy documentation explains how to generate a client ID and client secret using any one of fourteen supported OAuth providers.

I’ve chosen Google as the OAuth provider for an example deployment: try it out. I'm using oauth2-proxy's default login screen, but you can customize its design. You’ll be prompted to Sign in with Google. After Google authenticates your credentials (which aren’t shared with me or Render), your requests will be proxied to a Node.js service deployed to Render as a Private Service. Private Services on Render are protected from the public internet and only accessible to applications you own. The oauth2-proxy service receives a request from your browser, passes it to the Node.js service, and then passes the Node.js service’s response back to your browser.

More to Explore

If oauth2-proxy doesn't suit your needs, there are some projects that have spun-off from oauth2-proxy like pomerium and BuzzFeed's sso. In addition to the open source library, Pomerium offers a paid service with a GUI to help IT staff more easily manage user permissions. BuzzFeed's sso builds upon oauth2-proxy by separating the domain used for auth from the domain used for the proxy (among several other changes).

If you're interestd in learning more about OAuth, there is ongoing work to evolve the OAuth 2.0 standard. OAuth 2.1 exists in a draft state, and GNAP is a new IETF Working Group developing "a next-generation protocol that encompasses many use cases that are challenging to implement with OAuth 2.0."

Are you using oauth2-proxy or another reverse proxy with password protection? Let me know what worked and didn't work for you! I'm curious to learn more, and I'm sure others will find it helpful to hear about your experience.

It doesn't necessarily have to be an email. It could be a username or a user ID or any other identifier. ↩
You could even deploy your own! ↩

Password Protect Static Sites with PageCrypt

Chris Castle — Wed, 02 Feb 2022 20:25:53 +0000

Password protecting static sites is tricky. You could use window.prompt() to ask a site visitor to enter a password before the site content is revealed, but a resourceful visitor will quickly get around this with right-click, view source (or curl or numerous other ways). All of the site's HTML, CSS, and JavaScript are served to the web browser, and they constitute the entirety of the site.

If you are using a backend API that the static site pulls data from (like many single-page apps do these days), you could require authentication for API requests, but this doesn't protect the HTML, CSS, and JavaScript.

In trying to find a good solution for this for Render users, we discovered PageCrypt. It's a free, open source library that allows you to password protect these static assets securely. Let's investigate how PageCrypt works and test it out!

What's it good for?

Protecting a static site
Cases where you don't need (or can't run) backend code

What are the drawbacks?

Only encrypts a single HTML file by default
Only supports a single shared password (no per-user passwords)

What is it, and how does it work?

PageCrypt is a novel solution to password protecting HTML without a backend. It’s a library you can use as part of your site’s build step or as a command line tool. It uses the Web Crypto API -- currently supported by all major browsers -- and a password to encrypt an HTML page, which you can then host on any static hosting platform, including Render! An HTML page encrypted with PageCrypt prompts the viewer for a password. Upon entering the correct password, the page is decrypted and its content replaces the password prompt.

Example static site password protected with PageCrypt

One potential concern with PageCrypt is that it only encrypts an HTML file by default. If you want to encrypt your CSS and JavaScript files, you’ll have to inline them in the HTML file. The same applies to images and any other binary assets; you’ll have to inline them as Data URIs. As with any authentication and authorization solution, you’ll want to determine what’s acceptable for your security requirements. Maybe you’re comfortable with the risk of images leaking but have higher security requirements for your JavaScript. In that case, the HTML page can link to the image files but should contain all your JavaScript. You can use many static site build tools to automate inlining assets in HTML. Webpack, Gulp, or Grunt are just a few that might be useful.

PageCrypt also doesn't allow users to have individual usernames and passwords. It only works with a single, shared password. If you need the more fine-grained control provided by user accounts, check out a service like Auth0.

Try it out

Adding PageCrypt to the build step of a Hello World static site was straightforward. The instructions in the project’s README provide clear guidance on how to use PageCrypt as a library with browser-executed JavaScript, Node.js, or Deno, and how to use it as a CLI tool. I used the CLI in the build step of my example static site.

Add PageCrypt to your project as a dependency:

$ yarn add pagecrypt

Then update the build step in package.json to use the CLI:

{
...<snip>...
  "scripts": {
    "build": "pagecrypt src/index.html dist/index.html $PASSWORD && cp -R src/css dist/"
  },
...<snip>...
}

The password is set using the $PASSWORD environment variable since we don’t want to store that in the code. Using an environment variable also allows you to change the password and rebuild the site quickly.

Here’s an example deployment of the site. The password is s3cr3t.

To get a deeper understanding of how PageCrypt works, try entering an incorrect password. Then right-click and view the source of the page. PageCrypt generated the contents of this page during the build step. Your original page content is encrypted inside a hidden <pre> element at the bottom of the HTML document.

Encrypted HTML page inside the <pre> element.

After the correct password is entered, your page content is decrypted and shown.

To make it easier for users to access password protected pages, PageCrypt also allows you to create a "magic link" that decrypts the page without prompting the user for a password. The format for the magic link is https://<link-to-your-page>#<password>, placing the password in a URI fragment. Check out the project's README section about magic links to better understand the security implications. When your browser goes to a URL containing a URI fragment, the fragment isn't sent across the internet, but it does remain in the browser's history.

Extend

It would be interesting to extend PageCrypt to do a number of things:

Automate the inlining of CSS, JavaScript, and image files
Encrypt multiple HTML files
Encrypt multiple files, including CSS, JavaScript, and image files

If you do end up extending it in your build process, let me know!

Explore

This version of PageCrypt is a rewrite of an older version of PageCrypt. That older version also inspired a few spin-offs that you might find useful:

Python CLI for PageCrypt
PowerShell CLI for PageCrypt
R-wrapper for PageCrypt
StatiCrypt - A separate but similar project

Now try it out yourself! You can deploy the code to Render for free. The README provides step-by-step instructions.

Git Organized: A Better Git Flow

Annie Sexton — Thu, 13 Jan 2022 18:58:36 +0000

Imagine this: you've been paged to investigate a production incident, and after some digging, you identify the commit with the breaking code. You decide to revert the change:

$ git revert 1a2b3c

Unfortunately, in doing so, a new bug is introduced! As it turns out, hidden in that old "broken" commit was some code that another part of the app depended upon, and when you reverted those lines, it left the site once again in a broken state. 🙃 Oh dear.

How can situations like this be avoided? To answer this question, we first need to examine how these types of commits come to be.

A Common Git Flow

Let's take a look at a common git flow when building a new feature:

Create a new branch off of main.
Create commits as you go to save your work and fix bugs you find along the way.
When the feature is complete, make a pull request.
Merge branch into main once PR is approved.

This flow might feel quite familiar to you, and that's fine. It's how many of us were taught to work with git. However, there are two problems with this approach. The first problem we've already discussed is that some commits may contain incomplete work when you simply commit as you go. This makes reverting quite risky.

The second problem is that it can make reviewing pull requests very tedious. For example, what if you've been asked to review a recent PR in which the author states that, on top of adding a new feature, they fixed an unrelated bug as well. The PR consists of changes across dozens of files. Looking at each commit individually does not illuminate which changes pertain to the bug fix and which are for the new feature. Additionally, you notice some changes that seem unrelated to anything in the description of the PR. Clearly, this will not be a quick review.

Now, as lovely as it would be for each commit to neatly relate to only one change, that's a tall order to fill when you're in the midst of development. Tangents and rewrites are just part of the process. Our work is rarely so linear, and our git commits tend to reflect this.

So how can we guarantee that our git history is tidy and easily reviewable while also accepting the somewhat tangential nature of development? By modifying this basic git flow just slightly, we can create a better process that accomplishes just this.

An Improved Git Flow

The following approach was inspired by my coworker, Dan Wendorf, whose git flow tends to revolve around one core principle: do the work first, clean up the commits later. The benefit of this flow is that it separates the engineering work from the commit writing. In the end, we'll be left with a sequence of commits that are logically grouped, each relating to one main change in the code, thus cleaning up our git history and paving the way for a quicker PR review.

We can break it down into three steps, as follows.

Step 1: Make your changes

The first step isn't too different than before. Start by creating a new branch and getting to work on making your changes. Don't worry too much about writing descriptive commit messages just yet, as these won't be included in your final PR. For now a simple, "work in progress" or "WIP" message will do, or something that will help you remember what was in that commit like "WIP: Started building new model". The purpose of these commits are to make sure you don't lose work and provide some general guideposts along the path of that work.

$ git checkout -b my-feature-branch

...make changes...

$ git commit -m"WIP"

...make more changes...

$ git commit -m"WIP"

...make even more changes...

$ git commit -m"WIP"

In this step, it's okay to leave the codebase in a broken state or to commit half-baked features. This will all get cleaned up later.

Step 2: Reset

Once you've finished making your changes, it's time to prepare your work for some "git clean up." To do this, we'll run the following command:

$ git reset origin/main

Without any extra arguments, git reset won't change the working tree, so your code won't change — all the work you've done will still be there. But because you've reset to an older commit, git status will show all the changes you've made since you started building your feature. It will look like you did all the work but never made any of those "WIP" commits earlier.

$ git reset origin/main
Unstaged changes after reset:
M       src/components/Footer/Footer.tsx
M       src/components/Nav/Nav.css
M       src/components/Nav/Nav.tsx
M       src/components/Posts/Post.tsx
M       src/components/Posts/PostList.tsx

$ git status
On branch feature-branch
Your branch is behind 'origin/feature-branch' by 3 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   src/components/Footer/Footer.tsx
        modified:   src/components/Nav/Nav.css
        modified:   src/components/Nav/Nav.tsx
        modified:   src/components/Posts/Post.tsx
        modified:   src/components/Posts/PostList.tsx

In case you get in over your head here, don't worry — you can always bring back your original commits! Every commit you make lives in your .git folder, even after a reset. Even though it might seem like they've disappeared, they're still there, hiding.

If you want to go back to a commit where things weren't broken, git reflog will show you a timeline of every commit you've referenced in your local repository, even across branches. Run git reflog to find the commit you want to return to and then run git reset <commit-sha>. This command will point the HEAD of your current branch to that commit, and you're back in business!

From here, we're ready to start making our new commits.

Step 3: Create new, logically-grouped commits

Now, take a look at all the files you've changed. Are there any that you can logically group? For example, all the dependency updates or changes related to a particular model. There's no "right" way to group files, so use your best judgment here. Add these files to your staging area, and make a commit describing the changes.

$ git add src/components/Nav/Nav.css
$ git add src/components/Nav/Nav.tsx
$ git commit -m"Added new styles to navigation"

$ git add src/components/Posts/Post.tsx
$ git add src/components/Posts/PostList.tsx
$ git commit -m"Updated author images on posts"

$ git add src/components/Footer/Footer.tsx
$ git commit -m"Fixed responsive bug in footer"

If you haven't changed many files, you might not need more than one commit, but we can often make our pull requests much easier to review by splitting up our changes into human-readable, easy-to-follow commits.

What if the same file contains multiple changes that should be grouped separately? It's possible to stage part of a file using git add --patch (or git add -p). Some code editors also provide a way to stage a range of changes rather than a whole file.

Be mindful of not leaving your codebase in a broken state during this step. Remember, a huge reason we're cleaning up our commits in the first place is so that nothing will break if we ever want to revert our changes. After making one of these new commits, you can git stash the rest of the unstaged changes and test that everything's still in working order. If you realize you should have included another file in that commit, you can git stash pop to bring back the other changes, git add the missing file, and perform a git commit --amend . This command will replace the last commit with a new one with the same description, including the old commit and the change you just made.

The Final Result

Once you've split your work into logically grouped commits, you're ready to create your pull request! The final result is a set of changes that your colleague can review one commit at a time in manageable chunks.

The benefit of this git flow is that it allows for the fluidity of typical development while also providing some much-needed order to maintain the repository's history.

Use One-Click Deploys for Secure Online VS Code

Rosalind Benoit — Wed, 08 Dec 2021 17:49:13 +0000

Introducing "Deploy To Render"

I’m currently getting up and running with Render. Luckily, getting new users started with very little friction is core to our mission, and it shows. One of my biggest challenges in helping to maintain and grow the Spinnaker project was the friction around getting started with it. New users and potential contributors often had a difficult time with operations or simply with deploying Spinnaker for the first time to check it out. They became frustrated, and they moved on. This made my job hard.

I think that’s why, for my very first project here, I gravitated towards playing with Render’s awesome 1-click deploy feature, which takes a few minutes to learn and use successfully. Setting up a Deploy to Render button also taps into our (expanding) infrastructure-as-code functionality, and that’s my jam.

I get excited about use cases for Deploy to Render buttons:

Enablement! Remove institutional/project knowledge as a barrier to entry. Got an OSS project? Got new reports or colleagues who need to deploy services to become productive? Level the playing field.
Testing & CI! Incorporate polished, simple, and complete deployments into your process so you’ll know everything is working and can quickly (or programmatically) demonstrate.

I have browser-based VSCode on the brain after reading David’s post about building hosted dev environments with VSCode, Tailscale, and Render. So, the first app I try deploying is OpenVSCode Server, a neat project Gitpod recently open-sourced that shares a browser-friendly implementation of VSCode with a simple upgrade path and deployment strategy. It lets folks run the latest VSCode version on a remote server, and access it from anywhere in a browser.

Open VSCode joins my crowded tab landscape, allowing me to quickly edit a render.yaml file in browser.

Creating a `Dockerfile` for GitPod OpenVSCode Server

Gitpod makes OpenVSCode Server easy to deploy in several ways, including by running it in a Docker container, which is the most Render-friendly approach. Given a stable Docker image in a public registry such as Docker Hub, it’s quick to deploy that image on Render. My first newbie challenge is figuring out exactly how.

GitPod’s instructions for running the server in a Docker container are:

docker run -it --init -p 3000:3000 -v "$(pwd):/home/workspace:cached" gitpod/vscode

I can’t wait for the day that this becomes ~1-click, and we can deploy registered images on Render in a single step. While we work on this part of our roadmap, there’s a simple workaround you can use in the meantime.

First, fork the project and add a basic Dockerfile to it that pulls the image you want to deploy:

FROM gitpod/openvscode-server

ENTRYPOINT [ "/bin/sh", "-c", "/home/openvscode-server-v$OPENVSCODE_SERVER_VERSION-linux-x64/server.sh"]

USER vscode-server

Meet Blueprints and `render.yaml`

Next, meet render.yaml. A render.yaml is a Blueprint spec: it allows you to define environment variables, secrets, disks, build directories, start commands, healthchecks, deployment regions, and other configuration settings for your application without using a GUI. Since the docker run command in Gitpod’s OpenVSCode documentation mounts a volume, I need to add a volume mount to my Render service. I can easily add that in render.yaml:

services:
- type: web
  name: gitpod-vscode-example
  env: docker
  repo: https://github.com/render-examples/gitpod-vscode-example.git
  envVars:
    - key: OPENVSCODE_SERVER_VERSION
      value: 1.60.0
  disk:
    name: data
    mountPath: /home/workspace
    sizeGB: 1

With my simple render.yaml and Dockerfile in place in the root directory of the cloned project, I am ready to deploy my new fork of OpenVSCode Server onto Render. I use the New > Blueprint drop-down to begin a new project, find the repository in the GitHub search, give the project a name, and that’s it. I click Apply and watch it deploy via the Events stream. When it’s ready, I can click on the public address from the service page in the Dashboard, and enter my nifty new VSCode environment.

I click here to access my OpenVSCode Server instance.

Setting Up 1-Click Deploy

With this up and running, and a bit more confidence in my Render skills, I think, hmm, how can I make it ridiculously easy for anyone else who wants to use Render to check out this project? Sure, as long as my repo is public, anyone can use it to set the service up themselves, but only by consulting a guide (like this one : ) to make sure that all of the Docker settings and advanced features like disk mounting are configured correctly. I want to remove all of that overhead.

I thought setting up a Deploy to Render button would be more complicated, but it turns out I have already completed 90% of the effort. With render.yaml already in place, all I need to do is paste a single line of markdown into my README.

[![Deploy to Render](https://render.com/images/deploy-to-render-button.svg)](https://render.com/deploy)

Phew! Check out my Deploy to Render button:

Click to deploy OpenVSCode

Next Steps: Authentication, and Beyond!

Now, a developer’s work is never done, and this is no exception. As David pointed out in his blog, “I don’t want to invest more in configuring my code-server instance until I figure out a way to make it secure.” Yeah, browser-based VSCode feels much less safe, and is much less useful as a tool for standardizing remote dev environments, without more security. So, my next challenge is to deploy an authentication service on Render to provide auth for my web services.

Another handy open source project, OAuth2-Proxy, is up to the task! To integrate the two projects in a secure environment, I venture further into using Blueprints. I learn to consolidate my infrastructure into a single render.yaml file, and to use the sync: false attribute when defining a key to allow users to securely provide their own secret values in the Render Dashboard at deploy time.

Here, I define the secret values for my OAuth2 app that I don’t want in source control.

Check out the Deploy Secure Open VSCode with OAuth2-Proxy Guide now, and deploy it to Render yourself with this button:

Click to deploy OpenVSCode with Authentication

Stay tuned to read more about other ways to add authentication to web services...in an upcoming blog post : )

Linux Lite

I’ll leave you with one final Deploy to Render adventure. A little background: I have chosen my entry to Render as the opportune time to return to my roots as a desktop user of Linux. While I have more recently administered RHEL systems and of course, used Unix as a developer, I have not used Linux as my primary desktop since high school. But Fedora Core 1-4 will always hold a special place in my heart as the playground on which I tried [and failed?] to become great at Linux. My style has always been lazy: I’m not a workstation-optimization junkie; I muddle through, doing just enough to make things workable. I’m psyched to be doing so again, on a delightful new brick of a ThinkPad P15 and Ubuntu 20.04. Especially since I have the support of Render’s UX, and can deploy changes to the cloud and use preview environments when messing with local configuration gives me a headache. Look for Tweets, StackOverflows, and general cries for help from me in the coming months as I refine my developer environment into something kickass, and weed through the occasional need to kill Gnome because my cursor has randomly turned into the screenshot-selector crosshairs and won’t...curse [restarts X11 server].

Lest I get discouraged, Render once again has my back. I can always fire up this (inexplicably popular) OSS project and enjoy technicolor dreams of Windows 11:

A React & SCSS web app replica of the Windows 11 desktop experience - why not?

Deploy Your Own Windows 11 to Render (for free)

Go to https://dashboard.render.com/select-repo?type=web (create a Render account and link your GitHub)
Paste in the repo's URL and select it: https://github.com/blueedgetechno/win11React
Give it a name and choose the Free plan.
Click Create Web Service.

Enjoy our Render Examples and so much more when you start playing with our new plans!

Hi! I’m Rosalind, the newest member of Render’s Growth Team. A former on-call systems engineer, I somehow fell down the Developer Marketing rabbit hole through stints working on DevOps and open source projects for Puppet, Armory, and the Continuous Delivery Foundation. I have a background in education, and I love working with developers learning to solve problems in new ways, with new tools. This often requires me to do some learning myself 🙃

How to Build an Anycast Network

Jake Malachowski — Mon, 25 Oct 2021 20:54:28 +0000

When you type a URL into your address bar, your browser performs a DNS lookup to resolve the human-readable domain name to an IP address necessary for networking software, for example 216.24.57.1. Armed with that IP, how do the packets comprising the request actually get from your local machine to a server somewhere in the world capable of handling that request? How do you ensure those packets route to the server that can handle the request most efficiently?

Serving traffic as efficiently as possible, regardless of where it originates, is a critical requirement at Render. One answer to this challenge is to deploy a global fleet of servers to create an anycast network. What is an anycast network? What is it good for? How can you build your own? This post will answer all of these questions, but we’ll first need some background on the building blocks of global networking.

A Brief Overview of the Internet

The path that an HTTP request takes between autonomous systems communicating via BGP.

The Internet is the greatest decentralized network in the history of mankind. There is no central authority that controls who is allowed to connect or how you can use it. How do we manage billions of internet-connected devices without any single organization in charge of maintaining the system? This is accomplished through the coordination of many independent entities called Autonomous Systems (AS). ASs are the networking backbone of the internet. These entities, often managed by ISPs or large technology organizations, are responsible for handling traffic for the IP addresses they manage and advertising the paths to all other IP prefixes of which they are aware. Connections between ASs, also known as peers, are established through the manual configuration of connections between routers.

Once a connection has been established, ASs use the Border Gateway Protocol (BGP) to coordinate with each other. BGP carries the information necessary for ASs to determine the optimal path to a target. Many factors can be used to define "optimal", but the most common heuristic used is choosing the path with the fewest number of "hops" between ASs before reaching the destination. Each AS will store the best path for all IP prefixes in its routing table. When a route is added or removed, the AS will update its routing table, if necessary, and advertise the change to its peers so they can do the same. Each peer sends keep-alive messages to each other at regular intervals. If an AS does not send a keep-alive message before the configured timeout, the peer will stop advertising the AS as a reachable hop and packets will use a different path to reach the target if it exists.

What is Anycast?

An anycast network is two or more servers advertising the same IP address from different locations. Why would we want to do this?

Serving traffic from a single location often lacks the redundancy required for critical or latency-sensitive applications that serve users around the world. In the worst case of a global round-trip request, you can expect 300 ms of latency just in transit time. This doesn't account for the time it takes the server to process the request. Chain a few of these requests together and you're looking at a very sluggish application and a frustrating user experience. For applications that require high availability and low latency, you will want an architecture that has the following characteristics:

Globally distributed
Automatically routes traffic to the optimal server
Tolerates failures of individual servers

We can leverage the advanced routing capabilities of BGP to create a fault-tolerant, low-latency system by building an anycast network. By advertising an IP from many servers around the world, we can rely on BGP to route users' requests to the nearest Point of Presence (PoP) -- or server, in other words -- that advertises the IP. When one of those PoPs fails, it will stop sending keep-alive messages to its peers, connected ASs will stop advertising the path, and traffic will reroute to a healthy PoP.

How Render Uses Anycast

How Render uses anycast to route traffic to the proper origin

When you deploy a web service or static site on Render, you always get a subdomain of onrender.com that makes your service accessible from the internet. In many cases, users want to use a custom domain that they own instead of an onrender.com subdomain. Users can create a DNS A record for their custom domain that points to an IP address provided by Render.

Render strives to create the most delightful developer experience possible. One way we do this is by making it as simple as possible to configure your DNS settings for custom domains. We provide a single IP address (our anycast IP address) to use in your DNS settings. When a request reaches one of the servers advertising that IP, we will forward it to one of possibly several origins around the world, depending on where your site is hosted and whether it's a web service or a static site.

We can't make any assumptions about where traffic will originate, and we can minimize latency by routing requests to the server closest to the end-user that's capable of responding to the request. For web services, the request always needs to go to the origin server--the server you've deployed to. But for static sites, we can rely on BGP to route requests to the server closest to the end-user; we advertise our IP from anycast servers worldwide, which inspect each request and forward it to a server capable of responding. So, the server that serves a request is one of hundreds of geographically distributed CDN edge servers containing a cached copy of your static site. If one of those servers fails, its peers will stop advertising the route and the traffic will be sent elsewhere.

Building an Anycast Network

Now that we understand the components that make up an anycast network, as well as the use cases for it, we're ready to dive into how you can build your own. At a high level, the steps for setting up anycast are:

Obtain an Autonomous System Number
Acquire an IP Address
Find a Hosting Provider
Configure BGP

Obtain an Autonomous System Number

The first step for setting up an anycast network is getting an autonomous system number (ASN). An ASN is a unique identifier that other ASs will use when announcing a path to reach you via BGP. Having an ASN is also a prerequisite for acquiring an IP address. ASNs are managed by five Regional Internet Registries. As the name suggests, each registry is responsible for managing the ASNs within specific geographic regions of the world.

Each registry has different requirements for acquiring an ASN. If you’re based in the United States, you'll work with ARIN to get yours. Their process is straightforward. You just need to submit a request with some supporting documentation along with an explanation of why you need the ASN. ARIN grants ASNs to organizations for two purposes:

Unique Routing Policy: Organizations who want to define routing policies that differ from their connected peers.
Multi-homed: Organizations that will be peering with multiple providers. Multi-homing is usually done to improve coverage and resiliency to failures of individual providers.

When Render applied for an ASN, we wanted the ability to advertise from multiple providers, so we used multi-homing as a justification for receiving an ASN. After submitting our application, ARIN responded with our ASN within a week.

Acquire an IP Address

Now that you have an ASN, you can acquire an IP block to advertise. The minimum IP prefix that can be advertised is a /24 for IPv4 and a /48 for IPv6. This limit exists to prevent the routing tables that ASs need to manage from growing too large.

You are going to need to decide whether you want to buy or lease your IP block. The dynamics at play here are similar to buying and leasing most things. Buying an IP block comes with a large upfront cost, while leasing requires less capital at the start but you will be paying a fee for as long as you use the IP block. Leasing also comes with additional terms and conditions on how you can use the IP block. If you have the capital and intend to use the IP block for an extended period of time, it likely makes sense to buy. Almost all available IPv4 addresses have been allocated and demand for them continues to rise. You can expect the cost to obtain them to continue to grow until IPv6 adoption is widespread enough to justify dropping support for IPv4.

Since we knew that we would need the IP block for the foreseeable future, we decided to buy one. Asking all of our users to update their DNS records would be extremely disruptive, so we wanted to ensure that our IP block would remain stable for as long as it was in use. We had a good experience using IPv4 Global to purchase our IP block. The remainder of this post will assume that you have chosen to buy instead of lease.

There are a couple of things you should verify before buying an IP block. The block needs to be registered with the Regional Internet Registry that you acquired your ASN from, or it must be transferable to them. You will also want to verify that the IP addresses in the block are in good standing. Some IP addresses have been used for nefarious purposes and end up on widely-used blocklists. There are many free services available that will check an IP address against the most popular databases of bad IPs.

Once you purchase your IP block, you will need to go through the process of transferring ownership from the previous holder of the IP block. The service you use to purchase the block will likely guide you through that process, which will involve working with your Regional Internet Registry to transfer ownership. The exact steps will depend on the registry and whether the block needs to be transferred between registries. You can look at ARIN's documentation to get an idea of what's involved in the process.

Find a Hosting Provider

Now that we have an IP address to advertise, it's time to determine what providers we will use to advertise it. Not all providers support BGP, so you're going to want to find ones that have the capability. In our anycast network setup process, we decided to go with Vultr and Equinix Metal.¹ The latter is a bare metal provider rather than a VPS provider, so you should verify whether that makes sense for your use case before deciding to go with them. We chose Vultr because they had global coverage, low cost, and thorough documentation on how to set up BGP. You can find discussions comparing VPS providers on forums like LowEndTalk to determine what provider makes sense for you.

Configure BGP

The next step is to set up your server and start accepting traffic for your anycast IP address. After getting your application running on the server, you can get started on configuring BGP.

When we configured BGP, we first needed to submit an application to Vultr requesting that they enable BGP for our account. They had us send a Letter of Authorization that allowed them to advertise our IP address from their platform. As a part of this process, Vultr created a record in the Internet Routing Registry on our behalf that signals to the rest of the internet how to handle traffic for our IP. It's a great UX to have Vultr take care of this for you. However, it’s important to note that Vultr will delete this record if you end up migrating away from them. You must create a new record before they delete their copy to avoid any service disruptions.

The next step is configuring BGP on your server. You're going to need to choose a BGP daemon to handle the advertisement. The two most common are Quagga and BIRD. We decided to use BIRD since Vultr recommended it and they have excellent documentation for getting it running.

After installing BIRD, create a file called /etc/bird.conf with the following contents:

router id 203.0.113.123 # IP of the Vultr server running BIRD

protocol bgp vultr
{
    local as 123456; # your ASN
    source address 203.0.113.123;
    import none;
    export all;
    multihop 2;
    neighbor 169.254.169.254 as 64515; # Vultr’s peering information
    password "my-secret-password"; # BGP password provided by Vultr
}

After restarting BIRD, your server will establish a peering session with Vultr’s AS. At this point, your server is capable of transmitting packets with the rest of the internet. Now you just need to tell the rest of the internet that you’re here! The final step is to announce your route. Append the following to the same bird.conf file:

protocol static
{
        route 123.4.567.890/24 via 203.0.113.123; # your IP via Vultr’s IP
}

protocol device
{
        scan time 5;
}

Restart BIRD again to load the new configuration. At this point, your BGP server is announcing the route to Vultr, who is in turn announcing the route to their peers (who then announce it to their peers). The process continues until your new route propagates across the internet. Your server can now serve traffic for your IP! Repeat these same steps with a second server in another region and you have your very own anycast network.

Conclusion

While this post provides the information needed to get your anycast network running, you may still need to adjust your settings to fine-tune the traffic patterns for your network. As mentioned previously, ASs usually choose the path with the fewest number of hops to a destination. Fewer hops does not necessarily mean it will be faster if, for example, one of those hops crosses the Atlantic Ocean. If you notice suboptimal performance, you may want to look into changing the traffic patterns with tools like communities and prepending.

Anycast networks are a powerful tool that leverages the networking infrastructure of the internet to create resilient and performant systems. I hope this post was insightful enough to add another tool to your toolbelt when building reliable systems.

We don't use Vultr or Equinix Metal anymore because of how our Anycast needs have evolved; we'll discuss our new setup in another blog post! ↩

Forem: Render

How Render Scaled Knative to Support 100k+ Free-Tier Apps

How we initially built Free

Where we hit a wall

"Serviceless" Knative

Step by step

A moving target

Related reading

Migration Guide: Heroku to Render

Requirements

Migration Steps

Concept Mapping

Step 1: Generate a Dockerfile.render and render.yaml

Install Render's Heroku CLI Plugin

Run CLI Plugin

Excluded Environment Variables

Add Dockerfile.render and render.yaml to Source Control

Step 2: Create Resources on Render

Step 3: Configure Environment Variables

Step 4: Copy Data from PostgreSQL

PostgreSQL

Step 5: Update DNS Configuration

...It Works Fine Locally

Writing Code

Deploying Code

A Deployment Checklist

Migrate a Django App from Heroku to Render (and get it ready for prod)

Why Saleor, Why Render?

Deploy Saleor on Render

Migrate a Django App from Heroku to Render

Create a Web Service

Add a Database

Add Redis

Add Build Steps

Add a Dashboard

Add a React Storefront

Productionalizing a Django App on Render

Add a Secret File

Add a Background Worker

Add a Cron Job

Update Build Script

Add Runtime Script

Add CloudAMQP

DRY It Up

Help! (a Helper File for Derived Variables)

Next Steps

Render, Remix, and Strapi: Let's Build a Productivity Tips App

What are Strapi and Remix?

Why Strapi and Remix Together?

A Productivity Tips App

Set Up Your Development Machine

Configure and Get Familiar with Strapi

Build the Front-End with Remix

Deploy Everything to Render

Customize

Render Redis

Why we're offering Redis

What Redis enables for Render users

Getting started

Remote Debugging with SSH and VS Code

Why SSH?

Debug Node.js Remotely

Configure Render

Configure VS Code

Create the SSH Tunnel

Start Debugging

More to Explore

Add Password Protection to Any Site with OAuth2 Proxy - Plus Social Logins

What is it good for?

What are the drawbacks?

What is it, and how does it work?

Traffic Flow

Implementation

More to Explore

Password Protect Static Sites with PageCrypt

What's it good for?

What are the drawbacks?

What is it, and how does it work?

Try it out

Extend

Step 1: Generate a `Dockerfile.render` and `render.yaml`

Add `Dockerfile.render` and `render.yaml` to Source Control

Creating a `Dockerfile` for GitPod OpenVSCode Server

Meet Blueprints and `render.yaml`