Quickieweb

A publishing platform that costs nothing when nobody is reading.

Pages are rendered once, when you save them, and served as files from object storage behind a CDN. There is no server on the read path, no database, and no runtime for anyone to exploit. A page costs the same whether one person reads it or a hundred thousand do. The editor is a Lambda that wakes when you open it and goes back to sleep when you close the tab.

Two ways to use it:

• Run it yourself. This repository, pointed at your own AWS account. Your buckets, your CDN, your domain, your bill — which for a small site rounds to the price of a coffee a year. Instructions below.
• quickieweb.com — the hosted version. We run the infrastructure, you get a subdomain, and the template library lives with us.

Same codebase. The difference is one field on a site record, which is deliberate: the moment the self-hosted version becomes a demo of the hosted one, it stops being worth running.

---

What you get

• Static sites — real HTML, readable with JavaScript off, indexable, shareable. Feeds included; podcast feeds when a post has audio.
• A template system where templates are data, not code. Nothing in a template executes. A validator checks every field reference before publication, so a typo is an error with a line number rather than a blank space on a page.
• Point-and-click customization — colours, fonts, logos. The form is generated from whatever the template declares, so a new template gets one for free.
• Static pages alongside dated posts. An About page can put itself in the masthead without editing config.
• Photo galleries as a post type. Drop images into the editor and they come out as a responsive grid with a lightbox — keyboard, swipe, captions — that the platform supplies, so no template has to ship JavaScript to get one.
• Client-side search over full body text. The index is fetched on the first interaction with the search box and never on page load, so a reader who does not search pays nothing for the feature existing.
• Web analytics from CloudFront access logs — visits, referrers, bots, city-level geography — with no tracking script anywhere on the public site.
• Many sites from one installation, each with its own members, and each person seeing only the sites they belong to.

Not built: comments, search-as-you-type against a server, or anything else that needs to think while a reader waits. If your site needs to run code for every visitor, this is the wrong tool.

---

Running it in your own AWS account

You need Node 18+, the AWS CLI, curl, a domain in Route 53 (or one you can repoint there), and an AWS account. Everything is a script; there is no IaC tool to learn.

1. Get the code

git clone https://github.com/bissellator/quickieweb.git
cd quickieweb
cp config.example.json config.json
npm run fetch-editor

config.json is gitignored — it will hold your bucket names, distribution ids and certificate ARN, and publishing that hands a stranger a map of your infrastructure. fetch-editor vendors CKEditor into admin/ui/; it is not committed because this project is Apache-2.0 and CKEditor is GPL. See NOTICE.

Fill in config.json. Every script refuses to run against a REPLACE-ME.

2. Make a scoped deploy user

node infra/create-deploy-user.mjs --admin-profile <your-admin-profile>
export AWS_PROFILE=quickieweb

This is not optional politeness. A deploy script running on a root or full-admin key means "the script had a bug" and "the key leaked" both resolve to total account compromise. The policy in infra/iam/deploy-user-policy.json scopes the new key to your quickieweb-* buckets, qw-* functions and qw-* roles, and the secret is written straight into ~/.aws/credentials without ever being printed. Its residual weakness is documented at the top of the script rather than glossed over.

3. Provision

node infra/provision-platform.mjs    # template library + account registry
node infra/provision.mjs             # buckets, certificate, distribution, DNS, OAC

4. Create a Google OAuth client

The one step that cannot be scripted — it lives in the Google Cloud console. A personal Google account is fine; you do not need Workspace or a billing account.

1. https://console.cloud.google.com/apis/credentials → Create credentials → OAuth client ID → Web application
2. Authorized JavaScript origins: the hostname your console will be served from. Wildcards are not accepted, so use one host.
3. Leave redirect URIs empty — Google Identity Services posts the credential back to the page.
4. Add yourself as a test user on the consent screen. A new External app starts in Testing, where only listed users can sign in; everyone else sees "access blocked" and it looks like your install is broken.

Quickieweb asks only for openid email profile, so publishing the app to production needs no verification review.

5. Deploy

node infra/deploy-lambda.mjs --client-id <id>.apps.googleusercontent.com
node infra/wire-cloudfront.mjs
node infra/deploy-admin-ui.mjs
node infra/seed-platform-admin.mjs --email [email protected]   # makes you staff
node infra/enable-logging.mjs                                # access logs, for stats
node infra/fetch-geodb.mjs                                   # IP-to-city, monthly

Then sign in and create your first site.

Publishing from a checkout

The console is not the only way in. You can author locally and push:

node cli/build.mjs                # content/*.json -> site/
node cli/deploy.mjs --dry-run
node cli/deploy.mjs

deploy.mjs never deletes. The repository and the console are two authors of the same bucket and only one of them writes back, so a mirroring sync would take down posts written in the console. Pruning is opt-in behind --prune, and --dry-run --prune shows you what it would take first.

---

This is the beginning of the README. Read the rest at the original. Read the full README ↗