Render Docker

RenderOfficialCreated by Render

Skill
Tool integration
Cloud and DevOps
MIT
Low risk

From the author

Builds and deploys Docker containers on Render—Dockerfiles, multi-stage builds, Blueprint Docker fields, private registries, layer caching, and platform constraints. Use when the user mentions Docker, Dockerfile, container images, multi-stage builds, container registry, GHCR, ECR, BuildKit, dockerContext, runtime docker or image, or optimizing Docker builds on Render.

— the description by Render

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides technical instructions for configuring Docker-based services on Render. It covers the use of BuildKit for image construction, the distinction between runtime: docker and runtime: image configurations, and best practices for multi-stage builds, registry authentication, and layer caching. It also includes language-specific Dockerfile templates and guidance on managing build arguments, secrets, and platform-specific constraints.

What it does

Explains how to configure Docker services using runtime: docker or runtime: image.
Provides multi-stage Dockerfile templates for Node.js, Python, Go, Ruby, and Rust.
Details how to authenticate with private container registries like GHCR and ECR.
Outlines the use of BuildKit for optimized image builds and layer caching.
Defines the mapping of Blueprint fields such as dockerfilePath and dockerContext.
Offers guidance on secure secret management using BuildKit secret mounts.

When to use it

When you need to define or debug a Dockerfile for a Render service.
When deciding between building from a repository or pulling a prebuilt image.
When configuring private registry credentials for base or prebuilt images.
When optimizing Docker build performance or hardening container security.
When troubleshooting deployment triggers or container runtime behavior.

Advantages

Provides standardized patterns for multi-stage builds to reduce image size.
Clarifies the separation between build-time arguments and runtime secrets.
Includes specific configuration steps for common container registries.
Offers clear guidance on platform-specific requirements like port binding and health checks.

Usage examples

“How do I configure a Node.js service to build from a Dockerfile on Render?”: The agent provides a Blueprint configuration example using runtime: docker and a multi-stage Dockerfile template optimized for Node.js.
“How can I use a private image from ECR in my Render service?”: The agent explains how to store registry credentials in the Render Dashboard and reference them via image.creds in your Blueprint.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/render-oss/render-docker/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip render-docker.zip -d .agents/skills

Documentation by Render

Render Docker Deployments

Render uses BuildKit for Docker builds. All compute service types that support custom runtimes can use runtime: docker (build from a Dockerfile in the repo) or runtime: image (pull a prebuilt image; no Dockerfile build on Render). Deeper patterns and copy-paste templates live under references/.

When to Use

Authoring or debugging a Dockerfile for a Render service
Choosing runtime: docker vs runtime: image in a Blueprint
Wiring private base images or prebuilt images with registry credentials
Multi-stage builds, build args, secrets, and layer caching
Performance and security hardening of container images on Render

For full Blueprint authoring, see render-blueprints. For end-to-end deploy flows, see render-deploy.

Before deploying a built or prebuilt image, read references/deployments.md for current trigger, lifecycle, health-check, and signal behavior.

Render Docker Builds

BuildKit is used for Docker builds on Render.
runtime: docker: Render builds an image from your repo using dockerfilePath, dockerContext, and optional dockerCommand (overrides image CMD).
runtime: image: Render pulls image.url; no repo-based image build. Set image.creds.fromRegistryCreds.name when the registry is private.

Blueprint Configuration

Field	Role
`dockerfilePath`	Path to the Dockerfile (default `./Dockerfile`)
`dockerContext`	Build context directory (what is sent to the daemon)
`dockerCommand`	Overrides the container `CMD` after the image is built
`image.url`	Image reference for `runtime: image` (registry/repo:tag or digest)
`image.creds`	Dashboard-stored credential reference for a private prebuilt image
`registryCredential`	Dashboard-stored credential reference for private base images used by `runtime: docker`

Example sketch (values illustrative):

services:
  - type: web
    name: api
    runtime: docker
    region: oregon
    plan: starter
    dockerfilePath: ./Dockerfile
    dockerContext: .
    dockerCommand: node server.js
    envVars:
      - key: PORT
        value: 10000

For runtime: image, set image.url and, if needed, image.creds per Registry Configuration below.

Multi-Stage Builds

Recommended for production. Use a builder stage for compilation and dependency installation, and a minimal runner stage that only copies artifacts and runtime files. Benefits:

Smaller images and faster pulls
Fewer tools and secrets in the final image (smaller attack surface)
Clear separation between build-time and run-time dependencies

See references/dockerfile-patterns.md for language-specific templates.

Build Args vs Secrets

Critical: Never pass secrets via ARG. Build arguments are stored in image layers and can be recovered from the image history or intermediate layers.

Prefer runtime environment variables (Render env vars / secret files) for application secrets.
For build-time secrets (e.g. private package feeds), use Docker BuildKit secret mounts (RUN --mount=type=secret,...) rather than ARG.

Treat anything sensitive as runtime or BuildKit secret mount, not as a build arg.

Registry Configuration

Private base images (for runtime: docker) or prebuilt images (runtime: image) need authentication:

