Launch Your First Website to the Cloud

Build and publish a personal HTML and CSS website with Cloudflare Pages.

Introduction

30 Second Summary

A page saved on your Mac is easy for you to open. Everyone else needs a public web address before they can see it.

In this project, you will build a personal launch card with HTML plus CSS. You will publish Version 1 with Cloudflare Pages before proving that local edits stay private until you deploy again.

What You'll Build

You will share a public .pages.dev address that opens your polished launch card from any browser.

By the end of this project, you'll have:

Open Version 1 locally in Safari as a styled launch card stored on your Mac.
Share a public production URL that displays the same Version 1 card through cloud hosting.
Compare local and production versions to prove that a saved edit stays separate from the published snapshot.
Secret Mission: Publish a preview deployment with a new learning section while production remains on Version 2.

Are there any prerequisites?

No prior cloud experience is required. The project covers installing Visual Studio Code plus creating your Cloudflare account.

Before We Start

This is your moment to commit to building a public personal launch card before the hands-on work begins. Your card will show your cloud-project status and deployment version so someone else can open it online.

Set Up Your Mac and Cloud Account

Your launch card is still only a plan on your Mac. Installing the editor now keeps tool setup from interrupting your first build.

Visual Studio Code gives you one place to manage the website files. Cloudflare Pages will turn those files into a public website later.

Safari lets you compare the local page with its public cloud version.

In this step, get ready to:

Install an editor that can manage your website files.
Create a verified Cloudflare account without adding a payment method.
Create an empty workspace for your launch card.

Install Visual Studio Code

A code editor keeps related files together while you build. Visual Studio Code is free to use without an editor account or extensions.

Press Cmd+Space to open Spotlight.
Type Safari and press Enter to open it.
Open the official Visual Studio Code macOS setup page.
Download Visual Studio Code for macOS from the setup page.
Open the downloaded .dmg file from Downloads in Finder.
Drag Visual Studio Code.app into the Applications folder.
Press Cmd+Space to open Spotlight again.
Type Visual Studio Code and press Enter to open it.

✔️ Visual Studio Code opens

Your editor is ready. Visual Studio Code can now hold the complete launch-card workspace.

ⓧ My Mac is unsupported

Some older Macs cannot run the current Visual Studio Code desktop build. TextEdit gives you a built-in fallback for editing the same website files.

Press Cmd+Space to open Spotlight.
Type TextEdit and press Enter to open it.

Your fallback editor is ready for the website files you create in the next step.

Visual Studio Code did not open?

Check the Applications folder for Visual Studio Code.app.
Open the downloaded .dmg again if the app is missing.

Get help with troubleshooting the Visual Studio Code installation. You can also ask the NextWork community.

Create and verify a Cloudflare account

A Cloudflare account owns the deployment you publish later. Cloudflare Pages has a free starting path that does not require a credit card.

Account creation asks for login credentials. Your password stays in Cloudflare's form throughout this project.

Switch back to Safari.
Open the official Cloudflare Sign up page.
Enter your email address in the Email field.
Enter a password in the Password field.
Select Create Account.

Cloudflare sends a verification message to the email address you entered. That link confirms you control the account's email address.

Open Cloudflare's verification email in your email service.
Follow the verification link in the email.
Sign back in to Cloudflare with your verified account.
Keep the payment method unset for this project.
Confirm the Cloudflare dashboard loads in Safari.

Your verified account is ready. You now have the cloud destination that receives the launch card later.

Verification email missing?

Check the filtered or unwanted-message folders in your email service.
Confirm you entered the intended email address on the Cloudflare Sign up page.

Get help with finding or completing the Cloudflare verification email. You can also ask the NextWork community.

Prepare the workspace

A project folder gives every website file one shared home. Starting with an empty folder makes the files you create next easy to spot.

Press Cmd+Space to open Spotlight.
Type Finder and press Enter to open it.
Select Desktop in the Finder sidebar.
Select File in the menu bar.
Select New Folder.
Enter first-cloud-launch as the folder name.
Press Return to create the folder.

