Self Hosted Funnel Launch

# Self-Hosted Funnel Launch

Take a funnel from nothing to published on infrastructure the operator controls, using [Autonnel](https://github.com/autonnel/autonnel) (Apache-2.0). This skill is the build step; design the funnel first with `sales-funnel-blueprint`, and confirm self-hosting is the right call with `funnel-platform-picker` if that is still open.

## Step 1: choose how it runs

| Path | Cost at low volume | Ops burden | Use it for | |---|---|---|---| | **Cloudflare Workers** | Effectively $0 plus a Postgres | No servers, no patching | **Default for production.** Funnel pages are mostly static assets, which Workers serves free and unmetered | | Docker | Cost of one VPS or container host | Yours: upgrades, backups, uptime | Local evaluation in two minutes, or a server you already run and want the data on | | Source checkout (Node) | Cost of one VPS or container host | Yours | Modifying Autonnel itself, or running the Node build directly |

Recommend Workers unless the operator has a specific reason not to: the pricing model fits funnels almost exactly, and it removes the entire class of work that makes people avoid self-hosting.

Use Docker for the first look regardless. It is the fastest way to see the product, and nothing you build locally is wasted: the same schema and the same admin UI back both paths.

## Step 2a: Cloudflare Workers (the near-free production path)

### Why the cost is close to zero

Funnel traffic is overwhelmingly requests for pages, images and scripts. On Workers those are static asset requests, which are **free and unlimited, with no storage cost** - only requests that invoke the Worker (server-rendered pages, checkout, API) are billed. A funnel's dynamic surface is small: the order form, the upsell accept, the postback queue.

Verified Cloudflare free-plan limits (checked 2026-08; confirm current numbers before you rely on them):

| Resource | Workers Free plan | |---|---| | Static asset requests | Free and unlimited, no storage charge | | Worker invocations | 100,000 requests/day | | Hyperdrive (Postgres pooling) | Available on Free, 100,000 database queries/day | | Workers KV (page cache) | 100,000 reads/day, **1,000 writes/day**, 1 GB storage | | Cron Triggers | Supported (the repo ships a `scheduled` handler) |

**What is not free**: Postgres. Hyperdrive pools connections to a database you supply, so you still need a Postgres provider. Managed providers have their own free tiers with their own limits, and that is the one line item to plan for.

**The first ceiling you will actually hit is KV writes, not requests.** 1,000 writes/day is generous for serving pages and thin for publishing them, because publishing invalidates and refreshes cached entries. A day of heavy editing can burn it while traffic is nowhere near any limit. If publishing starts failing before traffic does, that is this limit, not a bug.

### Deploy

The repository ships the whole Workers toolchain: worker entry with the cron `scheduled` handler (`src/cf-worker.ts`), `wrangler.toml` generation, KV cache wiring and Hyperdrive for Postgres.

```bash npx wrangler login npx wrangler kv namespace create CACHE_KV # $DATABASE_URL is the operator's own Postgres connection string, exported in their # shell - do not write the credentials into this command or into wrangler.toml. npx wrangler hyperdrive create autonnel-db --connection-string="$DATABASE_URL" ```

Each command prints an id. Put them in `.env` next to the project:

```bash CF_WORKER_NAME=my-funnels CF_KV_NAMESPACE_ID=<id from kv namespace create> CF_HYPERDRIVE_CONFIG_ID=<id from hyperdrive create> ```

Then set the secrets and deploy:

```bash npx wrangler secret put DATABASE_URL npx wrangler secret put AUTH_SESSION_SECRET # openssl rand -hex 32 npx wrangler secret put CREDENTIALS_ENCRYPTION_KEY # openssl rand -base64 32 npm run deploy:cf ```

`deploy:cf` builds and generates `wrangler.toml` from the template first, so there is no separate generate step. Cron expressions are read from the app's cron registry rather than hand-written into the config - do not edit the generated `wrangler.toml` by hand, it is overwritten on every build.

If a `CF_*` variable is missing, generation fails and names the variable. That is the intended behaviour; there are no silent defaults for these.

Apply the database schema once against the same Postgres before the first visit, then open the Worker URL and complete the `/setup` wizard to create the admin account.

Also available: `npm run dev:cf` (dev server on the Workers runtime) and `npm run preview:cf` (local preview via `wrangler dev`). Prefer these over plain `astro dev` when the target is Workers, because the runtime differs.

### Operating it afterwards

The CLI commands below need database access, not a container. From a checkout with `DATABASE_URL` pointing at the same Postgres:

```bash npx autonnel admin:create you@example.com 'a-strong-password' npx autonnel password:reset you@example.com ``