How was blueprint designed to be used?

I have a CloudFormation background, so I was excited to dive into blueprint because any infra as code would allow me to reduce duplication, track changes, and overall save me a lot of time.

I spent the whole day fiddling with render.yaml, reading all the documentation, reading forums, testing different approaches, and I still haven’t found the “golden path”. All approaches that I had tried had unfavorable trade-offs. I am constantly fighting between 3 issues: version control, duplication, and explicitness.

I want to track every tiny detail in version control. Fields in the blueprint such as domains, region, plan, number of instances need parameterization to allow variance per environment, but it should not come at the cost of explicitness and version control. For example, I want to be able to parameterize environmental variables. HOST is a common environmental variable that differs between environments, and since it’s not a secret then we want to version control this. I can parameterize it per environment if I used sync: false, but it comes at the cost of explicitness and version control. Who changed it? when? to what? and why? Without version control of that env var, then I lose all that extra knowledge. Alternatively, if I hard code it into render.yaml then I will have to create a separate template for each environment which leads to duplication.

I am having a hard time finding the right balance of trade-offs. It would be really helpful to understand what are the best practices around blueprint.

1 Like

Hi Tansan,
That’s a great question and certainly something that I’ve posted internally because it definitely provides food for thought. As our customers’ needs have gotten more complex and customers want to rely on blueprints as a full representation of their services on Render then we need to spend time adapt to those needs.

There are definitely a few holes that need patching up to be able to use blueprints in the way you describe and definitely something we’re aware of because right now, it’s just not possible without tradeoffs. We have an internal effort already in place around this so you can expect some movement here in the future so you’re not having to choose between version control, duplication and explicitness.

John B

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.