Here’s a sample YAML file 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 plan: standard # optional branch: master # optional (uses repo default) 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-cache.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: /opt/redis sizeGB: 10 # optional # A Ruby web service - type: web name: sinatra env: ruby repo: https://github.com/renderinc/sinatra-example.git 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 # 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 databases: - name: elephant databaseName: mydb # optional (Render may add a suffix) user: adrian # optional envVarGroups: - name: conc-settings envVars: - key: CONCURRENCY value: 2 - key: SECRET generateValue: true - name: stripe envVars: - key: STRIPE_API_URL value: https://api.stripe.com/v2
You can define services in your YAML file.
- Each service should have a
- Cron jobs must have a
- Each service should have a
startCommandunless it’s a Docker service in which case Render uses the command in your Dockerfile.
render.yaml can omit a repo. If a repo is missing, it is assumed to be the repo the YAML file 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
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 other Render resources like databases:
key: DB_URL fromDatabase: name: prod property: connectionString
The set of available properties is defined below.
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 YAML file 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 YAML file.
key: SOME_SECRET sync: false
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:
When depending on other services, you must include the
name of the target service. The
service does not need to be in the YAML file. If it’s not in the YAML file, 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
The service plan can be specified by name and is case insensitive. If it’s omitted, the plan will default to the “Starter” plan. The following values are valid for plans:
- Standard Plus
- Pro Plus
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
plan. The following two database specifications are both valid:
databases: # db 1 - name: staging # db 2 - name: prod plan: pro databaseName: prod_app user: app_user
You can define environment groups in your YAML file.
- Environment groups can have zero or more environment variables.
- 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