Announcing Pulumi Provider For Render
The new Pulumi Render provider allows you to create services on Render.
The new Pulumi Render provider allows you to create services on Render.
What Is Render?
In Render's own words:
Render is a unified cloud to build and run all your apps and websites with free TLS certificates, global CDN, DDoS protection, private networks, and auto deploys from Git.
Render's offerings are perfect for teams that don't want to handle the mess of figuring out private networking, DDoS, CDN, TLS certificates (and automatically renewing them.) But now with this announcement you don't have to manually provision services in Render.
With this new Pulumi provider you can now create all of their supported service types. For example, here's a Pulumi app that creates a StaticSite
and a WebService
.
// Some details omitted for brevity.
const staticSite = new render.services.StaticSite("staticsite", {
name: "My custom static site",
ownerId,
repo: "https://github.com/cloudy-sky-software/test-static-site",
autoDeploy: "no",
branch: "main",
serviceDetails: staticSiteDetails,
});
// Some details omitted for brevity.
const webService = new render.services.WebService("webservice", {
name: "An Express.js web service",
ownerId,
repo: "https://github.com/render-examples/express-hello-world",
autoDeploy: "yes",
envVars: [
{
key: "PORT",
value: `${port}`,
},
],
branch: "master",
serviceDetails: webServiceDetails,
});
export const url = (
staticSite.serviceDetails as services.StaticSiteServiceDetailsArgs
).url;
export const webServiceUrl = (
webService.serviceDetails as services.WebServiceServiceDetailsArgs
).url;
Note that I said "service types" and not all "resources" that Render supports. This is because their API does not support creating every type of resource they support today, for example, creating a Postgres DB or a Redis instance.
SDKs for this provider are available for Go, Node.js, Python and .Net runtimes. Head over to the provider repository to see how you can get them and start using the provider today!
Why Render?
Render is just one of my favorite PaaS...es? Anyway, back in early 2022 when I left Pulumi start to Cloudy Sky Software, I needed to pick a service to host the website. There are many options to that. Seriously, many! I eventually settled on Render, specifically because they had just launched their public REST API and an idea had struck me. And I thought to myself, what if I could build a Pulumi provider that was based on their REST API.
There are examples of this sort of approach at a much larger scale that Pulumi handles today with the likes of AWS native provider and Azure native provider. They are "native" providers because they are not bridged with Terraform providers. They rely on the cloud providers' public APIs.
The other reasons include bringing Pulumi's platform to the teams that use services like Render. Now, they can not only use Render with Pulumi but also the 100+ provider packages available in Pulumi. Think of Render as a competitor to Heroku. The one complaint I hear from teams about Heroku is that they outgrow the platform. I think Render's offerings should scale well and you should be able to get pretty good mileage out of your infrastructure efforts. I am of the opinion you are never done evolving your infrastructure. Technologies like Pulumi are there to help you do just that. :)
Provider Maintenance
A significant effort goes into making a new provider regardless of whether it's a bridged-provider or a native one. Both types of providers are important to the Pulumi community. But when the API surface is relatively small, the technology used to generate providers like the Pulumi Render provider should help with cutting down the cost to create a provider.
As the API surface area grows for a provider, I imagine being able to auto-generate a provider will become extremely important and then manually handle some special cases which is most definitely going to be required. And for that reason, I've built the framework in a way that the framework gets out of the way when you have to do things yourself using simple pre/post callbacks. One example of such a case is triggering a deployment when certain (Render) service resources have been updated.
But as I mentioned before, certain large-scale providers like Azure have extremely large OpenAPI specs with a lot of customization. Despite it being based on an open standard, it's pretty time-consuming to develop a provider in such cases. It takes a whole team to build/maintain providers like that. For all other providers that have a pretty manageable surface area, I hope that pulschema
will help drastically reduce the development time and still yield high-quality providers because it stays as close as possible to the underlying cloud provider API.
Preview Status
Lastly, a few words about the status of this provider. It's not 1.0 just yet. You can read more about its status in the issue I created in the repo.
As a small example of real-world use of this provider, a pretty good chunk of my website's infrastructure is supported by this provider.
I am hoping that the Render team can make some updates to their API (if you are reading this, Render team 👋) this year.