Bringing My Blog Back with Codex Computer Use

Sat, 26 Sep 2026 00:00:00 +0000

My blog’s source code was sitting in GitHub. My domain, jacobaloysious.in, was registered with GoDaddy. I had a Vercel account ready to use. Somewhere in the background, an old AWS setup was still involved.

The goal sounded simple: publish the blog from GitHub using Vercel and make it accessible through my own domain.

This time, I asked Codex to help do the work through Computer Use. Instead of following a deployment tutorial and switching between dashboards myself, I let it inspect the browser, configure the deployment, and trace the domain setup. I stayed involved when access or missing context required my input.

It turned into a useful exercise in both AI-assisted work and remembering how my own website was wired together.

1. Get Computer Use working

The first obstacle appeared before deployment even began. Although I was signed in to GitHub, Vercel, and GoDaddy in Chrome, Codex could not initially connect to my browser.

The Computer Use setting showed:

Disabled by your organization or unavailable in your region.

The message alone did not establish the cause. We checked the available setup guidance, but did not conclusively diagnose why the setting was disabled. I subsequently enabled Computer Use and asked Codex to continue.

Once access was working, Codex could inspect my existing signed-in Chrome tabs and interact with the account dashboards.

The first lesson: being signed in to a website and giving an assistant access to that browser are separate steps.

2. Inspect the existing Hugo project

My Hugo source lived in a private GitHub repository.

Codex inspected the project and its existing GitHub Actions workflow. That revealed several details that mattered for the new deployment:

The site used Hugo with the Academic theme.
The theme was included as a Git submodule.
The existing build pinned a specific Hugo Extended version.
A custom icon was copied into the theme before building.
The previous workflow published the generated public directory to AWS S3.

Reading the old workflow gave us a starting point for a compatible build. There was no need to combine a hosting migration with a theme or Hugo upgrade.

3. Import the repository into Vercel

In the Vercel dashboard, Codex opened Add New → Project, selected GitHub, and selected my blog repository.

Vercel already had access to the repository, so it could import the private project without making the source code public.

The project configuration was:

Setting	Value
Framework preset	Hugo
Root directory	Repository root
Source branch	The production branch
Environment variable	`HUGO_VERSION`, matching the existing build
Build output	`public` through the Hugo preset

We overrode the build command to preserve the existing theme setup. The build initialized the Git submodules, copied my custom icon into the theme, and generated the static site with the intended production URL.

A simplified example of the Hugo generation step is:

hugo --minify --baseURL https://example.com/

Use your own domain in place of example.com, and include any preparation steps required by your theme.

4. Deploy and check the actual website

The first Vercel deployment succeeded. The blog became available at its Vercel-provided address.

Codex then opened the deployed site and checked more than the deployment success message. The homepage displayed my biography, profile image, styling, and recent posts. It also opened the Leadership - Buy In | Meetings article and verified that its content loaded.

At this point, the hosting part was working. The Vercel project was connected to GitHub so future pushes to the production branch could trigger new deployments.

5. Add the custom domain in Vercel

Next, Codex added jacobaloysious.in to the project’s production environment.

We kept the address without www as the main domain. Codex also added www.jacobaloysious.in and configured a 308 permanent redirect to jacobaloysious.in.

Vercel supplied the DNS records needed for this project:

Type	Name	Destination
A	`@`	The IP address provided by Vercel
CNAME	`www`	The CNAME target provided by Vercel

The destinations are intentionally generalized here. Use the exact records displayed in your own Vercel dashboard.

6. Discover the old AWS connection

I expected the next step to be editing DNS in GoDaddy. Instead, GoDaddy showed that the domain’s DNS was managed by Amazon Route 53.

That explained why registering the domain with GoDaddy did not mean GoDaddy controlled its active DNS records.

The services had different jobs:

Service	Role in this setup
GitHub	Stored the Hugo source and content
Vercel	Built and hosted the website
GoDaddy	Registered the domain; later became its DNS provider
AWS	Previously supplied Route 53 DNS and the S3 deployment destination

Codex initially suggested updating the existing Route 53 records to preserve anything else using that DNS zone. I clarified that I no longer used the AWS setup and wanted the website routed to Vercel.

That context mattered: it allowed us to replace the old nameserver delegation instead of requiring access to AWS.

7. Move DNS management back to GoDaddy

Codex selected GoDaddy’s default nameservers and completed the confirmation flow, moving DNS management back to GoDaddy.

Once the GoDaddy DNS records became available, Codex made two changes:

Replaced the parked @ A record with the IP address supplied by Vercel.
Changed the www CNAME to the target supplied by Vercel.

GoDaddy confirmed that both records were saved successfully.

Changing DNS and retiring the previous hosting setup are separate tasks. A migration should also include a review of old deployment workflows, credentials, and billable resources.

8. Investigate Vercel’s “Invalid Configuration” warning

After saving the records, Vercel still showed Invalid Configuration for both domain names.

It was tempting to assume we had entered something incorrectly. Codex compared the saved GoDaddy records with Vercel’s required values and ran public DNS checks.

The records matched, but the public lookups were still reaching the old AWS nameservers. Those servers refused the queries, and the lookups returned SERVFAIL.

So there were two different states:

In GoDaddy: the new nameservers and Vercel records were saved.
In the public DNS checks: the old AWS delegation was still being used.

Vercel could not verify the custom domain while those lookups were failing. A browser check also failed to resolve the domain, so we could not yet verify HTTPS on the custom address.

GoDaddy advised that most DNS updates take effect within an hour, but global propagation can take up to 48 hours. Saving a DNS change is not the same as every resolver seeing it immediately.

9. Verify the domain and go live

After the DNS changes propagated, the domain was verified and the blog became accessible at jacobaloysious.in.

The completed setup:

The Hugo blog was deployed and working on its Vercel address.
GitHub was connected to Vercel for future deployments.
The main domain and www redirect were configured in Vercel.
GoDaddy had accepted the nameserver change and saved the required records.
The custom domain was verified and the website was live at jacobaloysious.in.

The earlier Invalid Configuration warning was an intermediate state during the migration. Once the DNS change took effect, the main goal was complete: readers could use my own domain to access the blog hosted on Vercel.

What I learned from using Computer Use

The most useful part was watching Codex carry context across several services. It read the old build workflow, applied those details in Vercel, discovered the Route 53 dependency in GoDaddy, and used DNS checks to explain the remaining warning.

It also exposed where my input was necessary. I had to enable browser access and explain that AWS was no longer part of the intended setup. The assistant could inspect the dashboards, but it could not infer that decision from a nameserver entry alone.

There were practical limits too. Browser pages needed time to load, some interactions needed another attempt, and a successful save did not guarantee an immediately working domain. Verification remained part of the job.

For me, this was a concrete example of AI helping with an operational task: taking an existing website, understanding enough of its history to deploy it, and working through the connections between source code, hosting, registration, and DNS.

My blog is now live at jacobaloysious.in, with the content in GitHub, hosting on Vercel, and domain registration and DNS managed through GoDaddy. The old AWS nameserver dependency has been replaced.

For future posts, the publishing flow is simple: update the content in GitHub, push to the production branch, and let Vercel build and deploy the site.

Vercel | Jacob Aloysious