Finder now shows an empty first-cloud-launch folder on your Desktop.

✔️ Visual Studio Code is ready

Switch back to Visual Studio Code from earlier.
Select File in the menu bar.
Select Open Folder....
Select the first-cloud-launch folder from your Desktop.
Confirm the folder selection in the macOS file picker.
Select the Explorer icon in the Activity Bar if the sidebar is hidden.

The Explorer shows first-cloud-launch with no files beneath it. Your workspace is open without any website code yet.

ⓧ I am using TextEdit

Keep the first-cloud-launch folder visible in Finder.
Switch back to TextEdit from earlier.
Confirm the first-cloud-launch folder contains no files in Finder.

TextEdit is ready beside the empty project folder. You will save each website file into that folder in the next step.

Before the final check, what should you see if the workspace is ready without starting the website build?

Return to the workspace you prepared.
Confirm the first-cloud-launch folder is empty.
Switch back to Safari.
Confirm the Cloudflare dashboard still loads under your verified account.

You will see an empty first-cloud-launch folder with no index.html or styles.css files. Safari will show the Cloudflare dashboard without any payment method added.

Your editor, verified cloud account, and empty workspace are ready. Next, you will turn that empty folder into a launch card you can open on your Mac.

Build Your Local Launch Card

Your empty first-cloud-launch folder is ready. You will turn it into a local launch card with HTML and CSS.

A working local page gives you an immediate result. Files stored only on your Mac cannot give other people a public website to visit.

In this step, get ready to:

Create index.html and styles.css inside first-cloud-launch.
Build and style the Version 1 launch card.
Open the local page in Safari and confirm its local file address.

Create the page structure

The index.html file holds the content that Safari displays. The styles.css file controls how that content looks.

Visual Studio Code

Use the new-file control in the Explorer from earlier to create index.html inside first-cloud-launch.
Use the same control to create styles.css beside index.html.

TextEdit

Create a new TextEdit document from the File menu.
Convert the document through the Format menu by choosing Make Plain Text.
Save the document as index.html inside first-cloud-launch.
Select Use .html if TextEdit asks about the file extension.
Create a second plain-text document through the same menus.
Save the second document as styles.css inside first-cloud-launch.

You should now see index.html and styles.css at the same level inside first-cloud-launch.

In index.html, add the launch card structure by copying this code:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>My Cloud Launch</title>
    <link rel="stylesheet" href="styles.css" />
  </head>
  <body>
    <main class="launch-card">
      <p class="eyebrow">MY FIRST CLOUD PROJECT</p>
      <h1>Hello, cloud.</h1>
      <p class="intro">
        I'm learning how local files become a public website.
      </p>

      <div class="status">
        <span class="status-dot" aria-hidden="true"></span>
        <span>Live on Cloudflare Pages</span>
      </div>

      <ul class="facts">
        <li><span>Built on</span><strong>macOS</strong></li>
        <li><span>Made with</span><strong>HTML + CSS</strong></li>
        <li><span>Deployment</span><strong>Version 1</strong></li>
      </ul>
    </main>
  </body>
</html>

What Does This Code Do?

The document head gives the page its title. It also connects styles.css from the same folder.
The launch-card element groups the complete card into one page section.
The status area shows the deployment message with a separate status dot.
The facts list records the platform. It also records the tools and the Version 1 deployment value.

Save index.html.
Switch back to Finder.
Select index.html inside first-cloud-launch.
Choose File from the menu bar.
Choose Open With.
Choose Safari.

Safari should show the launch card text in a plain layout. You should also see Version 1 in the facts list.

Page Blank or Missing Content?

Confirm the file is named index.html with no extra extension. Compare the opening and closing tags with the reference below.

If TextEdit shows the HTML tags as page text, reopen the file as plain text before saving it again.

Help me fix my local index.html page.

✔️ Awesome, I've got everything!

Your page structure is saved. Keep the local Safari tab available for the styling checks.

