# Your Website Does Not Need a Subscription

**Publishing a small organization's site on a Worker and a domain**

Point Arena Cyber Security
Version 1.0

---

## Summary

If your organization's website is mostly words, pictures, hours and a phone
number, you are probably paying a monthly subscription for something you could
run for the cost of a domain name.

This guide shows how to put a real website on your own domain using one HTML
file and a Cloudflare Worker. It takes about twenty minutes. There is no
subdomain with someone else's brand in it, no ads on your page, and no monthly
bill.

It also says clearly where this is the wrong choice, because it often is.

A ready-to-edit starter page is published alongside this guide at
`templates/starter-site.html`. It is CC0, public domain, no conditions. You can
use it, change it, and remove every trace of us from it.

---

## 1. Who this is for

**A good fit if your site is:**

- Who we are, what we do, where we are, when we are open
- A contact phone number and email
- A few pages of information that change a handful of times a year
- Documents, reports, meeting minutes, a newsletter archive

That describes the majority of small nonprofit, school, church, clinic and
community organization websites.

**A bad fit if you need:**

- Online payments, a shop, ticketing
- Appointment booking or class registration
- A volunteer with no technical background updating content weekly
- User logins, member areas, anything private
- A blog with dozens of posts a year

Some of those can be added. Most are the reason website builders exist, and
paying for one is a reasonable decision. This guide is not an argument that
platforms are bad. It is an argument that many organizations are paying for a
platform to serve a page of opening hours.

---

## 2. What you are currently paying for

As of late 2026, Wix's entry paid tier runs about seventeen dollars a month on
annual billing and about twenty-four billed monthly, with a custom domain only
becoming available at that tier. Squarespace starts near sixteen. WordPress.org
is free software, but you pay for hosting, and realistically for a theme, a few
plugins, and eventually someone to fix it.

The free tiers are what push people to pay. A free Wix site lives on a
`wixsite.com` subdomain and carries Wix's own ad on your page. For a community
organization asking for donations, an ad you did not choose sitting above your
appeal is a real cost, not a cosmetic one.

Call it two hundred dollars a year at the entry tier. That is not a catastrophe.
It is also a week of groceries for a family your food program serves, and it is
recurring forever.

**What you get for it:** a visual editor, hosting, templates, forms, and
somebody else's responsibility when it breaks. Those are genuine. The visual
editor in particular is worth real money if the person updating the site cannot
edit HTML.

**What you also get:** your content in a format you cannot straightforwardly
take with you. This is the part organizations discover at renewal time.

---

## 3. What you will pay instead

| Item | Cost |
|---|---|
| Domain name | Roughly $10 to $15 a year |
| Cloudflare account | Free |
| Worker hosting at small-org traffic | Free tier |
| TLS certificate | Included |
| **Total** | **The domain, and nothing else** |

Cloudflare's free Workers tier covers a daily request allowance far above what a
small organization's site generates. A local nonprofit getting a few hundred
visitors a day is not close to it.

---

## 4. The security argument

We are a security organization, so this section is the one we care most about.

A WordPress site is an application. It has an administrator login, a database,
a PHP runtime, a theme, and typically somewhere between five and thirty plugins,
each written by a different person, each with its own update schedule and its
own vulnerability history. WordPress powers a very large share of the web,
which makes it the single most attacked application on it. The overwhelming
majority of WordPress compromises come through outdated plugins rather than
WordPress itself.

The practical result for a small organization is a website that requires
ongoing attention from someone who understands what a plugin update might break,
and which does not get that attention, and which is eventually found by an
automated scanner.

**A static page has no admin login to brute force, no database to inject into,
no plugins to fall behind, and no PHP to execute.** There is nothing to patch
because there is nothing running. An automated scanner sweeping for WordPress
paths finds nothing, because nothing is there.

Hosted builders like Wix and Squarespace are meaningfully better than
self-hosted WordPress on this point, because the platform handles patching. The
tradeoff you accept there is different: you are trusting a company with your
content and your availability, and you have no ability to inspect or move
quickly if something goes wrong.

Being honest about the residual risk on the static approach: whoever controls
your Cloudflare account controls your website. Put multi-factor authentication
on it, ideally a hardware key. That is the whole of your security maintenance
burden, and it is a one-time task.

---

## 5. Doing it

Twenty minutes, start to finish. You need a credit card for the domain and
nothing else.

### Step 1. Get a domain

Register through any registrar. Cloudflare's own registrar sells at cost with
no markup and no first-year-discount-then-renewal-spike pattern, which makes it
a reasonable default if you are starting fresh. If you already own a domain,
you can move its DNS to Cloudflare without transferring the registration.

Do not skip to a subdomain of someone else's site. Owning the name is the entire
point, and it is the part you cannot retrofit later without losing your search
ranking and every printed business card.

### Step 2. Write your page

Download `templates/starter-site.html` from this site. Open it in Notepad,
TextEdit, or any text editor. Do not use Word.

Search the file for `EDIT`. There are fifteen of them, each with a comment
explaining what to change. Work top to bottom. Change the colors by editing the
five lines at the top of the style block.

Save it. Open it by double-clicking. That is your website, running on your own
computer, before you have paid anyone anything.

