Publish a Small Static Project on Cloudflare Pages

What belongs in a static deployment?

A static deployment contains files the browser can receive directly, such as HTML, CSS, JavaScript, and images. Establish what your project actually needs before uploading. A working static page can display information and run browser code, while server features require an appropriate runtime and configuration.

Keep the practice brief small: publish a weekly study plan with a heading, three study blocks, and links to resources you can legally share. Use no login, payment, upload, or private database for this exercise. That gives you a clear result to inspect without hiding a backend requirement inside the project.

Cloudflare documents support for static HTML websites on Pages. [1] If your project needs server-rendered routes, a database connection, or secret API credentials, follow its relevant framework and runtime guidance instead. Do not move a secret into browser JavaScript to make a static deployment “work.” Browser-delivered files should be treated as public information.

How do you prepare the files?

Prepare one clean output folder and check that its homepage and referenced assets are inside it. If a framework generates the site, run its build first and identify the output directory. Upload the deployable result rather than assuming the source repository is the finished website.

For a hand-written site, put index.html, a stylesheet such as styles.css, and any needed assets together in the intended deployment folder. For a framework project, inspect the build command and output path documented for that framework. Cloudflare’s Direct Upload guide requires prebuilt assets. [2]

Open the homepage locally using your normal development preview. Check each asset reference and filename, including capitalization. Remove unused test files and private notes from the release folder. Add a 404.html with a useful message and a route back to the homepage; Cloudflare describes how this file controls its not-found response. [3] Keep the editable source separately so a clean upload never becomes your only copy.

Should you use Git integration or Direct Upload?

Choose a release method based on how you will update the project. Git integration suits a repository-driven workflow, while Direct Upload accepts prepared assets from your own build process. Read the current method restrictions before creating the project, because moving between project types may require a new project.

Cloudflare’s Git integration can build and deploy changes pushed to a connected repository. [4] It is useful when you want the source history and publishing workflow together. Direct Upload is useful when you already have a built folder and want to submit it directly. [2]

For this small exercise, choose one method and write down why. A first upload can be simpler with a prepared static folder; ongoing collaborative development may fit a repository workflow better. Neither choice removes the need to inspect what will be published. Check current account limits, applicable charges, and method-specific restrictions in the official documentation rather than assuming “static” means every future feature is free.

How do you publish the first version?

Follow the current official steps for the chosen method, select the intended project and output folder, and inspect the resulting deployment. Keep the first release limited to the practice site. A deployment success message is useful evidence, but the published page still needs its own checks.

For Direct Upload, follow the linked guide’s dashboard or Wrangler instructions. The documented upload formats differ between methods: Wrangler receives a folder, while dashboard drag and drop accepts a folder or ZIP. [2] Choose the folder containing the actual homepage rather than an extra enclosing directory with another copy inside it.

For Git integration, connect the intended repository and configure its documented build and output settings. [4] Inspect the selected repository, branch, and destination before publishing. After release, save the exact site address and deployment identifier in your project notes. A source archive, dashboard preview image, or repository URL is not a substitute for opening the published site itself.

What should you check on the published website?

Open the published address and test the pages, assets, navigation, and missing-page behavior. Repeat the main tasks on a narrow screen and with keyboard navigation. Compare what the browser receives with your intended release instead of treating a successful build as proof that every route works.

Use a short acceptance checklist for the study-plan site:

• The homepage identifies the project and explains the three study blocks.
• The stylesheet loads and text stays readable on a small screen.
• Each resource link points to the intended destination.
• Keyboard focus is visible on links.
• A deliberately missing address presents a useful not-found page.
• Refreshing an existing nested page does not lose it.

Cloudflare documents extensionless HTML routing and custom not-found behavior. [3] Test your actual paths rather than guessing which URL form will be used. If styles are missing, compare the published asset path and filename with the build folder. If old content appears, first verify the deployment and address you opened before changing unrelated settings.

How do you make the next release reliable?

Make one visible change, rebuild when required, and publish through the same recorded workflow. Verify both the new change and a few unchanged features. Keep source history and deployment notes so you can identify which version is live and recover from a broken update.

Change one study block’s label or add one owned image with descriptive alternative text. Record the intended change, produce the output again if needed, and deploy it to the existing project. Confirm the exact live address shows the change, then retest the homepage, resource links, and not-found page.

Keep a release note with the source revision or file version, build command, output folder, deployment time, and published address. Avoid overwriting an older working source copy with an unverified experiment. Once this cycle is repeatable, you can consider a custom domain, forms, analytics, or other features individually. Each addition should have a clear purpose, data-handling decision, and verification step rather than arriving as an unexplained bundle.