From a domain to your first complete application
Six verifiable stages cover domain setup, application development, data, defense, and production release.
Edited and verified by Orange Book Editorial Team ·
This path is for someone putting an AI-generated project on Cloudflare for the first time. An “AI application” does not mean an agent or chatbot here. It means a normal application completed with AI assistance. A SaaS, CMS, image converter, or PDF utility all qualify. Completion means more than seeing a home page: domain, core flow, data boundary, security rules, and rollback must all be verifiable.
Final completion criteria
A custom domain responds; success and failure paths are tested; secrets never enter browser code or the repository; data recovery is separate from code rollback; and logs can place a failure on the request path.
Six-stage growth path
- 01Connect the domain
Separate DNS, proxying, TLS, and caching in your mental model.
Start setup - 02Constrain AI
Provide versions, runtime, bindings, and an acceptance contract before code.
Prepare context - 03Build the application shell
Separate assets, request logic, structured data, objects, and background work.
Understand the layers - 04Complete one project
Choose a SaaS, CMS, image utility, or PDF utility and close one loop.
Choose a project - 05Establish defenses
Cover public pages, forms, login, APIs, and administration.
Configure defenses - 06Verify the release
Build, preview, observe, stage, and roll back with evidence.
Run the release checklist
Understand the synchronous request first
Detailed description
- 01Client
A browser, mobile application, or API caller.
- 02DNS
Controls name resolution and whether traffic is proxied.
- 03Edge
Handles TLS, security policy, and cache decisions.
- 04Worker
Runs routing, authorization, and application logic.
- 05Resource
Reads a binding or existing origin only when needed.
Choose one complete project
Multi-tenant SaaS
Content CMS
Image converter
PDF toolkit
Leave evidence at every stage
| Stage | Minimum evidence | What cannot replace evidence |
|---|---|---|
| Domain | DNS lookup, TLS response, proxy status | A saved-looking dashboard screen |
| Application | Success, 404, and validation tests | AI saying “it works” |
| Data | Local migration, bound queries, tenant boundary | A schema file alone |
| Security | Server-side validation and rule events | Hiding a button in the browser |
| Release | Preview smoke, version ID, rollback trigger | Running deploy once |
Do not pursue every capability at once
The first release needs one core user flow. An image tool does not need natural-language search, a CMS does not need customer code execution, and a normal SaaS does not need Workers for Platforms by default.
Remote changes and rollback boundary
This path does not automatically modify production DNS, create billed resources, apply remote D1 migrations, or deploy WAF rules. A Worker code version can be rolled back, but data in D1, R2, and Durable Objects does not automatically follow the code rollback. Back up irreversible changes and keep old code compatible with the new schema during the migration window.
Next: prepare context for AI-assisted development.
Primary sources
Did this page help you complete your goal?
Beta feedback is generated in this browser and is never uploaded automatically.
15 · End-to-end performance verification and diagnosis
Use evidence from DNS, TLS/protocol, cache, origin transit, application, and Core Web Vitals to locate where a site is actually slow.
Learning path: domain to first edge API
Four progressive modules cover the request model, Worker development, verification, and Free-plan limits.