{"id":164930,"date":"2026-03-28T21:46:36","date_gmt":"2026-03-28T18:46:36","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=164930"},"modified":"2026-03-28T21:46:37","modified_gmt":"2026-03-28T18:46:37","slug":"claude-code-docker-guide","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/claude-code-docker-guide\/","title":{"rendered":"Build and Debug Docker Containers with Claude Code"},"content":{"rendered":"\n<p>Dockerfiles and Compose stacks are where Claude Code earns its keep. The files are structured, the patterns are predictable, and validation is instant: either it builds or it doesn&#8217;t. You describe what you want, Claude Code writes the Dockerfile, builds the image, and shows you the result. When a container won&#8217;t start, you paste the error and Claude Code traces it to the root cause.<\/p>\n\n\n\n<p>This guide is part of the <a href=\"https:\/\/computingforgeeks.com\/claude-code-devops-engineers\/\" target=\"_blank\" rel=\"noreferrer noopener\">Claude Code for DevOps Engineers<\/a> series. Every demo below ran on a real Docker 29.1.2 installation. The builds, the image sizes, the error messages, the container logs are all captured from actual execution. For the full command reference, see the <a href=\"https:\/\/computingforgeeks.com\/claude-code-cheat-sheet\/\" target=\"_blank\" rel=\"noreferrer noopener\">Claude Code cheat sheet<\/a>.<\/p>\n\n\n\n<p><em>Tested <strong>March 2026<\/strong> | Docker 29.1.2, Compose 2.40.3, Python 3.12-alpine, PostgreSQL 17.9, Redis 7, Nginx alpine<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What You Need<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/code.claude.com\/docs\/en\/overview\" target=\"_blank\" rel=\"noreferrer noopener\">Claude Code<\/a> installed and authenticated<\/li>\n\n<li>Docker Engine 24+ with Compose V2 (<a href=\"https:\/\/computingforgeeks.com\/install-docker-rocky-almalinux\/\" target=\"_blank\" rel=\"noreferrer noopener\">Docker on Rocky Linux 10<\/a> or <a href=\"https:\/\/computingforgeeks.com\/install-docker-compose-ubuntu-debian\/\" target=\"_blank\" rel=\"noreferrer noopener\">Docker on Ubuntu 24.04<\/a>)<\/li>\n\n<li>Docker must be accessible without sudo (add your user to the <code>docker<\/code> group)<\/li>\n\n<li>Note: Docker requires disabling Claude Code&#8217;s sandbox mode or adding Docker socket exclusions<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Generate a Production Dockerfile<\/h2>\n\n\n\n<p>Most engineers write Dockerfiles that work. Fewer write ones that are small, secure, and cache-friendly. Claude Code generates the optimized version by default.<\/p>\n\n\n\n<p>Start with a simple Flask app. Create <code>app\/app.py<\/code> with a JSON health endpoint and <code>app\/requirements.txt<\/code> with flask and gunicorn. Then tell Claude Code:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Create two Dockerfiles for the Flask app in .\/app\/:\n1. A naive single-stage build using python:3.12-slim\n2. A production multi-stage build using alpine, non-root user, proper\n   layer caching. Build both and compare sizes.<\/code><\/pre>\n\n\n\n<p>Claude Code generates the naive version first:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>FROM python:3.12-slim\nWORKDIR \/app\nCOPY app\/ .\nRUN pip install -r requirements.txt\nEXPOSE 5000\nCMD [\"python\", \"app.py\"]<\/code><\/pre>\n\n\n\n<p>Then the production multi-stage version:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Build stage\nFROM python:3.12-alpine AS builder\nWORKDIR \/build\nCOPY app\/requirements.txt .\nRUN pip install --no-cache-dir --prefix=\/install -r requirements.txt\n\n# Runtime stage\nFROM python:3.12-alpine\nRUN adduser -D appuser\nWORKDIR \/app\nCOPY --from=builder \/install \/usr\/local\nCOPY app\/ .\nUSER appuser\nEXPOSE 5000\nCMD [\"gunicorn\", \"-b\", \"0.0.0.0:5000\", \"-w\", \"2\", \"app:app\"]<\/code><\/pre>\n\n\n\n<p>It builds both and shows the size comparison:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>TAG         SIZE\noptimized   88.2MB\nnaive       227MB<\/code><\/pre>\n\n\n\n<p>The multi-stage build is 61% smaller. But size isn&#8217;t the only win. Claude Code also verifies the security posture:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Naive runs as:     root\nOptimized runs as: appuser<\/code><\/pre>\n\n\n\n<p>The naive image runs as root, which means a container escape gives the attacker root on the host. The optimized image runs as <code>appuser<\/code>, a non-privileged account. Claude Code adds this by default because it knows Docker security best practices.<\/p>\n\n\n\n<p>A quick test confirms the optimized container works:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker run -d --name demo-test -p 5050:5000 demo-api:optimized<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>curl -s http:\/\/localhost:5050\/\n{\"host\":\"5011a306c6c6\",\"python\":\"3.12.13\",\"service\":\"demo-api\",\"status\":\"running\"}\n\ncurl -s http:\/\/localhost:5050\/health\n{\"status\":\"healthy\"}<\/code><\/pre>\n\n\n\n<p>The container responds on port 5050 with the correct Python version and hostname.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Docker Compose Full Stack<\/h2>\n\n\n\n<p>Single containers are simple. The real test is generating a multi-service stack with proper networking, health checks, and persistence. This demo builds a complete backend: Flask app, PostgreSQL database, Redis cache, and Nginx reverse proxy.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Generate a docker-compose.yml with:\n- Flask app connecting to PostgreSQL and Redis\n- PostgreSQL 17 with a persistent volume and health check\n- Redis for caching\n- Nginx reverse proxy on port 8080\n- Proper networking (all services on a backend network)\n- Health checks and depends_on conditions\nBuild and bring it up.<\/code><\/pre>\n\n\n\n<p>Claude Code generates the Compose file with all four services, a named volume for PostgreSQL persistence, and a dedicated bridge network. The key details it handles automatically:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Health check on PostgreSQL<\/strong> using <code>pg_isready<\/code> with the correct user and database<\/li>\n\n<li><strong>depends_on with conditions<\/strong> so the app waits for PostgreSQL to be healthy before starting<\/li>\n\n<li><strong>Nginx config<\/strong> with proper proxy headers (<code>X-Real-IP<\/code>, <code>X-Forwarded-For<\/code>, <code>X-Forwarded-Proto<\/code>)<\/li>\n\n<li><strong>Named volume<\/strong> for PostgreSQL data (survives <code>docker compose down<\/code>)<\/li>\n<\/ul>\n\n\n\n<p>Bringing up the stack:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose up -d<\/code><\/pre>\n\n\n\n<p>All four containers start and the health check passes:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NAME                    IMAGE                STATUS                    PORTS\ncompose-stack-app-1     compose-stack-app    Up 14 seconds             5000\/tcp\ncompose-stack-db-1      postgres:17-alpine   Up 20 seconds (healthy)   5432\/tcp\ncompose-stack-nginx-1   nginx:alpine         Up 14 seconds             0.0.0.0:8080->80\/tcp\ncompose-stack-redis-1   redis:7-alpine       Up 20 seconds             6379\/tcp<\/code><\/pre>\n\n\n\n<p>Testing the endpoint through the Nginx proxy confirms all services are connected:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>curl -s http:\/\/localhost:8080\/ | python3 -m json.tool<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>{\n    \"cache\": \"connected (hits: 1)\",\n    \"database\": \"PostgreSQL 17.9 on aarch64-unknown-linux-musl\",\n    \"host\": \"21743ef0d2ee\",\n    \"service\": \"compose-demo\"\n}<\/code><\/pre>\n\n\n\n<p>PostgreSQL 17.9 is connected and responding. Redis is tracking hit counts (incrementing on every request). The entire stack took one prompt to generate and one command to launch. Hitting the endpoint again shows the Redis counter increment to 2, confirming cache persistence across requests.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Debug a Container That Won&#8217;t Start<\/h2>\n\n\n\n<p>Containers fail silently. They exit, you see &#8220;Exited (1)&#8221; in <code>docker ps -a<\/code>, and the only clue is in the logs. Claude Code reads those logs and traces the problem faster than you can type <code>docker logs<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario 1: Wrong entrypoint file<\/h3>\n\n\n\n<p>A Dockerfile references <code>server.py<\/code> but the actual file is <code>app.py<\/code>. The container exits immediately.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>My container demo-api:broken exits immediately. Figure out why.<\/code><\/pre>\n\n\n\n<p>Claude Code checks the container status and reads the logs:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker ps -a --filter name=broken-cmd<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>NAMES        STATUS\nbroken-cmd   Exited (2) 16 seconds ago<\/code><\/pre>\n\n\n\n<p>Exit code 2 means the command failed. The logs reveal exactly why:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker logs broken-cmd<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>python: can't open file '\/app\/server.py': [Errno 2] No such file or directory<\/code><\/pre>\n\n\n\n<p>The Dockerfile <code>CMD<\/code> references <code>server.py<\/code> but the actual file is <code>app.py<\/code>. Claude Code inspects the Dockerfile, finds the mismatch, and fixes the <code>CMD<\/code> line. One rebuild and the container runs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario 2: Port already in use<\/h3>\n\n\n\n<p>You try to start a container on port 8080 but something else is already listening there.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker run -d --name port-conflict -p 8080:5000 demo-api:optimized<\/code><\/pre>\n\n\n\n<p>Docker returns the bind error:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Error response from daemon: failed to set up container networking:\ndriver failed programming external connectivity on endpoint port-conflict:\nBind for 0.0.0.0:8080 failed: port is already allocated<\/code><\/pre>\n\n\n\n<p>Tell Claude Code &#8220;the container won&#8217;t start, port conflict on 8080&#8221; and it finds the offender:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker ps --filter \"publish=8080\" --format \"table {{.Names}}\\t{{.Ports}}\"<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>NAMES                   PORTS\ncompose-stack-nginx-1   0.0.0.0:8080->80\/tcp<\/code><\/pre>\n\n\n\n<p>The Nginx container from the Compose stack is using port 8080. Claude Code removes the failed container and relaunches on a free port:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker rm port-conflict\ndocker run -d --name port-fixed -p 5051:5000 demo-api:optimized<\/code><\/pre>\n\n\n\n<p>Verified working:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NAMES        STATUS         PORTS\nport-fixed   Up 2 seconds   0.0.0.0:5051->5000\/tcp<\/code><\/pre>\n\n\n\n<p>These are the two most common container startup failures. The first (wrong file\/command) accounts for most &#8220;Exited (2)&#8221; cases. The second (port conflict) accounts for most &#8220;failed to set up networking&#8221; errors. Claude Code diagnoses both in under 10 seconds.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Optimize an Existing Dockerfile<\/h2>\n\n\n\n<p>When you inherit a Dockerfile that works but produces a bloated image, Claude Code can analyze the layers and suggest improvements. Ask it to compare:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Analyze the layers of demo-api:naive and demo-api:optimized.\nShow me where the size difference comes from.<\/code><\/pre>\n\n\n\n<p>Claude Code runs <code>docker history<\/code> on both images and compares:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>=== Naive image (227MB) ===\nSIZE      CREATED BY\n18.6MB    RUN pip install -r requirements.txt\n16.4kB    COPY app\/\n44.6MB    RUN set -eux; savedAptMark=\"$(apt-mark...)\"   \u2190 Debian build tools\n163MB     Base: python:3.12-slim (Debian)\n\n=== Optimized image (88.2MB) ===\nSIZE      CREATED BY\n7.12MB    COPY \/install \/usr\/local                       \u2190 only runtime deps\n16.4kB    COPY app\/\n41kB      RUN adduser -D appuser\n81MB      Base: python:3.12-alpine (musl libc)<\/code><\/pre>\n\n\n\n<p>The size difference comes from three sources:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Base image<\/strong>: <code>python:3.12-slim<\/code> (Debian) is 163MB. <code>python:3.12-alpine<\/code> is 81MB. Alpine uses musl libc instead of glibc, cutting the base in half<\/li>\n\n<li><strong>Build tools<\/strong>: the naive image keeps pip&#8217;s cache and any build dependencies in the final image. Multi-stage copies only the installed packages (7.12MB vs 18.6MB)<\/li>\n\n<li><strong>Layer efficiency<\/strong>: the build stage is discarded entirely. Only runtime files make it to the final image<\/li>\n<\/ul>\n\n\n\n<p>Claude Code suggests these optimizations automatically when you ask it to review a Dockerfile. It catches: missing <code>--no-cache-dir<\/code> on pip, running as root, missing <code>.dockerignore<\/code>, unnecessary packages in the runtime image, and layers that could be combined.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Dockerfile Optimization Checklist<\/h2>\n\n\n\n<p>After running dozens of Dockerfile generation sessions, these are the patterns Claude Code applies consistently:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Pattern<\/th><th>Why It Matters<\/th><th>Impact<\/th><\/tr><\/thead><tbody><tr><td>Multi-stage builds<\/td><td>Build tools don&#8217;t ship to production<\/td><td>30-70% size reduction<\/td><\/tr><tr><td>Alpine or distroless base<\/td><td>Minimal attack surface, smaller image<\/td><td>50-80% base size reduction<\/td><\/tr><tr><td>Non-root USER<\/td><td>Limits blast radius of container escape<\/td><td>Security<\/td><\/tr><tr><td><code>--no-cache-dir<\/code> on pip<\/td><td>Pip cache wastes space in the layer<\/td><td>5-20MB savings<\/td><\/tr><tr><td>COPY requirements first<\/td><td>Layer caching: deps rebuild only when requirements change<\/td><td>Faster rebuilds<\/td><\/tr><tr><td><code>.dockerignore<\/code><\/td><td>Prevents .git, __pycache__, .env from entering context<\/td><td>Faster builds, no secrets leaked<\/td><\/tr><tr><td>Specific image tags<\/td><td><code>:latest<\/code> breaks reproducibility<\/td><td>Reliability<\/td><\/tr><tr><td>Health checks in Compose<\/td><td>Ensures depends_on waits for readiness<\/td><td>No race conditions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Practical Docker Prompts That Work<\/h2>\n\n\n\n<p>After testing Claude Code on dozens of Docker tasks, these prompt patterns produce the best results.<\/p>\n\n\n\n<p><strong>Always specify the language runtime and base image preference.<\/strong> &#8220;Create a Dockerfile for my Go app using Alpine&#8221; produces better output than &#8220;Dockerize this app.&#8221; Claude Code picks a sensible default, but your choice of base image matters for compatibility and size.<\/p>\n\n\n\n<p><strong>Ask for the .dockerignore alongside the Dockerfile.<\/strong> Claude Code sometimes forgets to create one. A missing <code>.dockerignore<\/code> means <code>.git\/<\/code>, <code>__pycache__\/<\/code>, <code>.env<\/code>, and node_modules all get copied into the build context, which slows builds and can leak secrets into layers.<\/p>\n\n\n\n<p><strong>Request health checks explicitly in Compose files.<\/strong> Claude Code adds them for databases (PostgreSQL, MySQL) but sometimes skips them for application containers. A health check on your app container catches startup crashes before traffic arrives.<\/p>\n\n\n\n<p><strong>For debugging, paste the full error.<\/strong> &#8220;My container won&#8217;t start&#8221; gives Claude Code nothing to work with. &#8220;My container exits with code 137&#8221; tells it immediately that the container was OOM-killed. Exit code 1 means the app threw an error. Exit code 2 means the command or file wasn&#8217;t found. Exit code 127 means a binary is missing. The more specific the error, the faster the diagnosis.<\/p>\n\n\n\n<p><strong>Use Claude Code to review inherited Dockerfiles.<\/strong> Paste an existing Dockerfile and ask &#8220;Review this for security issues, size optimization, and caching.&#8221; Claude Code catches things like running as root, installing dev dependencies in production, missing <code>HEALTHCHECK<\/code> instructions, and unnecessary layers.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">When Claude Code Gets Docker Wrong<\/h2>\n\n\n\n<p>Two areas where you&#8217;ll need to override Claude Code&#8217;s defaults:<\/p>\n\n\n\n<p><strong>Alpine compatibility.<\/strong> Alpine uses musl libc. Some Python packages with C extensions (numpy, pandas, scikit-learn) fail to install on Alpine or require extra build dependencies. If your app uses data science libraries, use <code>python:3.12-slim<\/code> instead and accept the size tradeoff. Claude Code sometimes suggests Alpine without checking dependency compatibility.<\/p>\n\n\n\n<p><strong>Compose networking assumptions.<\/strong> Claude Code creates a single flat network by default. For production stacks, you want frontend and backend networks separated so the database is never directly reachable from the reverse proxy. If security matters (it always does), explicitly request network segmentation in your prompt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Part of the Claude Code for DevOps Series<\/h2>\n\n\n\n<p>This Docker guide connects to the broader series. The <a href=\"https:\/\/computingforgeeks.com\/claude-code-ssh-server-management\/\" target=\"_blank\" rel=\"noreferrer noopener\">SSH server management<\/a> guide covers running Docker commands on remote servers via SSH. The <a href=\"https:\/\/computingforgeeks.com\/claude-code-kubernetes-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\">Kubernetes guide<\/a> covers converting Compose stacks to Kubernetes manifests.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-devops-engineers\/\" target=\"_blank\" rel=\"noreferrer noopener\">Set Up Claude Code for DevOps Engineers<\/a> (pillar with safety rules and permissions)<\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-ssh-server-management\/\" target=\"_blank\" rel=\"noreferrer noopener\">Manage Servers with Claude Code via SSH<\/a><\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-terraform-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>Claude Code + Terraform<\/strong><\/a>: generate modules, deploy infrastructure, import resources<\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-ansible-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>Claude Code + Ansible<\/strong><\/a>: generate playbooks, multi-OS testing, debug SELinux<\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-kubernetes-guide\/\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>Claude Code + Kubernetes<\/strong><\/a>: manifests, Helm charts, debugging CrashLoopBackOff<\/li>\n\n<li><a href=\"https:\/\/computingforgeeks.com\/claude-code-github-actions-infrastructure\/\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>Claude Code + GitHub Actions<\/strong><\/a>: automated PR review, Terraform validation<\/li>\n<\/ul>\n\n","protected":false},"excerpt":{"rendered":"<p>Dockerfiles and Compose stacks are where Claude Code earns its keep. The files are structured, the patterns are predictable, and validation is instant: either it builds or it doesn&#8217;t. You describe what you want, Claude Code writes the Dockerfile, builds the image, and shows you the result. When a container won&#8217;t start, you paste the &#8230; <a title=\"Build and Debug Docker Containers with Claude Code\" class=\"read-more\" href=\"https:\/\/computingforgeeks.com\/claude-code-docker-guide\/\" aria-label=\"Read more about Build and Debug Docker Containers with Claude Code\">Read more<\/a><\/p>\n","protected":false},"author":3,"featured_media":164931,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[39034,690,27,299],"tags":[],"class_list":["post-164930","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-dev","category-docker","category-how-to"],"_links":{"self":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/164930","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/comments?post=164930"}],"version-history":[{"count":1,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/164930\/revisions"}],"predecessor-version":[{"id":164980,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/164930\/revisions\/164980"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media\/164931"}],"wp:attachment":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media?parent=164930"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/categories?post=164930"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/tags?post=164930"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}