Store credentials in the Render Dashboard under Registry Credentials.
For runtime: docker, reference private base-image credentials with registryCredential.fromRegistryCreds.name.
For runtime: image, reference private prebuilt-image credentials with image.creds.fromRegistryCreds.name.

Supports common registries (Docker Hub, GHCR, ECR, Google Artifact Registry, and others). Step-by-step per provider: references/registry-setup.md.

Prebuilt-image services do not automatically deploy when a mutable registry tag moves. After publishing a new image, trigger a manual deploy through the Dashboard or a supported API or deploy-hook flow. Prefer immutable tags or digests so each deploy identifies an explicit artifact; follow references/deployments.md for the complete trigger and verification workflow.

Layer Caching

Render caches Docker layers between builds; order Dockerfile instructions so that frequently unchanged layers stay early (see references/optimization-guide.md).
Tags and caching: mutable tags like latest can resolve to stale cached images. Prefer immutable references: digest (repo/image@sha256:...) or version pins (v1.2.3).

Platform Specifics

Render builds linux/amd64. Avoid assumptions about other architectures in production images.
Port binding matches native services: bind HTTP to 0.0.0.0:$PORT (Render sets PORT).
Health checks use the same platform behavior described in references/deployments.md.
Secret files from Render appear under /etc/secrets/ — do not rely on repo-root secret paths inside the container unless you copy or mount them explicitly in the image.

`.dockerignore` and Start Commands

Always maintain a .dockerignore that excludes node_modules, .git, .env, build artifacts, logs, and OS junk. This shrinks context upload time and avoids leaking local files into layers. Lists and rationale: references/optimization-guide.md.
Custom start command: if you need multiple shell steps, use a single shell form, e.g. /bin/sh -c 'set -e; ./migrate && exec node server.js' (prefer exec so your app receives signals for graceful shutdown).

References

Document	Contents
`references/dockerfile-patterns.md`	Multi-stage templates (Node, Python, Go, Ruby, Rust, static sites)
`references/registry-setup.md`	Docker Hub, GHCR, ECR, Artifact Registry + Blueprint wiring
`references/optimization-guide.md`	Layer order, `.dockerignore`, BuildKit cache mounts, debugging
`references/deployments.md`	Deploy triggers, lifecycle, health checks, shutdown, and verification

render-deploy — Deploy flows, Blueprint vs Dashboard, operational steps
render-blueprints — Full render.yaml schema, wiring, and validation
render-web-services — Web service behavior, health checks, and HTTP edge cases

Current documentation retrieval

Whenever this skill directs you to consult current Render documentation:

Retrieve the linked Markdown document directly with an available URL-fetching tool or HTTP client, such as curl. Do not substitute web-search summaries for the document.
Confirm that retrieval succeeded and returned the expected document, then read its contents. Saving a file or printing its path is not sufficient.
If the request fails or your tool cannot read the Markdown response, open and read the linked HTML version instead.
If neither version can be retrieved, disclose that the current reference is unavailable and follow any topic-specific fallback in the skill. Use bundled guidance only for stable constraints, and do not guess at changeable platform details.

When a task requires multiple references, apply this workflow to each one and distinguish the documents you verified from those that remain unavailable.

Files

ATTRIBUTION.mdAdded by AutoGineer881 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md7.9 KiB
references/deployments.md7.9 KiB
references/dockerfile-patterns.md5.4 KiB
references/optimization-guide.md3.2 KiB
references/registry-setup.md3.0 KiB

references/deployments.md

Deployments and health checks

A Render deploy is asynchronous. A successful trigger means only that Render accepted or queued the deploy; it does not mean the new version is live. Before triggering a deploy, confirm the workspace, service, intended source commit or image, and current live deploy. Capture the new deploy ID, monitor it to a terminal state, and do not report success until its status is live and the deployed workload has been verified.

Before configuring or troubleshooting deployments and health checks, fetch the current Render references:

