Render.com - Parser Full Documentation

The parser for Render.com translates the docker-compose.yml file into Render BluePrint. The parser logic can be found in GitHub inside docker-to-iac repo.

Parser language abbreviation for API

• languageAbbreviation: RND.

Prerequisite to deploy Render BluePrint

There are no special requirements for using the Render.com blueprint. However, you need a valid render.com account with sufficient credits.

Architecture

The BluePrint will create a render "web" service.

Type = "Web Service".

Render dashboard will list all your web services. At the top, you can switch between Dashboard and BluePrints.

After the BluePrint has been created through one-click deployment, the BluePrint will be visible in the BluePrint menu.

In contrast to other cloud providers, Render.com's usability is very trivial. There is no VPC / VNet or anything else. After successful deployment, you can open your service via a URL.

Default output format

• The default output format for this parser: YAML.

File Configuration

The Render.com parser generates a single file output:

• render.yaml - The main Blueprint configuration file that defines all services, environment variables, and disk configurations

This straightforward single-file approach aligns with Render's Blueprint specification, which requires all service definitions to be contained within a single YAML file. The file is structured according to Render's requirements with services, environment variables, and disk configurations properly organized for immediate deployment.

Supported Docker Compose Variables

The current version supports the following Docker Compose variables:

For services:

• image
• environment
• ports
• command

Volume Support

Render.com offers two types of storage options:

Default: Ephemeral Filesystem

By default, Render services use an ephemeral filesystem where:

• Changes to the filesystem are lost after deployments or restarts
• Each service instance has its own separate filesystem
• No data persists between deployments

Persistent Disk Option

The parser supports adding persistent disk storage through the volumes directive:

• Persistent disks are automatically configured with 10GB size
• Only one disk per service is supported
• Files are preserved across deployments and restarts
• Only filesystem changes under the disk's mount path are preserved

Important limitations for persistent disks:

• A disk can only be accessed by a single service instance
• Services with persistent disks cannot scale to multiple instances

Read more here: render.com/docs/disks

Service Types

The parser automatically determines the appropriate service type for each container in your Docker configuration:

Web Services (Default)

By default, services are created as type: web, which is suitable for:

• HTTP-based applications
• Frontend applications
• API servers
• Any service that needs to be publicly accessible

Private Services

For databases and other TCP-based services, the parser automatically sets type: pserv. These services:

• Are not publicly accessible
• Can communicate with other services over TCP
• Are ideal for databases and backend services

Read more here: render.com/docs/private-services.

The service type is determined based on the Docker image being used. For example:

services:
  web:
    image: nginx:latest
    # Automatically set to type: web
    
  db:
    image: mariadb:11.2
    # Automatically set to type: pserv

Adding New Service Types

If you're using a service that should be private but isn't automatically detected, please visit our Render: Contributing to Render Service Types docs page.

Multi Services Support

Multi services support for Render.com: yes

Since multi services feature is supported.

Please read more about multi service support here.