I typed kimkj.com into the browser. The site did not open. I refreshed, changed networks, and tried again. The result was the same. A website built over months had suddenly stopped responding.

kimkj.com is not just a small profile page. It contains Kim Kyung-jin’s AI library, AI board, lecture materials, and multilingual pages. Technically, it is a WordPress site running on AWS Lightsail. The bulletin boards use KBoard, and the site is operated in Korean, English, Chinese, and Japanese.

This time, OpenAI Codex was asked to handle it. The instruction was simple: “Check whether kimkj.com is working, and fix it if there is a problem.”

Codex first checked DNS. kimkj.com was pointing to the static IP address 43.202.123.207. This was an AWS Lightsail static IP. With Lightsail, a static IP can be detached from one instance and attached to another without changing DNS records.

At first, local checks to HTTP port 80 and HTTPS port 443 timed out, and administrative access was also not connecting normally. This looked less like a broken WordPress page and more like a server or network-level failure.

The AWS Lightsail console showed two WordPress instances in the Seoul region: WordPress-Lightsail-20260508, which contained the latest content, and WordPress-2, an older fallback instance.

The first priority was to bring the site back online. Codex detached the static IP 43.202.123.207 from the suspected failing instance and temporarily attached it to WordPress-2, which was responding normally. This allowed kimkj.com to come back without touching DNS.

The site opened again. But there was a problem: WordPress-2 did not contain the most recent updates. The user then clarified that the current version was on WordPress-Lightsail-20260508, so Codex re-examined that instance.

During that process, one mistake was corrected. A dynamic IP had initially been read as 3.56.59.80, but the actual IP was 3.36.59.80. With the correct IP, the latest instance responded, and Apache, MariaDB, and SSH were confirmed active.

The static IP 43.202.123.207 was then moved back to WordPress-Lightsail-20260508. kimkj.com was restored to the server that contained the current content, and the site returned HTTP 200 OK.

Codex did not stop once the site was visible. Both WordPress instances were backed up, including WordPress files and the database. The encrypted local backup files were:

• WordPress-Lightsail-20260508 backup: about 481 MB

• WordPress-2 backup: about 465 MB

• Storage location: the user’s local Codex workspace

• Verification: SHA256 checks and decryption test completed

The backups were not plain archives. They were encrypted tar.gz.enc files. Each archive contained a WordPress file bundle, a database dump, a README file, and backup warning logs. Temporary backup files placed on public server paths were removed after verification.

The main technical risk was memory pressure during WordPress uploads. The active Lightsail instance has 2 GB of memory, but it had no swap space. When memory briefly ran short, Linux had no buffer to absorb the spike.

Apache was running in prefork mode. This is stable with PHP, but it can consume memory quickly when too many worker processes are active. Uploading several large book files in a row can trigger PHP processing, WordPress plugin work, attachment metadata generation, and database writes at the same time.

So yes, uploading one book at a time, with a time gap between uploads, reduces the chance of another stall. It gives the server time to release memory and finish background processing. But that is an operational habit, not a complete architectural fix.

The first stabilization pass added no monthly server cost. The actual changes were:

• Added a 2 GB swap file as a memory safety buffer

• Tuned Apache prefork and set MaxRequestWorkers 10

• Set MaxConnectionsPerChild 500 to recycle workers

• Tuned PHP: memory_limit 384M, upload_max_filesize 256M, post_max_size 300M, max_execution_time 300 seconds

• Verified Apache config with apache2ctl configtest and confirmed Apache, MariaDB, and SSH were active

The phrase “limited simultaneous connections to 10” should be understood precisely: the setting limits Apache’s simultaneous worker processes, not the exact number of human visitors. On a small Lightsail instance, this is an important guardrail against memory exhaustion.

Before deleting WordPress-2, a Lightsail snapshot was created. Then the unused instance was removed. The site now runs on one Lightsail instance, WordPress-Lightsail-20260508. In instance cost terms, that reduces the monthly server bill from roughly 24 dollars to roughly 12 dollars.

Snapshots still have a small separate storage cost. So the accurate summary is this: one running server keeps the monthly instance cost down, while snapshots are retained for safety at a small additional cost.

The site is more stable now, but more traffic, more automation, and more large file uploads will eventually require a broader plan.

• Short term: upload large books one at a time with pauses between uploads.

• Medium term: move to a 4 GB or larger Lightsail instance.

• Medium term: combine scheduled snapshots with encrypted local backups.

• Long term: move large files to object storage such as S3.

• Long term: separate WordPress, database, and file storage to reduce failure scope.

The cheapest path is to keep the current 2 GB server and operate conservatively. The most robust path is to upgrade the instance and separate storage, but that raises monthly costs. The right choice depends on how much stability is needed and how much cost is acceptable.

In this incident, Codex did more than give advice. It checked DNS, tested ports, used the AWS Lightsail console, moved a static IP, inspected server services over SSH, backed up WordPress files and the database, adjusted Apache and PHP settings, created snapshots, and removed an unused instance after confirmation.

AI agents still make mistakes. In this case, an IP address digit was misread once. The important point is the operating method: re-check, verify against actual server responses, and require user confirmation before risky deletion. Website operations are not about perfect speech. They are about procedures that can be audited and recovered.

Personal website management is changing. Domains, WordPress, backups, server configuration, and cost review can now be handled with an AI agent through natural language. The recovery of kimkj.com shows that this is no longer theory. It is already possible in real operations.