Our software factory had already built Sentinel and deployed it to Vercel.
Sentinel is designed to provide weather, wildfire, and flood advisories backed
by signed evidence receipts.
For this experiment, we gave the agent a smaller infrastructure task:
redeploy the existing application, buy a suitable domain for no more than $3,
and connect it to the Vercel project.
The result was sentinelproof.click.
Registration cost $1.54. The website and its health endpoint worked over HTTPS.
A repeated run charged nothing.
Getting there exposed two useful details: DNS configuration is only one part of
readiness, and successful infrastructure setup does not prove the application's
main feature works.
Check the price before spending
Our first choice, sentinel.click, was already registered. We selected
sentinelproof.click instead, keeping the connection to Sentinel's evidence-based
approach.
A registry lookup helped us shortlist the name. The purchase decision used
Porkbun's own availability and price response. It confirmed:
- The domain was available.
- It was not a premium domain.
- The registration term was one year.
- The total registration price was $1.54.
The account had $10 in prepaid credit. After the purchase, it had $8.46.
The quoted renewal price was $10.81, so we disabled automatic renewal.
The first-year promotional price should not be mistaken for the long-term cost.
Before the purchase, the agent called Porkbun's registration endpoint in
dryRun mode. This validated the proposed registration without creating an
order or charging the account.
These prices were observed during our October 20, 2026 test. Future purchases
need a fresh quote.
Redeploy first, then connect the domain
The agent redeployed the existing Sentinel version through the Vercel API.
It waited for the deployment to reach READY, checked the application's home
page, and called /api/health. The health response reported that both the
application and its database were working.
Only then did the domain purchase proceed.
The agent added the purchased domain to the existing Vercel project, retrieved
Vercel's recommended DNS records, and created those records in Porkbun.
The responsibilities stayed separate:
Porkbun: domain registration and DNS
Vercel: application hosting and HTTPS
Agent: coordinate the steps and verify the result
There were no GitHub writes during this experiment. The work stayed in the
aicom workspace for the alexar76 ecosystem, with deployment performed
directly through Vercel.
DNS configured does not mean HTTPS ready
Initially, the browser could not resolve the new hostname. Public DNS later
returned the expected Vercel addresses, but HTTPS still failed.
Vercel had accepted the domain configuration. A separate certificate check
showed that no certificate had been issued for the hostname yet. The agent
requested one through Vercel's API.
After issuance, the new domain opened Sentinel over HTTPS. Both the home page
and /api/health returned 200 OK, and we confirmed the page in a browser.
Following that first run, we added automatic readiness waiting to the script.
It now distinguishes waiting for DNS, a certificate, HTTPS, the application,
or the provider. It pauses 20 seconds between checks within a 10-minute waiting
window; an already-running network request finishes under its own timeout.
The script marks setup as ready only after the domain, DNS, certificate,
expected page, and API health checks pass.
If the waiting window expires, it saves a pending status. A later invocation
resumes setup for the same purchased domain. There is no background worker
installed yet, so an exited process must be started again.
The second run matters
After the purchase and configuration, we ran the workflow again.
It reused the existing deployment and saved purchase receipt. It did not
register another domain or charge for the same one again. The balance stayed
at $8.46.
The purchase intent is persisted before the billable request. If the registrar
processes the order but its response is lost, a retry uses the same operation
identifier and request body.
The script also limits how long it will replay an uncertain operation.
Once that window expires, it stops for reconciliation instead of issuing a
fresh purchase.
Tests covered the spending ceiling, a lost response after registration,
expiration of the retry window, account binding, and preservation of unrelated
DNS records. The package passed 66 tests during the original pilot.
Four additional tests subsequently covered readiness delays, timeout and resume,
application health, and provider errors.
Operation state is encrypted and excluded from Git. Porkbun credentials stay
outside the repository, and the Vercel token remains on the factory server.
What the test proved—and what still needs work
The infrastructure result was successful:
| Check | Result |
|---|---|
| Redeploy the existing Sentinel version | Passed |
| Register one domain within the $3 limit | $1.54 |
| Connect DNS and verify the domain | Passed |
| Serve Sentinel over HTTPS | Passed |
| Check application and database health | Passed |
| Repeat without another domain charge | $0 |
The application's safety report had a separate limitation.
For the Berlin example, it returned UNKNOWN. The upstream ATLAS capability,
atlas.situation.brief@v1, reported that it required paid access and was not
available in the current free mode. We observed the same result on both the
original Vercel URL and the new domain. We made no additional ATLAS payment.
That means this experiment demonstrated deployment and domain provisioning,
but did not demonstrate a complete weather, wildfire, and flood advisory.
There were also deliberate boundaries. The owner supplied production keys and
funded the Porkbun account beforehand. The purchase used that account's credit
and existing registration contacts. The application had already been built.
The pilot is pinned to one project, one domain, and a $3 ceiling; the existing
supplier adapter remains sandbox-only.
The practical use case is a service that delivers a website with its own
address. Once the domain has been purchased and connected, later deployments
can keep using it. They should not trigger another purchase.
Top comments (0)