### Step 3. Create the Worker

In the Cloudflare dashboard: **Workers & Pages** → **Create** → the **Workers**
tab → **Start with Hello World!** Give it a name and deploy.

Then **Edit code**. You will see a small JavaScript file. Replace all of it
with this, pasting your finished HTML where marked:

```js
const PAGE = `
PASTE YOUR HTML HERE
`;

export default {
  fetch() {
    return new Response(PAGE, {
      headers: { 'content-type': 'text/html; charset=utf-8' }
    });
  }
};
```

Deploy.

**One thing that will bite you.** The backtick characters around `PAGE` mark
where your HTML starts and ends. If your HTML contains a backtick, or the two
characters `${` together, the page will break. Plain text and normal HTML do
not contain either. If you paste in something copied from elsewhere and the
deploy fails, that is why.

### Step 4. Point your domain at it

On the Worker's page: **Settings** → **Domains & Routes** → **Add** → **Custom
domain** → type your domain.

Cloudflare creates the DNS record and issues the TLS certificate. Wait a minute,
then load your domain.

That is the whole thing. You are live, on your own name, over HTTPS.

### Step 5. Updating it later

Edit code, change the HTML, deploy. Changes are live in seconds.

Cloudflare keeps previous versions, so a bad edit is recoverable from the
**Deployments** tab.

---

## 6. Adding more pages

Beyond one page, check the URL and return different HTML:

```js
const HOME = `...`;
const ABOUT = `...`;

export default {
  fetch(request) {
    const path = new URL(request.url).pathname;
    const body = path === '/about' ? ABOUT : HOME;
    return new Response(body, {
      headers: { 'content-type': 'text/html; charset=utf-8' }
    });
  }
};
```

This stays comfortable up to perhaps five or six pages. Past that, put the files
in an R2 bucket and serve from there instead, which is the approach documented
in our companion paper *Publishing Without a Platform*.

---

## 7. The honest hard part: forms

This is where "just use a static page" gets glib, so here it is straight.

A static page cannot process a contact form. Something has to receive the
submission, and that something is a server. You have three real options.

**Use `mailto:` and a phone number.** Not a form. A clickable email address and
a clickable phone number. For most small organizations this is genuinely
sufficient, and it has the advantage of working forever with no dependency. The
starter template does this.

**Use a form service.** Formspree, Basin and similar accept a form post and
email you the result, with free tiers adequate for low volume. You are adding a
third-party dependency and their JavaScript, so read their privacy policy before
putting it on a page where people disclose need.

**Write a handler in the Worker.** Accept a POST and send mail through an email
API. Perhaps thirty lines. But you have now introduced a write path, which means
you need spam protection, rate limiting and input validation, and you have
reintroduced most of the attack surface section 4 was about removing. Do this
only if you will maintain it.

If you need a form badly enough that none of these work, a hosted builder is
the right answer and you should use one without guilt.

---

## 8. What you give up

Stated plainly.

**The visual editor.** This is the real one. If the person who updates your site
cannot comfortably edit an HTML file, this approach will fail, not technically
but organizationally. The site will go stale because updating it requires the
one volunteer who moved away.

Be honest about who maintains it before you choose. A subscription that keeps
your hours accurate beats free hosting that shows last year's.

**Built-in features.** No galleries, no booking, no newsletter signup, no
analytics dashboard, no e-commerce. Each is addable and each is work.

**Somebody to call.** Nobody is on the hook when it breaks. In practice a static
page breaks approximately never, but when you need a change at 9pm before a
grant deadline, there is no support line.

**Templates.** You get one starter page from us. A builder gives you hundreds of
professionally designed options, and design matters for credibility when you are
asking people for money.

---

## 9. When to pay for a platform instead

Do not take the cheap option if any of these are true:

- You sell things or take payments on the site
- You need bookings, registrations or scheduling
- Content changes weekly and non-technical staff make the changes
- You need member logins or anything private
- Nobody in your organization is comfortable editing a text file
- Design quality matters more to your fundraising than two hundred dollars a
  year does

Any one of those and a subscription is money well spent. The waste is paying a
platform rent for a page of opening hours that changes twice a year.

---

## 10. Why we published this

Our organization exists because security knowledge sits behind paywalls that do
not need to exist. The same pattern shows up one layer down, in basic web
publishing, and it hits the same organizations hardest: the food bank, the
volunteer fire department, the after-school program.

The technique in this guide is not clever. Any web developer knows it. That is
exactly the problem. It is not written down anywhere the person running a
community center would find it, so they pay a subscription instead, and nobody
in a position to tell them otherwise has any reason to.

So here it is written down. The template is public domain. Take it.

---

## Licensing

Copyright (C) 2026 Point Arena Cyber Security.

This guide is licensed under the Creative Commons Attribution-ShareAlike 4.0
International License.
https://creativecommons.org/licenses/by-sa/4.0/

SPDX-License-Identifier: CC-BY-SA-4.0

**The starter template is not.** `templates/starter-site.html` is released
under CC0 1.0, public domain. A starting point for your work must not impose
conditions on your work. Use it with no attribution and no share-alike
obligation.

Corrections: hello@pointarenacybersecurity.dev