ⓧ I'd like to double check the full code

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>My Cloud Launch</title>
    <link rel="stylesheet" href="styles.css" />
  </head>
  <body>
    <main class="launch-card">
      <p class="eyebrow">MY FIRST CLOUD PROJECT</p>
      <h1>Hello, cloud.</h1>
      <p class="intro">
        I'm learning how local files become a public website.
      </p>

      <div class="status">
        <span class="status-dot" aria-hidden="true"></span>
        <span>Live on Cloudflare Pages</span>
      </div>

      <ul class="facts">
        <li><span>Built on</span><strong>macOS</strong></li>
        <li><span>Made with</span><strong>HTML + CSS</strong></li>
        <li><span>Deployment</span><strong>Version 1</strong></li>
      </ul>
    </main>
  </body>
</html>

How To Use This Reference

Compare this file with your saved index.html. Pay close attention to the class names because the stylesheet uses those exact values.

Style the launch card

The page structure is working. Styling now turns the plain document into a centered card with a dark background.

In styles.css, add the page-wide layout rules by copying this code:

* {
  box-sizing: border-box;
}

:root {
  color-scheme: dark;
  font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

body {
  min-height: 100vh;
  margin: 0;
  display: grid;
  place-items: center;
  padding: 24px;
  color: #f8fafc;
  background: radial-gradient(circle at top, #1d4ed8 0%, #0f172a 55%, #020617 100%);
}

What Do These Rules Control?

The universal selector keeps element sizes predictable when padding and borders are added.
The root rule selects a dark colour scheme. It also defines the page font stack.
The body rule fills the browser height. Its grid layout places the card in the centre.
The radial gradient creates the blue-to-navy page background.

Save styles.css.
Return to the local Safari tab.
Refresh the page.

You should see the page content centred over a dark blue gradient.

Still Seeing a White Background?

Confirm styles.css is saved beside index.html. Check that the stylesheet link still uses the exact filename.

Help me connect my local stylesheet.

Append the card panel and heading rules below the body rule in styles.css by copying this code:

.launch-card {
  width: min(100%, 620px);
  padding: 40px;
  border: 1px solid rgba(148, 163, 184, 0.35);
  border-radius: 24px;
  background: rgba(15, 23, 42, 0.9);
  box-shadow: 0 24px 70px rgba(2, 6, 23, 0.55);
}

.eyebrow {
  margin: 0 0 12px;
  color: #93c5fd;
  font-size: 0.78rem;
  font-weight: 800;
  letter-spacing: 0.16em;
}

h1 {
  margin: 0;
  font-size: clamp(2.5rem, 9vw, 5rem);
  line-height: 0.95;
}

How Does The Card Take Shape?

The launch-card rule limits the card width. It adds the rounded panel and its shadow.
The eyebrow rule turns the project label into a small blue heading.
The h1 rule scales the main greeting with the browser width.

Save styles.css.
Return to Safari.
Refresh the local page.

You should see a rounded dark card. The blue project label should sit above a large greeting.

Card Still Looks Like Plain Text?

Check that the HTML uses class="launch-card" and class="eyebrow" exactly. A spelling difference prevents the matching CSS rule from applying.

Help me match my card classes.

Append the introduction and status rules below the h1 rule by copying this code:

.intro {
  max-width: 42ch;
  margin: 20px 0 28px;
  color: #cbd5e1;
  font-size: 1.08rem;
  line-height: 1.6;
}

.status {
  display: inline-flex;
  align-items: center;
  gap: 10px;
  padding: 10px 14px;
  border-radius: 999px;
  color: #bbf7d0;
  background: rgba(22, 101, 52, 0.3);
  font-weight: 700;
}

.status-dot {
  width: 10px;
  height: 10px;
  border-radius: 50%;
  background: #4ade80;
  box-shadow: 0 0 16px #4ade80;
}

What Changes In The Middle?

The intro rule limits the paragraph width. It uses softer text colour for visual contrast.
The status rule creates the green rounded status badge.
The status-dot rule creates a glowing green circle inside the badge.

Save styles.css.
Return to Safari.
Refresh the local page.

You should see a muted introduction followed by a green status badge with a glowing dot.

Status Badge Missing Its Colour?

Confirm the badge uses class="status". Confirm the empty span uses class="status-dot".

Help me fix the status badge styling.

Append the facts and note rules below the status-dot rule by copying this code:

.facts {
  margin: 30px 0 0;
  padding: 0;
  list-style: none;
  border-top: 1px solid rgba(148, 163, 184, 0.25);
}

.facts li {
  display: flex;
  justify-content: space-between;
  gap: 20px;
  padding: 16px 0;
  border-bottom: 1px solid rgba(148, 163, 184, 0.25);
}

.facts span {
  color: #94a3b8;
}

.note {
  margin: 22px 0 0;
  color: #bfdbfe;
  font-weight: 700;
}

How Are The Facts Organised?

The facts rule removes the default list markers. It adds the top divider.
Each facts item places its label opposite its value. Thin borders separate the rows.
The facts labels use a muted colour. This keeps the bold values prominent.
The note rule defines the appearance of note content when the page includes it.

Save styles.css.
Return to Safari.
Refresh the local page.

You should see three divided fact rows. The final row should show Deployment opposite Version 1.

Facts Still Have Bullet Points?

Confirm the list uses class="facts". Check that the list-style declaration remains inside the matching rule.

Help me fix the facts list styling.

Append the responsive rules below the note rule by copying this code:

@media (max-width: 520px) {
  .launch-card {
    padding: 28px;
  }

  .facts li {
    align-items: flex-start;
    flex-direction: column;
    gap: 6px;
  }
}

What Makes The Card Responsive?

The media rule activates when the page width reaches 520px or less. It reduces card padding and stacks each facts row vertically.

Save styles.css.
Return to Safari.
Narrow the Safari window until the facts values move below their labels.

You should see the facts rows stack into a mobile-friendly layout. The card should remain inside the visible page width.

Facts Do Not Stack On A Narrow Window?

Confirm the media rule closes with its final brace. Check that .facts li matches the earlier facts-row selector.

Help me fix the responsive facts layout.

✔️ Awesome, I've got everything!

Your complete stylesheet is saved. Restore Safari to a comfortable width for the final check.

ⓧ I'd like to double check the full code

* {
  box-sizing: border-box;
}

:root {
  color-scheme: dark;
  font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

body {
  min-height: 100vh;
  margin: 0;
  display: grid;
  place-items: center;
  padding: 24px;
  color: #f8fafc;
  background: radial-gradient(circle at top, #1d4ed8 0%, #0f172a 55%, #020617 100%);
}

.launch-card {
  width: min(100%, 620px);
  padding: 40px;
  border: 1px solid rgba(148, 163, 184, 0.35);
  border-radius: 24px;
  background: rgba(15, 23, 42, 0.9);
  box-shadow: 0 24px 70px rgba(2, 6, 23, 0.55);
}

.eyebrow {
  margin: 0 0 12px;
  color: #93c5fd;
  font-size: 0.78rem;
  font-weight: 800;
  letter-spacing: 0.16em;
}

h1 {
  margin: 0;
  font-size: clamp(2.5rem, 9vw, 5rem);
  line-height: 0.95;
}

.intro {
  max-width: 42ch;
  margin: 20px 0 28px;
  color: #cbd5e1;
  font-size: 1.08rem;
  line-height: 1.6;
}

.status {
  display: inline-flex;
  align-items: center;
  gap: 10px;
  padding: 10px 14px;
  border-radius: 999px;
  color: #bbf7d0;
  background: rgba(22, 101, 52, 0.3);
  font-weight: 700;
}

.status-dot {
  width: 10px;
  height: 10px;
  border-radius: 50%;
  background: #4ade80;
  box-shadow: 0 0 16px #4ade80;
}

.facts {
  margin: 30px 0 0;
  padding: 0;
  list-style: none;
  border-top: 1px solid rgba(148, 163, 184, 0.25);
}

.facts li {
  display: flex;
  justify-content: space-between;
  gap: 20px;
  padding: 16px 0;
  border-bottom: 1px solid rgba(148, 163, 184, 0.25);
}

.facts span {
  color: #94a3b8;
}

.note {
  margin: 22px 0 0;
  color: #bfdbfe;
  font-weight: 700;
}

@media (max-width: 520px) {
  .launch-card {
    padding: 28px;
  }

  .facts li {
    align-items: flex-start;
    flex-direction: column;
    gap: 6px;
  }
}

How To Use This Reference

Compare this file with your saved styles.css. Keep every selector and closing brace in the same order.

Confirm the local result

Your finished card now runs directly from files on your Mac. The Safari address reveals whether the page has reached the cloud.

Before you check, do you expect the address to identify a local file or a public website?

Refresh the local page in Safari.
Confirm the facts list shows Version 1.
Inspect the address shown for the page.

You should see the complete styled card with Version 1. Safari should show a location beginning with file:// and no .pages.dev domain.

What Does The Address Prove?

The file:// location points to a file stored on your Mac. Your browser can display it because Safari can read that local file.

Other people cannot visit this Mac-only location as a public website. Publishing the folder creates the shareable address.

That is your first visible win. Your launch card works from local files and is ready for its first Cloudflare Pages deployment.

Deploy Version 1 to Cloudflare

Your Version 1 launch card already works from a file on your Mac. Its file:// address points Safari to your own drive.

A production deployment gives the card a public home. Cloudflare Pages uses Direct Upload to turn your saved folder into a published snapshot.

In this step, get ready to:

Create a Cloudflare Pages project named first-cloud-launch.
Upload the saved Version 1 website folder as the first production deployment.
Open the generated .pages.dev address in Safari.

Start a Direct Upload project

Direct Upload accepts the static files already stored on your Mac. Cloudflare Pages serves the uploaded snapshot from its global network.

Return to the Cloudflare dashboard from earlier.
Select Workers & Pages.
Select Create application.
Select Get started.
Select Drag and drop your files.

Why Direct Upload?

Repository-based publishing uses Git to move changes through a remote code history. That workflow introduces extra setup before the first deployment.

Direct Upload keeps this project focused on how local files become a public website. Your finished HTML and CSS can move straight to the cloud.

Upload the website folder

Publishing your first site can feel like a big step. This upload exposes only the two project files inside first-cloud-launch.

Enter first-cloud-launch as the project name.
Switch back to Finder from the previous step.
Drag the whole first-cloud-launch folder into Cloudflare's upload area.
Select Deploy site.
Drag the folder into the next upload frame if Cloudflare shows one.
Select Save and Deploy on that screen.

Cloudflare creates the first-cloud-launch Pages project. Its production environment now contains one deployment with your saved files.

Folder not uploading?

Confirm that you dragged the whole first-cloud-launch folder into the upload area. The folder should contain index.html plus styles.css at the same level.

If the project name is unavailable, keep the project name you entered. Cloudflare can add random characters to the generated address.

Help me resolve the folder upload problem.

Verify the public production page

The generated .pages.dev address is the public location for this production snapshot. Cloudflare may add random characters if the original address is unavailable.

Continue to the deployed project.
Locate the generated production address ending in .pages.dev.
Record the generated production address here: https://your-project.pages.dev.

Before you open the link, predict which deployment value the public card will show.

Select the generated production address to open it in Safari.

You should see the styled launch card with Version 1 as its deployment value. Safari's address bar should show a public .pages.dev location instead of a local file:// location.

That is your first cloud launch. The same card now loads from a public production URL.

Public page not loading correctly?

A 404 can appear when index.html is missing from the top level of the uploaded folder. Confirm that index.html sits directly beside styles.css.

If the card appears without styling, confirm that the deployed folder included styles.css.

Help me diagnose the public deployment.

Your public Version 1 snapshot is live. Next, you will change the local card to test whether the production snapshot follows.

Compare Local and Published Versions

Your Version 1 launch card is live through Cloudflare Pages. Its public URL gives anyone a way to open the card.

The local file and the production deployment currently show matching content. This step changes the local copy so you can test whether a save on your Mac also changes the published page.

In this step, get ready to:

Change the local card to Version 2.
Verify the update from the local file address.
Compare the production deployment with the local copy.

Update the local card to Version 2

Your index.html file holds the content Safari reads from the local file:// address. Two visible markers make the local and published copies easy to compare.

Switch back to the editor containing your first-cloud-launch folder.
Select index.html from the file list.
Find the <ul class="facts"> block.
Replace that entire block with the code below:

      <ul class="facts">
        <li><span>Built on</span><strong>macOS</strong></li>
        <li><span>Made with</span><strong>HTML + CSS</strong></li>
        <li><span>Deployment</span><strong>Version 2</strong></li>
      </ul>

      <p class="note">Updated after my first cloud deployment.</p>

What Does This Change Do?

The Version 2 value creates the first comparison marker.
The .note paragraph creates the second comparison marker.
The existing .note rule in styles.css gives the new message its blue styling.

Save index.html.
Switch back to the local file:// tab in Safari.
Refresh the local tab using Safari's reload control.

You should see Version 2 in the Deployment row. You should also see Updated after my first cloud deployment. beneath the facts list.

Still Seeing Version 1 Locally?

Confirm that the open file belongs to the local first-cloud-launch folder.
Check that the Deployment row contains Version 2.
Check that the .note paragraph sits below the closing </ul> tag.

Help me find why my local launch card still shows Version 1 after editing index.html.

✔️ Awesome, I've got everything!

Good work. Your local index.html now contains both comparison markers.

ⓧ I'd like to double check the full code

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>My Cloud Launch</title>
    <link rel="stylesheet" href="styles.css" />
  </head>
  <body>
    <main class="launch-card">
      <p class="eyebrow">MY FIRST CLOUD PROJECT</p>
      <h1>Hello, cloud.</h1>
      <p class="intro">
        I'm learning how local files become a public website.
      </p>

      <div class="status">
        <span class="status-dot" aria-hidden="true"></span>
        <span>Live on Cloudflare Pages</span>
      </div>

      <ul class="facts">
        <li><span>Built on</span><strong>macOS</strong></li>
        <li><span>Made with</span><strong>HTML + CSS</strong></li>
        <li><span>Deployment</span><strong>Version 2</strong></li>
      </ul>

      <p class="note">Updated after my first cloud deployment.</p>
    </main>
  </body>
</html>

Test the published snapshot

The public tab points to the files Cloudflare Pages received during your earlier upload. This comparison uses that existing deployment without adding new files.

Leave the Cloudflare dashboard unchanged during this comparison.

Before you refresh the public tab, predict whether the edit saved on your Mac will appear at the public address.

Switch to the public .pages.dev tab in Safari.
Refresh the public tab using Safari's reload control.

You will still see Version 1 in the Deployment row. The update note is absent.

Return to the local file:// tab.
Confirm that the local Deployment row shows Version 2.
Confirm that the local update note is visible.
Return to the public .pages.dev tab.
Confirm that the public Deployment row still shows Version 1.
Confirm that the public update note is absent.

You have caught the deployment boundary in action. Your local file is now Version 2. The published snapshot remains Version 1.

The stale production copy is now proven. Next, you will publish the updated folder so the public site matches your local card.

Publish Version 2 to Production

Your local card now shows Version 2. The public site still serves Version 1 because the earlier deployment is a fixed snapshot.

A new production deployment sends your saved folder to Cloudflare Pages. This updates the existing public URL without changing its address.

In this step, get ready to:

Start a new production deployment in the existing Pages project.
Upload the updated folder as the current production snapshot.
Verify the public page matches the local launch card.

Prepare the production deployment

The Version 1 deployment remains active until you publish another snapshot. Your existing Pages project provides the path for replacing the public version.

Return to the first-cloud-launch Cloudflare Pages project from earlier.
Select Create a new deployment.
Choose the production environment.

Why use another production deployment?

Each deployment captures the files you upload at that moment. A second production deployment replaces the public snapshot while preserving the earlier deployment in project history.

Publish the updated folder

A Direct Upload deployment reads the saved files inside your folder. Uploading the whole folder keeps index.html beside styles.css.

Drag the updated first-cloud-launch folder into the upload area.
Confirm the upload includes index.html at the top level.
Confirm the upload includes styles.css at the top level.
Select the deploy action shown below the upload area.
Wait for the production deployment to complete.

The completed deployment becomes the current production snapshot. The project now contains two production deployments.

What did this deployment change?

This second production deployment publishes the saved Version 2 files as the current website.

The earlier Version 1 deployment remains available in the project's deployment history.

Upload not completing?

Drag the first-cloud-launch folder itself into the upload area.
Confirm index.html appears at the top level of the upload.
Wait for the folder upload to finish before selecting the deploy action.

Help me troubleshoot why my Cloudflare Pages Direct Upload is not completing.

Confirm production matches local

The project address stays the same when a new production snapshot becomes current. Before you refresh, ask yourself which version you expect the production URL to serve.

Switch back to the public .pages.dev Safari tab from earlier.
Refresh the public page.

You should now see Version 2 in the Deployment row. You should also see Updated after my first cloud deployment.

Switch back to the local file:// Safari tab.
Compare the Deployment row across both tabs.
Compare the update note across both tabs.

Both pages should show the same Version 2 content. This confirms that the new production snapshot matches your saved local files.

Return to the Cloudflare Pages project from earlier.
Check the project's deployment list for two production deployments.

The latest deployment serves Version 2. The earlier Version 1 deployment remains in the project history.

That closes the stale-copy gap. Your public URL now serves the same Version 2 card as your Mac.

Secret mission

Test a Preview Deployment

Add a next-learning section to your launch card. Publish it at a preview URL while Version 2 stays unchanged in production.

Clean Up Your Resources

Decide whether to keep your resources running, pause your work, or delete everything. The free Cloudflare Pages path needs no payment card because paid products and custom domains are outside this project.

Resources you used:

A local first-cloud-launch folder containing index.html and styles.css.
A Cloudflare Pages Direct Upload project named first-cloud-launch with two production deployments.
One preview deployment for the next-step-preview preview environment.

Keep everything running

No action is needed. Choose this if you want to keep comparing the production site with your experimental preview.

Keep the first-cloud-launch folder for future edits.
Leave the Cloudflare Pages project deployed so the production site remains public.
Keep the recorded production and preview URLs for future comparisons.

Pause - I'll come back to this later

This option leaves both deployed versions online while your work is paused. Direct Upload has no required background process on your Mac.

Stop uploading new versions to the Cloudflare Pages project.
Leave the existing production and preview deployments online.
Keep the local first-cloud-launch folder for your next editing session.

Delete - I don't want to use this again

Remove all project resources to start fresh. Choose this option when you no longer need the public sites or local files.

Deletion Is Permanent

These actions remove the Cloudflare Pages project and the local folder. Rebuilding them later means repeating the uploads.

Delete the Cloudflare Pages project:

Return to the Cloudflare dashboard from earlier.
Select Workers & Pages.
Select the Pages project named first-cloud-launch.
Select Settings.
Select Delete project.
Confirm the deletion when Cloudflare asks.
Return to Workers & Pages to check the result.

The first-cloud-launch project should no longer appear. This confirms its production and preview deployments are gone.

Delete the local project folder:

Use Finder to search for first-cloud-launch.
Select the first-cloud-launch folder in the search results.
Drag the selected folder to the Trash in the Dock.
Return to the Finder location that held the project folder.

The first-cloud-launch folder should no longer appear in its original location. Your local project copy is now removed.

Nice Work!

That is your first cloud launch complete. Your Version 2 launch card is live on Cloudflare Pages at a public address.

You've learned how to:

Build a responsive launch card with HTML and CSS that opens from the local first-cloud-launch folder.
Prove that local files and a public cloud URL can serve separate versions of the same website.
Publish a new production deployment that moves the public site from Version 1 to Version 2.
Secret Mission: Publish an experimental change to a preview URL while keeping production unchanged.

You now have a complete workflow for moving a static website from your Mac to a public URL.

Ready to quiz yourself?