Here’s a sample Blueprint spec that uses most of the supported settings for infrastructure as code. Use it to get started with your own
services: # A Docker web service - type: web name: webdis env: docker repo: https://github.com/render-examples/webdis.git # optional region: oregon # optional (defaults to oregon) plan: standard # optional (defaults to starter) branch: master # optional (uses repo default) dockerCommand: ./webdis.sh # optional (defaults to Dockerfile command) numInstances: 3 # optional (defaults to 1) healthCheckPath: / envVars: - key: REDIS_HOST fromService: name: redis type: pserv property: host # available properties are listed below - key: REDIS_PORT fromService: name: redis type: pserv property: port - fromGroup: conc-settings # A private Redis instance - type: pserv name: redis env: docker repo: https://github.com/render-examples/redis.git # optional envVars: - key: GENERATED_SECRET generateValue: true # will generate a base64-encoded 256-bit secret - key: DASHBOARD_SECRET sync: false # placeholder for a value to be added in the dashboard disk: name: redis-data mountPath: /var/lib/redis sizeGB: 10 # optional # A Ruby web service - type: web name: sinatra env: ruby repo: https://github.com/renderinc/sinatra-example.git scaling: minInstances: 1 maxInstances: 3 targetMemoryPercent: 60 # optional if targetCPUPercent is set targetCPUPercent: 60 # optional if targetMemory is set buildCommand: bundle install startCommand: bundle exec ruby main.rb domains: - test0.render.com - test1.render.com envVars: - key: STRIPE_API_KEY value: Z2V0IG91dHRhIGhlcmUhCg - key: DB_URL fromDatabase: name: elephant property: connectionString - key: REDIS_SECRET fromService: type: pserv name: redis envVarKey: GENERATED_SECRET autoDeploy: false # optional # A Python cron job that runs every hour - type: cron name: date env: python schedule: "0 * * * *" buildCommand: "true" # ensure it's a string startCommand: date repo: https://github.com/render-examples/docker.git # optional # A background worker that consumes a queue - type: worker name: queue env: docker dockerfilePath: ./sub/Dockerfile # optional dockerContext: ./sub/src # optional branch: queue # optional # A static site - type: web name: my blog env: static buildCommand: yarn build staticPublishPath: ./build pullRequestPreviewsEnabled: true # optional headers: - path: /* name: X-Frame-Options value: sameorigin routes: - type: redirect source: /old destination: /new - type: rewrite source: /a/* destination: /a databases: - name: elephant databaseName: mydb # optional (Render may add a suffix) user: adrian # optional ipAllowList: # optional (defaults to allow all) - source: 203.0.113.4/30 description: office - source: 198.51.100.1 description: home - name: private database databaseName: private ipAllowList:  # only allow internal connections envVarGroups: - name: conc-settings envVars: - key: CONCURRENCY value: 2 - key: SECRET generateValue: true - key: USER_PROVIDED_SECRET sync: false - name: stripe envVars: - key: STRIPE_API_URL value: https://api.stripe.com/v2
You can define services in your Blueprint spec.
- Each service should have a
- Cron jobs must have a
- Each service should have a
startCommandunless it’s a Docker service. For Docker services, Render users the command in your
Dockerfile. This can be overridden by specifying
dockerCommandin your service definition.
render.yaml can omit a repo. If a repo is missing, it is assumed to be the repo the Blueprint spec is in. The specified repo must be accessible to you.
You can also omit a branch. Render will use the repo’s default branch if it’s omitted.
The service type must be one of the following:
webfor a web service
workerfor a background worker
pservfor a private service
cronfor a cron job
webservice with a
staticenvironment. The type of a service cannot be changed once it's created. Services created as static sites cannot be changed to other environments.
A service can be deployed in a specific region by adding an optional
region field. If specified, the region field must be one of following:
If not specified, the region defaults to
The service environment must be one of the following:
A service can specify zero or more environment variables. These variables can be plain variables as follows:
key: A value: B
They can depend on the properties of other Render resources like databases:
key: DB_URL fromDatabase: name: prod property: connectionString
The set of available properties is defined below.
You can pull copy environment variables from other services with a different key:
key: MYSQL_PASSWORD fromService: name: mysql type: pserv envVarKey: PASSWORD
The value of an environment variable can also be generated (only if the key doesn’t already exist).
key: APP_SECRET generateValue: true
There are some environment variables which you don’t want to include in your Blueprint spec and are not
generated such as external secrets. For those, you can specify a placeholder environment variable
sync: false. This allows you to declare that an environment variable is expected without
having to specify a value in your Blueprint spec. You will later be prompted to enter a value for these
variables on the dashboard before your deployment is finalized.
Variables defined with
sync: false will not be copied to preview environments. To share these variables across preview environments, add them to an environment group instead.
key: SOME_SECRET sync: false # will not be copied to preview environments
You can choose to provide a value for these variables before you approve your changes:
Environment variables can also be set all at once from an environment group:
Environment variables can refer to the following properties on databases:
databaseis the PostgreSQL database name (not the friendly name)
Environment variables can refer to the following properties on services:
hostportis the service’s host and port separated by a colon, as in
When depending on other services, you must include the
name of the target service. The
service does not need to be in the Blueprint spec. If it’s not in the Blueprint spec, it must already exist in your Render account.
Here’s an example of an environment variable referring to a service property:
fromService: name: redis type: pserv property: host
render.yamldoes not support variable interpolation. The best way to accomplish this is to pair environment variables with a build or start script that does the interpolation for you.
You can specify whether your service has a Disk attached to it. A disk must have a
mountPath, and (optionally) a size in GB (
disk: name: redis-data mountPath: /opt/redis sizeGB: 10
You can specify custom domains for your service in the
domains field. If a domain is an apex
www. subdomain will be added automatically and will redirect to the apex domain.
If a domain is a
www. subdomain, the apex domain will be added automatically and will redirect to the
Every web service is always accessible at its
You can specify HTTP headers for your static site with the
headers field like
you can in the dashboard.
headers: # add X-Frame-Options: sameorigin to all paths - path: /* name: X-Frame-Options value: sameorigin # add Cache-Control: must-revalidate to /blog paths - path: /blog/* name: Cache-Control value: must-revalidate
You can specify redirect and rewrite routes for your static site with
routes field just like in the dashboard.
routes: # redirect (HTTP status 301) from /a to /b - type: redirect source: /a destination: /b # rewrite /app/* requests to /app - type: rewrite source: /app/* destination: /app
The service plan can be specified by name and is case insensitive. The plan will default to “Starter” if unspecified on service creation. Render will maintain the service’s current plan for existing services where no plan is specified in the
render.yaml. The following values are valid for plans:
- Starter Plus
- Standard Plus
- Pro Plus
You can set a health check path for your HTTP service for zero downtime
deploys by adding the
You can set the number of instances you want for your service by setting the
Instead of setting a static number of instances for your service, you can autoscale your service based on target CPU and/or memory utilization.
scaling: minInstances: 1 maxInstances: 3 targetMemoryPercent: 60 # optional if targetCPUPercent is set (valid: 1-90) targetCPUPercent: 60 # optional if targetMemory is set (valid: 1-90)
- Services with disks cannot be scaled up yet.
- Payment info is required to turn on autoscaling.
- Services with autoscaling enabled prior to
render.yamlsupport will keep existing settings set in dashboard until this section is specified in their
render.yamlfile for their service.
- Services in preview environments will launch with
minInstancesnumber of instances. Autoscaling is disabled for services in preview environments.
If your service is Docker-based, i.e. it has
env: docker, then you can optionally specify the
dockerContext. These are relative to your repo root. This is useful for
mono-repo Docker services.
dockerfilePath: ./sub/Dockerfile dockerContext: ./sub/src
You can create databases by defining them in
render.yaml. A database only needs a
name — all other fields are optional.
You can also set the PostgreSQL
postgresMajorVersion. The following two database specifications are both valid:
databases: # db 1 - name: staging # db 2 - name: prod region: frankfurt plan: pro databaseName: prod_app user: app_user ipAllowList: # optional (defaults to allow all) - source: 203.0.113.4/30 description: office - source: 198.51.100.1 description: home # db 3 - name: private database databaseName: private ipAllowList:  # only allow internal connections postgresMajorVersion: 13 # optional (defaults to 13, supported versions are 11, 12, and 13)
You can specify which IP addresses can access your database from outside Render’s network using an
ipAllowList: - source: 203.0.113.4/30 description: office - source: 198.51.100.1 description: home
IP address ranges can be given with CIDR notation and the description is optional.
The IP allow list is optional. If it’s omitted, any source with the right credentials can access your database.
You can block all external access by providing an empty list.
ipAllowList:  # only allow internal connections
Learn more at Database Access Control.
You can define environment groups in your Blueprint spec.
- Environment groups can have zero or more environment variables.
- Environment groups can be used to propagate
sync: falseenvironment variables to preview environments.
- The environment variables in an environment group cannot depend on other resources, unlike the environment variables in a service. However, you can still generate environment variables within an environment group. The following is a valid environment group spec:
- name: conc-settings envVars: - key: CONCURRENCY value: 2 - key: SECRET generateValue: true - key: USER_PROVIDED_SECRET sync: false