We’re well into the age where an agent can build a dynamic website end to end: writing the code, testing the UI with a browser and managing the database. The models are also capable enough to manage the infrastructure. I’ve been looking for a way to give an agent the freedom to deploy websites without also giving it the freedom to wreck everything else I run.
This is nothing new, ChatGPT sites already let you prompt an application into existence, but I want something I own, control and could manage myself in future.
The result is Launch Factory: a reusable setup for building and deploying small dynamic applications. I’m keeping the code to myself for now but no doubt this can be built entirely for a small number of tokens.
I built it through Hermes Agent, but nothing here should be agent specific.
Requirements
I started with a fairly short list of requirements:
- It should be cheap to run and host.
- It should not run on my main VPS. This is somewhat untrusted code exposed to the internet, so I want a real layer of separation rather than another container on the same machine.
- Deployments should be repeatable. When I ask an agent to use the factory, it should spend its time on the application rather than rediscovering the release process.
- The deployment credentials should not grant access to unrelated infrastructure, including this blog.
- “Dynamic” means more than serving files. Each application should start with access to a relational database, with room to add object storage later.
The plan
After some back and forth with Hermes, I settled on the Cloudflare Workers stack. A Cloudflare API token can be scoped to a dedicated account linked to my existing user, which gives the agent a useful but bounded blast radius.
That covered the compute side but not the database. I chose Neon because it provides managed PostgreSQL and can scale compute down to zero. That is a good fit for an application which might be used for five minutes a day and then sit idle.
With those boundaries agreed, the implementation was handled by the agent using dedicated Cloudflare and Neon credentials. The credentials can manage Launch Factory resources, but they cannot touch the infrastructure behind this blog or the rest of my VPS.
Cloudflare Zero Trust protects preview URLs with a one-time PIN restricted to approved email addresses. The todo example below is deliberately public, but previews and future private applications do not need to be exposed while they are being built.
The stack
The current setup uses:
- TypeScript with Hono for the application;
- Neon PostgreSQL with Drizzle migrations;
- Cloudflare Workers for compute;
- Cloudflare Hyperdrive between each Worker and Neon;
- OpenTofu for infrastructure;
- GitLab for source control, CI and the remote OpenTofu state backend;
- a private instance repository for non-secret deployment metadata.
Cloudflare also documents the Neon and Hyperdrive combination, so this is a fairly conventional serverless stack.
Each product has a deliberately boring layout:
products/<slug>/
product.json
app/
deploy/
product.json describes the product. app/ contains the application and migrations. deploy/ is one OpenTofu root which owns the database, Hyperdrive connection, Worker identity, immutable Worker version and deployment.
A release is:
build -> migrate -> plan/apply -> smoke test
When creating a new app the model can spin up the backend to initialise the database, run the migrations and only then make it publicly accessible.
The skill
The repository contains the application and infrastructure, but the operating knowledge lives in a skill.
There is an example skill for it, and it’s roughly the following:
Before cloud work:
run lf doctor --cloud
Release:
1. require a clean revision and a green verification gate
2. build the immutable Worker bundle
3. provision without serving on a fresh environment
4. run database migrations
5. plan and apply with serving enabled
6. verify health, readiness and a representative operation
7. confirm repeated requests all serve the expected Worker UUID
Never:
- let Wrangler deploy directly
- migrate from Worker startup
- commit credentials, state, plans or tfvars
- automate deletion of the Neon database
Example deployment
The first test is a deliberately simple public todo application. It stores todos in a PostgreSQL table and lets anyone create, complete and delete them.
It is intentionally basic. It just shows that the core building blocks of a small dynamic site work together.
Next steps
The obvious additions are Cloudflare R2 for object storage and Cloudflare Queues for background jobs. With those two pieces the same setup could support uploads, generated files, email delivery and work that should not happen during a web request.