Making Builds MoreFlexible and Performant

By Stephen Barlow

Render takes your infrastructure problems away by providing a powerful, battle-tested, cost-effective cloud with an outstanding developer experience. Stay focused on building great apps, shipping them fast, and delighting your customers, and leave your cloud infrastructure to us.

Today we’ve shipped two often-requested features for service builds:

  • Set a pre-deploy command to run tasks just before each deploy of your service. This is perfect for performing database migrations and asset uploads—especially for services that deploy a prebuilt Docker image.
  • For teams, enable the Performance build pipeline to run all of your build tasks with significantly more memory and CPU.

These additions help provide a more predictable, organized workflow for everything that happens on Render before your service is deployed.

Let’s take a closer look at each!

Pre-deploy command

Up until now, if your Render app ran new database migrations before every deploy, you probably shoehorned that migration step into your build command by running a miniature script. Here’s mine from one of my own apps:

npm install
db-migrate -e prod up

Admittedly, this could be more elegant—database migrations should run according to whether the database is up to date, not according to whether code needs to be built. And to complicate matters further, services that deploy a prebuilt image can’t customize their build command this way.

Enter the new pre-deploy command. As its name suggests, this command runs before each deploy of your service, regardless of whether Render executed a build for that deploy. This means it also runs for services that deploy a prebuilt Docker image.

Build command
Start command

You set your pre-deploy command from the Render Dashboard, alongside your build and start commands:

Setting a pre-deploy command in the Render Dashboard

Pre-deploy command logs are included in each deploy…

Viewing pre-deploy updates in deploy logs

…and if the command fails, the deploy is canceled.

Like the build command, your pre-deploy command uses pipeline minutes (formerly known as build minutes).

Give pre-deploy commands a try! You can set one for any paid web service, private service, or background worker.

Performance build pipeline

Some apps have heavy-duty builds that require a bit—or a lot—of extra horsepower. If your team’s builds are running up against memory or CPU limits, we now offer a Performance tier for our build pipeline, which you can enable from your Team Settings page:

Selecting a build pipeline tier

If you enable the Performance tier for your team, Render runs all of your team’s pipeline tasks—including builds and the new pre-deploy command—on compute instances with much higher memory and CPU.

Performance pipeline usage is billed in batches of 1,000 pipeline minutes, at a higher price than Starter to account for the increased compute usage. Pipeline minutes are not transferable between tiers, and only the Starter tier includes a free batch of minutes each month.

If your builds are hitting a resource bottleneck, enable the Performance build pipeline to throw a lot more compute at the problem. And if your builds are already running smoothly, awesome—stick with Starter and your free monthly batch of minutes.

Level up your builds

Done and done: two new features for more flexible, more performant builds. For more details on them and the rest of Render’s build pipeline, check out the docs:

Stephen Barlow

Stephen Barlow creates developer content at Render.

Subscribe to our newsletter for regular product updates.

Discover More

  1. A New Log Explorer and HTTP Logs

    Search and filter your application logs in our new explorer. Plus, teams now automatically log all HTTP requests for web services.

    - Stephen Barlow

  2. How Felt Ships 15+ Times a Day on Render

    Render preview environments support Felt's engineering culture of rapid iteration.

    - Can Duruk

  3. How Render Scaled Knative to 100k+ Web Apps

    As Render free-tier apps exploded in popularity, we needed to make the feature much more scalable. This work was our first step along that path.

    - Hieu Nguyen