iTranslated by AI
Fully Automated Infrastructure Setup and Error Fixing with Claude Code
Introduction
After passing Cloudflare and GitHub API tokens to Claude Code, it handled everything from building the GitHub Actions workflows and configuring Cloudflare Pages deployments to automatically fixing errors.
In this article, I will share the story of automated infrastructure building and error correction by Claude Code, experienced during the development of my personal tool, "Daily Tech Digest." Based on actual session logs, I will introduce the specific workflow when entrusting infrastructure to Claude Code and how practical the automated error correction really is.
What I Built
Daily Tech Digest is a tool that automatically collects technical articles every day, analyzes them with AI, and delivers them as an HTML digest.
The process flow is as follows:
- Article Collection: Fetches technical articles from 13 RSS feeds, Reddit, and GitHub Releases.
- AI Analysis: Passes the collected 50–80 articles to the Claude API (Haiku) to generate Japanese summaries, relevance scoring (1-5), and translations of English titles.
- Topic Categorization: Uses the Claude API to cluster all analyzed articles into a maximum of 6 themes and generates a narrative overview for each topic.
- HTML Generation: Generates an HTML digest with topic-based layouts, dark mode support, and an in-page table of contents.
- Deployment: Automatically deploys to Cloudflare Pages to make it viewable in a browser.
This entire pipeline is executed automatically every day via GitHub Actions. By caching articles analyzed on previous days to skip re-analysis, API costs are kept under $1 per month.
The tech stack consists of Python 3.11, feedparser, the anthropic SDK, GitHub Actions, and Cloudflare Pages. The codebase is approximately 1,500 lines, and the initial implementation was completed in 54 minutes by leaving it to Claude Code. I have continued to make improvements as points of interest arise. This article focuses specifically on infrastructure building and error correction.
Fully Automated Infrastructure Setup
All I did was set the Cloudflare and GitHub API tokens as environment variables. After that, Claude Code built the following infrastructure completely automatically.
Migration from GitHub Pages to Cloudflare Pages
Because I operate in a private repository, I needed to switch from GitHub Pages, which I was initially considering, to Cloudflare Pages. Claude Code adopted the Direct Upload method using cloudflare/wrangler-action@v3 and rewrote the workflow YAML. The initial project creation was also automated with continue-on-error: true (a setting that prevents the entire workflow from stopping if a step fails), ensuring a design that does not error even if the project already exists.
Auto-generation of the 504-line setup.py
Claude Code generated a 504-line Python script that handles the collective setup of Cloudflare KV, Workers, and Access. The process is as follows:
- Connectivity verification of API tokens
- KV Namespace creation
- Workers deployment (executing
npx wrangler deployvia subprocess) - Workers Secret configuration (ANTHROPIC_API_KEY)
- Cloudflare Access setup (Pages protection + Workers API protection)
- AUD tag retrieval &
wrangler.tomlupdate
The script is designed with idempotency in mind (ensuring it is safe to execute repeatedly for the same result), skipping resources if they already exist. It is structured so that running python setup.py once completes all configurations on the Cloudflare side.
Secret Management via Infisical
To centrally manage secrets across multiple projects, I migrated from GitHub Secrets to Infisical (a secret management SaaS). This migration was also completed simply by having Claude Code modify the workflow YAML. I added Infisical/secrets-action@v1.0.9 and configured it to dynamically retrieve secrets using Universal Auth. Only the Infisical authentication information remains in GitHub Secrets.
The Final Version of the GitHub Actions Workflow
The final workflow is shown below (some settings such as permissions are omitted).
name: Daily Tech Digest
on:
schedule:
- cron: '0 16 * * *' # UTC 16:00 = JST 01:00 next day (to avoid API congestion)
workflow_dispatch:
jobs:
generate:
runs-on: ubuntu-latest
timeout-minutes: 10
steps:
- uses: actions/checkout@v4
- name: Fetch secrets from Infisical
uses: Infisical/secrets-action@v1.0.9
with:
method: "universal"
client-id: ${{ secrets.INFISICAL_CLIENT_ID }}
client-secret: ${{ secrets.INFISICAL_CLIENT_SECRET }}
project-slug: "homelab-5-ua1"
env-slug: "dev"
secret-path: "/daily-tech-digest"
- uses: actions/setup-python@v5
with: { python-version: '3.11', cache: 'pip' }
- run: pip install -r requirements.txt
- name: Restore previous output
uses: dawidd6/action-download-artifact@v6
continue-on-error: true
with:
name: digest-output
path: output
workflow: daily-digest.yml
if_no_artifact_found: ignore
- run: python digest.py
env: { ANTHROPIC_API_KEY: "${{ env.ANTHROPIC_API_KEY }}" }
- run: python deploy.py
- uses: actions/upload-artifact@v4
with:
name: digest-output
path: output
retention-days: 10
include-hidden-files: true
- name: Deploy to Cloudflare Pages
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ env.CLOUDFLARE_API_TOKEN }}
accountId: ${{ env.CLOUDFLARE_ACCOUNT_ID }}
command: pages deploy output --project-name=daily-tech-digest --commit-dirty=true
Everything from fetching secrets from Infisical, setting up the Python environment, restoring previous outputs, and generating the digest, to deploying to Cloudflare Pages, is consolidated into a single workflow. Claude Code built this entire workflow.
Automated Error Correction Cases
Infrastructure builds rarely work perfectly on the first try. The key is "what you do after an error occurs."
When Claude Code detects an error, it automatically loops through reading the logs, identifying the cause, fixing it, and re-executing. Here are some of the most memorable cases among them.
Case 1: Timezone Issue ── Identifying one root cause from three symptoms
Daily Tech Digest runs via GitHub Actions every morning, generating a digest HTML with that day's date (e.g., digest-2026-02-05.html). However, immediately after starting operation, the following three problems occurred simultaneously:
- The generated file date is off by one day (executed on 2/5, but
digest-2026-02-04.htmlwas generated) - The previous day's file is overwritten and lost (date mismatch causing a filename collision)
- Previously analyzed articles are displayed again the next day (because the cache date is also shifted)
Although these are three distinct symptoms, Claude Code did not treat them as separate problems but searched for a common root cause.
Claude Code Session Log (Timezone Issue)
1. Identifying the Root Cause
Important discovery. It is currently the morning of 2/5 JST, but it is still 2/4 in UTC.
I have identified the root cause.
Line 1398:
today_str = datetime.date.today().strftime("%Y-%m-%d")This uses the system's local timezone.
- GitHub Actions runs in UTC - cron
0 22 * * *(UTC 22:00 = JST 07:00)- When executing at UTC 22:00,
datetime.date.today()returns the UTC date- Since JST 2/5 07:00 = UTC 2/4 22:00, the generated file becomes
digest-2026-02-04.html
Analysis table created by Claude Code:
| Execution Timing (JST) | UTC Time |
date.today() (UTC) |
Expected Value | Actual |
|---|---|---|---|---|
| 2/5 JST 07:00 | 2/4 UTC 22:00 | 2026-02-04 | digest-2026-02-05.html | digest-2026-02-04.html |
2. Formulating the Fix
Hypothesis: If I change
datetime.date.today()to be JST timezone-based, all three problems will be solved.Fix strategy:
- Change date acquisition in
digest.pyto JST-based- Change
cleanup_oldindeploy.pyto JST-based (for consistency)
3. Verification After Fix
23:23:47 [INFO] ✅ Digest generation complete: output/digest-2026-02-05.html
The fix was completed in about 20 lines of changes. I implemented a get_jst_today() helper function to handle the JST timezone and applied it to both digest.py and deploy.py. The fact that it autonomously decided to fix two related files simultaneously to maintain consistency was not instructed by me; Claude Code determined it itself.
Case 2: API 529 Overloaded Countermeasures ── Simultaneous code and infrastructure config fixes
Daily Tech Digest sends 50–80 articles to the Claude API (Haiku) for analysis every time. Since it calls the API for each article, dozens of API calls occur in a single execution.
Initially, this workflow ran at JST 07:00 (= UTC 22:00). The retry logic in the initial implementation was a maximum of 3 retries with a 2-second initial delay exponential backoff (total max 14 seconds).
However, as I continued to operate it, the Claude API would return HTTP 529 Overloaded, and the morning digest generation would fail. A retry of about 14 seconds was not enough to wait for the server load to subside.
Claude Code implemented both code fixes and infrastructure configuration changes simultaneously to address this issue.
Measure 1: Strengthening Retry Logic
# Before
def _retry_with_backoff(fn, max_retries: int = 3, base_delay: float = 2.0):
# Total max wait: 2 + 4 + 8 = 14 seconds
# After
def _retry_with_backoff(fn, max_retries: int = 5, base_delay: float = 5.0):
# Total max wait: 5 + 10 + 20 + 40 = 75 seconds
It changed the number of retries from 3 to 5 and the initial delay from 2 to 5 seconds. The total maximum wait time increased from 14 seconds to 75 seconds, allowing it to withstand temporary load spikes.
Measure 2: Changing Execution Time
# Before
schedule:
- cron: '0 22 * * *' # UTC 22:00 = JST 07:00
# After
schedule:
- cron: '0 16 * * *' # UTC 16:00 = JST 01:00 next day
UTC 22:00 corresponds to 17:00 in US Eastern Time, a time when API servers are likely to be congested. By changing the execution time to UTC 16:00 (early morning in the US), it adopts a strategy to avoid API congestion itself.
What is interesting about this case is that it combined infrastructure configuration changes—"run in a time zone where the API is not congested in the first place"—with the code fix of simply "increasing the number of retries." Claude Code autonomously determined to analyze the correlation between API load patterns and execution time and modify both the code and the workflow simultaneously.
Other Automated Fixes
Besides the above, the following problems were fixed one after another in a single session (12 Edits, 76 Bash commands):
| Problem | Cause | Countermeasure |
|---|---|---|
| Cloudflare Pages deployment failure | Commit message contained Japanese, causing encoding error | Changed to fixed ASCII message |
| Artifact download failure | Lack of actions: read permission |
Added one line to permissions |
| Cache disappears every time |
.digest_cache.json (hidden file) not included in artifact |
Added include-hidden-files: true
|
| Workers API returns 401 for all requests |
CF_ACCESS_AUD value remained even after Cloudflare Access deletion |
Changed setting value to empty |
In every case, Claude Code read the error log, identified the cause, and performed the fix and commit automatically. All I did was inform it that "an error occurred," and in some cases, even that error report was unnecessary.
How usable is it? ── From personal use to production environments for commercial services
Practical enough for personal use
An approach like this, where you hit the API directly in a development environment to build infrastructure and fix it immediately when an error occurs, is perfectly practical for personal services. If you pass it the API tokens and say "deploy to Cloudflare Pages," it will handle everything from building the workflow to fixing deployment errors.
Cautious approach needed for commercial production environments
On the other hand, pointing Claude Code directly at the production environment of a commercial service is high risk. You would be giving Claude Code tokens with permissions to manipulate infrastructure, so if you let it touch production cloud resources directly, unintended changes could be reflected immediately.
In reality, you would likely have Claude Code write setup scripts or IaC (Terraform, Ansible, etc.) in a development environment, verify them in a staging environment, and then apply them to production. The role of Claude Code would be "writing code that builds infrastructure" rather than "touching infrastructure directly." Mock environments like LocalStack are preferable for testing if possible. If you must use a real cloud for staging, you need to be very careful with the permissions of the API token and monitor to ensure no unintended resources are created.
If you prepare an environment where you can perform test executions and verify results, infrastructure configuration changes can also be targets for automated verification. For example, if you build a mechanism in a CI pipeline that allows Claude Code to execute tests and verify the results, you will be able to take not only code but also infrastructure configuration changes through an "error → automated fix" loop.
The value of completing trial-and-error within Claude Code
In this experience, the most valuable part was that the entire loop of error detection → root cause identification → fix → re-execution was completed within the Claude Code session. Conventionally, the human would have to cycle through reading the error log, researching the cause, fixing it, and re-executing. Automating this cycle drastically shortens the time spent building infrastructure. vncprobe was also created based on this experience, thinking about how to entrust everything to Claude Code.
Conclusion
I experienced the building of everything from GitHub Actions workflow construction and Cloudflare Pages deployment settings to secret management using Infisical, all by simply passing API tokens to Claude Code. Furthermore, Claude Code read the logs to identify the causes of problems that occurred after deployment, such as timezone issues and API overloading, and automatically fixed them from both code and infrastructure perspectives.
This approach is perfectly practical for personal tool development. For commercial services, a workflow where you have Claude Code write IaC scripts and verify them in a staging environment is more realistic. I believe that preparing environments for test execution and result verification is the key to expanding the scope of this automation.
Discussion