Docker on Render
Docker is the preferred application delivery mechanism for an increasing number of applications. Render offers native support for running containerized apps and services at scale, offering features that were previously available only in complex orchestration tools like Kubernetes.
Render's Docker support includes:
- Deploying prebuilt images from a container registry
- Automated image builds and deploys from a Dockerfile in your Git repository
- Parallelized multi-stage builds
- Customizable Docker
CMD, context directory, and Dockerfile path - Full
.dockerignoresupport - Automatic translation of environment variables to Docker build args
- Maximal layer caching for faster builds
- Infrastructure as Code with
render.yaml
Docker services also support universal Render features like:
- Setting a pre-deploy command to run database migrations and other tasks before each deploy
- Private networking, load balancing, and service discovery (limited on free instance types)
- Persistent disk storage
- Automatic Brotli and gzip compression for faster responses
- Easy HTTP health checks and zero downtime deploys
- Automatic Pull Request Previews
- Native HTTP/2 support with automatic HTTP → HTTPS redirects
- Unlimited custom domains (25 free per service)
Docker vs. native runtimes
Render has native support for many popular languages, including Node.js, Python, Ruby, Go, Rust, and Elixir. You don't need to use Docker on Render if your service can be deployed with a native runtime and a build and start command.
You should consider containerizing your application in the following scenarios:
- You need OS-level packages that aren't included in a native runtime. With Docker you have complete control over your base operating system and installed packages.
- Your application is in a language not yet supported natively on Render, like PHP, Java, or ASP.NET.
- You need guaranteed reproducible builds. We release regular updates to native runtimes to improve functionality, security, and performance. While we aim for full backward compatibility, using a Dockerfile is the best way to ensure that your production runtime is always in sync with your local builds.
Docker builds on Render
Render uses the BuildKit engine to build your Dockerfiles.
Run your local builds with DOCKER_BUILDKIT=1 docker build to use BuildKit on your own machine.
If your Dockerfile requires private images, you can specify a registry credential for the service to access those images. For details, see Credentials for private images.
Render builds your Docker image on every push to your repo, storing the image in a private and secure container registry. After building the image, the system creates new containers based on the latest version of your app and starts directing traffic to them as soon as they are healthy. For more details, see Zero-downtime deploys.
Caching
Render caches all intermediate build layers in your Dockerfile, which significantly speeds up subsequent builds. Follow these instructions from Docker to further optimize your images and improve build times.
In addition, Render maintains a cache of public Docker Hub images. Because of this, pulling an image with a mutable tag (e.g., latest) might result in a build that uses a cached, less recent version of the image. To ensure that you don't use a cached Docker Hub image, do one of the following:
- Reference an immutable tag when you deploy (e.g., a specific version like
v1.2.3) - Add a credential to your image. For details, see Credentials for private images.
Getting started with Docker containers
You can build and deploy your own Dockerfile by adding it to your repo and creating a Render service as usual. Render automatically detects Dockerfiles at the root of your repo and suggests a Docker runtime for your app during service creation.
We also have templates to install popular open-source applications on Render using Docker: