How to Deploy to Cloudflare Pages Without GitHub Actions (Git Integration vs. Direct Upload)

It was supposed to be one link

Short answer: you don't need GitHub Actions to publish a Cloudflare Pages site. If your Pages project is connected to GitHub, Cloudflare builds and deploys on every push by itself. If it's a Direct Upload project, you build the whole site and upload the output with Wrangler. Here's how I learned that the hard way.

The job was tiny. To get through an affiliate program's site review, I needed one product link to an external hard drive in a real article. Above the link went a clear note: "This page contains affiliate links, and the site owner may earn a commission if you buy something." I made the link, added it to the article and committed it to GitHub.

Done, I thought.

Then a basic mix-up came to light.

Code sitting on GitHub is not the same as a page that's live on the web.

The GitHub Actions setup I normally used wasn't available. Someone suggested catching just that one URL with a Cloudflare Worker and serving it from there. That route wasn't available under our current setup either.

All I wanted was one link, and suddenly I was in a deployment meeting: "What about CI? Workers? Is Pages connected to Git, or is it Direct Upload?"

That's how you accidentally break ground on Affiliate Sagrada Família, Building No. 2.

Once you pull the pieces apart, though, the problem gets a lot simpler.

---

1. Why did the affiliate link have to be live first?

Sovrn Commerce tells content and blog publishers to add Commerce links to their site and generate some clicks first. Only then does the campaign go to review.[3]

So it isn't "get approved, then add links." The reviewer has to be able to see a real, working example first.

Sovrn also asks you to tell readers clearly, on every page with affiliate links, that you may earn money from them. The note should show up before the link or the promotion.[4]

You don't need a fancy product-comparison site for this. The checklist is short:

• a real article exists on the site you applied with;
• that article has the affiliate link;
• the disclosure note comes before the link;
• anyone can open the page from its public URL;
• after it's live, you can generate a few test clicks.

The second-to-last point is the one that matters here: a file in a GitHub repo is not a public page yet.

---

2. GitHub Actions being down doesn't mean Cloudflare Pages is down

GitHub Actions is GitHub's built-in automation (CI/CD). It runs builds, tests and deployments on GitHub's side.

Cloudflare Pages has its own separate Git integration. You connect a Pages project straight to GitHub or GitLab, and whenever you push to that repo, Cloudflare runs the build and the deploy itself.[1]

So the chain looks like this:

push to GitHub → Cloudflare Pages spots the commit → Cloudflare builds → Cloudflare deploys

No GitHub Actions workflow anywhere in that chain.

That's the key point. "We can't use GitHub Actions" is not the same as "GitHub can't publish to Cloudflare." They're two different systems.

Think of GitHub Actions as a conveyor belt inside your own warehouse. Cloudflare's Git integration is a courier that drives over and picks up the package itself.

The belt can be stopped while the courier still shows up.

---

3. First, find out what kind of Pages project you already have

Skip this step and Cloudflare Pages turns into a maze fast.

There are two main ways a Pages project gets published:

Type	What starts it	Who builds and deploys	Good for
Git integration	a push to GitHub / GitLab	Cloudflare	the repo is your source of truth and you want automatic deploys
Direct Upload	files you already built	Wrangler or the dashboard	you build on your own machine or in another CI and upload the result

Cloudflare's docs spell out a catch: a project created with Git integration can't be switched to a normal Direct Upload project later. You can still push a manual deploy to a Git-connected project with Wrangler, but the dashboard's drag-and-drop upload doesn't work for it.[1][2]

It works the other way too. A project that started as Direct Upload can't get Git integration added later. If you want automatic Git deploys, you need a new Pages project.[2]

So the first question isn't "how do I deploy this?"

It's this: "Is my current Pages project Git integration or Direct Upload?"

Answer that and half your options disappear.

---

4. If it's Git integration, you don't need to bring GitHub Actions back

If your GitHub repo is already properly connected to Cloudflare Pages, the shortest path isn't a Worker or a new CI service.

Check these in your Pages project:

1. it's connected to the right GitHub repo;
2. the production branch is the branch you actually want to publish;
3. automatic builds for the production branch aren't paused;
4. the build command and output folder match your current project;
5. after a push, a new deployment shows up on the Pages Deployments screen;
6. the new content shows up on your pages.dev address;
7. finally, your custom domain shows the same new content.

Cloudflare's Git integration builds and deploys from the commits on the connected branch.[1]

So even if GitHub Actions is out for a while, your publishing line keeps running as long as Cloudflare's own build works.

The job here isn't to bolt on another complicated system. It's to check whether Cloudflare's pickup door is already open.

---

5. If it's Direct Upload, upload the whole build, not one page

Direct Upload means you hand Cloudflare Pages a finished set of static files. The docs describe uploading prebuilt files with Wrangler or through the dashboard.[2]

Here's the risky shortcut that comes to mind:

"I only changed one article. Can't I just upload that one HTML file?"

If your static site is built as a whole, try not to.

What you deploy isn't "the one file that changed in Git." It's the complete build output of your site at that moment. A build often regenerates page lists, CSS, JavaScript, search indexes, images and routing too. Slip in one hand-made page and your live site stops matching your repo.

With Direct Upload, the basic flow is:

get the latest code → run the project's build command → check the output folder → deploy the whole output → check the live URL

On a Node-based static site, for example, you'd run the project's own build command, like pnpm build, and upload the folder it creates, such as dist.

The point is to keep production from turning into a mystery copy that someone edited by hand.

---

6. If you can't use a Worker, just drop it

If you need one page live in a hurry, catching that one path with a Worker route can work in principle.

But when Workers aren't allowed in your setup, as here, there's no point building your plan around one.

Every "maybe we can use it" route you leave on the whiteboard makes running things harder.

• GitHub Actions: not available
• Workers: not available
• So pick one: Cloudflare Pages Git integration or Direct Upload

That's it.

Finding the one front door that's open beats building ten emergency exits.

Don't build a second deployment system just to publish one affiliate link.

That was the biggest lesson of the whole thing.

---

7. "Published" means you saw it on the live page, not that you have a commit hash

A classic mistake in running a website is calling a halfway step "done."

• you wrote the code
• you committed it to GitHub
• the build passed
• a deployment appeared on Cloudflare

All of these matter, but readers only ever see the final URL.

For an affiliate review page like this, the last check looks like this:

1. the public URL opens in a private or incognito window;
2. the latest version of the article shows up;
3. the affiliate disclosure appears before the link;
4. the product link goes where it should;
5. the page looks fine on a phone;
6. if needed, you generate a few test clicks;
7. you check click tracking and review status in your Sovrn account.

Sovrn describes the content and blog campaign flow as: add the links, generate clicks, then review.[3]

So "it's on GitHub, now we wait for review" is wrong. You're only at the starting line once the reviewer can see it working on the live URL.

---

8. Later on, don't hard-code affiliate URLs into your articles

One link added by hand is fine.

But once you have hundreds or thousands of articles, having a person decide every time "Does this article get ads? Where? Which product? Which country?" means a whole ad factory grows next to your content factory.

The next step is to keep the article text and the money-making details separate.

For example, each article just carries a small settings block like this:

article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage

Then, at publish time, things flow like this:

article → monetization check → product picks → affiliate link creation → inserted by the page renderer → performance tracking

The article stays a long-term asset. Product URLs, stock, stores and country-by-country routing become parts you can swap out.

That way you don't have to dig through the article text in all 12 languages every time a link breaks or a product changes.

An affiliate link isn't the article itself.

Treat it like sales plumbing you hook up to the article later. That holds up much better over time.

---

9. Bottom line: when CI breaks, find Cloudflare's real entrance before building another castle

The whole story says a lot.

It started with: "Let's add one hard drive link for the review."

I made the link. I wrote the disclosure. It went into GitHub.

But when it came time to go live, GitHub Actions was off the table. Trying to sneak around it with a Worker didn't work either.

Add yet another system at that point and the goal quietly shifts from "publish one link" to "build a whole deployment platform."

In the end, you only need these calls:

• if your Pages project uses Git integration, let Cloudflare's own build do the work;
• if it's Direct Upload, build the whole site and deploy the proper output;
• if you can't use Workers, cross them off;
• never call a GitHub commit "published";
• check the disclosure, the link, the layout and the clicks on the real public URL.

The riskiest setup isn't one with too few options.

It's one where options you can't use stay on the plan forever.

The answer to this deployment maze turned out to be pretty boring.

First, look at how your Cloudflare Pages project is set up.

That was all it took.

---