deploys.md (HTML: https://render.com/docs/deploys)
health-checks.md (HTML: https://render.com/docs/health-checks)

Using the documentation-retrieval workflow in the root SKILL.md, retrieve and read both references.

Read the relevant sections of both documents. Confirm current service-type support, command timeouts, health-check thresholds, rollout behavior, and configuration syntax rather than relying on remembered values.

Automatic deployment behavior depends on the service's source and settings. A service linked to a branch through a connected Git provider can deploy on each commit, wait for supported CI checks, or require manual triggers. Services that pull a prebuilt image and services linked by a public Git repository URL require manual deploys; moving a mutable image tag does not itself trigger one. When manually deploying a historical commit, verify whether that trigger method changes automatic-deploy settings. If automatic deploys remain enabled, a later branch update can replace the selected commit.

The normal lifecycle is build command, optional pre-deploy command, then start command and readiness checks. If a command fails or times out, the deploy fails and later steps do not run. A pre-deploy command runs after the build on a separate instance before the new version is deployed. Neither the build nor pre-deploy instance can access an attached persistent disk, and pre-deploy filesystem changes do not carry into the running service. Use pre-deploy for release tasks such as database migrations, not for producing runtime artifacts. Pre-deploy commands are supported for paid web services, private services, and background workers.

Render normally deploys services without downtime by starting the new version before retiring the current one. Web and private services continue routing traffic to the current instances until the new instances are ready. Multi-instance services roll out one instance at a time; if a replacement does not become healthy, Render cancels the rollout and retains or restores the previous version. Attaching a persistent disk disables zero-downtime deploys, so plan explicitly for an interruption.

A workflow deployment has a different completion model. It builds and caches the image used by future task runs and includes a task-registration step, but it does not execute those tasks. After a workflow deploy succeeds, verify that the expected task definitions are registered. Trigger and monitor a task run separately only when execution is intended. For workflow-specific deployment behavior, fetch the current workflow overview:

Using the documentation-retrieval workflow in the root SKILL.md, retrieve and read the Markdown reference or its HTML version.

Health checks apply to web services and private services. Both use TCP socket checks by default. Only web services support a configured HTTP health-check path. Render sends an HTTP GET; any 2xx or 3xx response received within five seconds succeeds, while other status codes, timeouts, and connection failures fail. Private services support TCP checks only.

For a new deploy, all new instances must pass their checks at the same time within the current readiness window, documented as 15 minutes, before Render routes traffic to them. For a running service, consecutive failures currently remove an instance from routing after 15 seconds and restart it after 60 seconds. Treat these thresholds as platform behavior, not user-tunable health-check interval settings, and verify them in the fetched reference before relying on exact timing.

Design an HTTP health endpoint to represent readiness for production traffic. Keep it fast and side-effect free. Check critical dependencies only when losing that dependency should make the entire instance unavailable; otherwise a transient dependency failure can unnecessarily remove healthy application capacity. Verify the configured path, response status, response time, listening port, and 0.0.0.0 binding when checks fail.

After traffic moves, Render gives the previous instance a drain period, then sends SIGTERM. The application should stop accepting new work, finish or safely abandon in-flight work, close connections, and exit within its shutdown delay. Ensure the actual application process receives the signal: container entrypoints and shell wrappers should use exec or explicitly forward signals. Render sends SIGKILL if the process remains running after the delay. The documented default shutdown delay is 30 seconds and the usual maximum is 300 seconds, but support varies by service configuration; confirm the current reference and Blueprint or API validation before setting maxShutdownDelaySeconds.

A service restart is a special deploy of the same commit and user-defined environment-variable values as the current running instance. It does not incorporate configuration changes saved after that deploy. Use a standard deploy when pending configuration must take effect.

Only one deploy runs at a time for a service. A workspace's overlapping-deploy policy determines whether a new trigger waits or cancels the in-progress deploy. Do not assume the policy or wait for every intermediate revision: inspect the workspace setting and identify the deploy that actually became live.

Treat rollback as a new deploy based on a retained previous build artifact, not as restoration of the entire service to an earlier point in time. It does not reverse database migrations, messages, external writes, or other side effects from the release, so confirm that the previous application version remains compatible with current external state. Disks and their data are not rolled back, some settings continue using current configuration, mutable image tags can resolve to a different image, and eligible artifacts are retained only for a limited period. Before rolling back, fetch the current rollback reference:

Using the documentation-retrieval workflow in the root SKILL.md, retrieve and read the Markdown reference or its HTML version.

Read which configuration comes from the target deploy and which remains current. After the rollback is created, inspect the service's resulting automatic-deploy setting instead of assuming whether it remains enabled, and deliberately restore the intended setting after the underlying issue is resolved.

Deploy hooks are secret credentials that authorize deploys. Never print, commit, or expose their full URLs. Before using one, fetch the current deploy-hook reference:

Using the documentation-retrieval workflow in the root SKILL.md, retrieve and read the Markdown reference or its HTML version.

Distinguish an immediately started deploy from a queued one, and continue monitoring the resulting deploy rather than treating the HTTP response as completion.

After a deploy becomes live, verify the behavior appropriate to the service type: make a request to a web or private service, confirm a worker is processing work, confirm a cron job or workflow invocation completes, and inspect recent runtime logs for new errors. If a deploy fails, diagnose the first failed lifecycle stage before retrying.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

The author says: Any Render compute service (web, private, worker, cron) with runtime: docker or runtime: image.

Security

What our scanner noticed· Low risk

Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

Render

Publisher

Render (Official)

Source

render-oss/skills · skills/render-docker · commit b985a63

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

AutoGineer is not affiliated with or endorsed by Render.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download render-docker.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by Render

Render Docker Deployments

When to Use

Render Docker Builds

Blueprint Configuration

Multi-Stage Builds

Build Args vs Secrets

Registry Configuration

Layer Caching

Platform Specifics

.dockerignore and Start Commands

References

Related Skills

Current documentation retrieval

Files

references/deployments.md

Deployments and health checks

Requirements and compatibility

Security

Attribution and licence

Related skills

Shipping And Launch

Quantized Export

Deployment Pipeline Design

Gitops Workflow

Spark Environment Setup

Cloud Infrastructure Deployment Engineer

Download ZIP

`.dockerignore` and Start Commands