Self Hosted Funnel Launch

Self-Hosted Funnel Launch

Take a funnel from nothing to published on infrastructure the operator controls, using 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

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):

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.

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:

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:

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:

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

Step 2b: Docker (local evaluation, or your own server)

Get the repository from <https://github.com/autonnel/autonnel> (Apache-2.0), check out a release tag, and read its docker-compose.yml - it declares the images and ports that will run. From that checkout:

docker compose up

Open <http://localhost:4321> and complete /setup. The compose file starts Postgres, applies the schema, and runs the app. Nothing else is needed to boot: store, payments, media storage, email and AI are configured later in the admin UI, and only for the features actually used.

Before exposing it on a public host, put real secrets in a .env next to docker-compose.yml - the shipped defaults are insecure development values, and they exist only so the first local run needs zero configuration:

AUTH_SESSION_SECRET=$(openssl rand -hex 32)
CREDENTIALS_ENCRYPTION_KEY=$(openssl rand -base64 32)
ADMIN_DOMAIN=admin.example.com

Generate each value once and keep it stable. Rotating AUTH_SESSION_SECRET invalidates sessions; rotating CREDENTIALS_ENCRYPTION_KEY makes stored provider credentials unreadable, which means re-entering every payment and platform credential.

Multi-arch images are published to GHCR for a plain docker run against an existing database:

# DATABASE_URL, AUTH_SESSION_SECRET and CREDENTIALS_ENCRYPTION_KEY come from the
# operator's own environment - never write their values into a command or a file.
docker run -p 4321:4321 \
  -e DATABASE_URL \
  -e AUTH_SESSION_SECRET \
  -e CREDENTIALS_ENCRYPTION_KEY \
  -e ADMIN_DOMAIN="admin.example.com" \
  ghcr.io/autonnel/autonnel:v1.5.0

Keep an exact tag pinned rather than :latest, and re-apply the schema after pulling a newer tag - the compose file's one-shot schema service re-runs on every docker compose up. Health endpoint for orchestrators: /api/health (covers database and cache connectivity).

Admin CLI inside a container:

docker compose exec app node dist/cli/index.js admin:create you@example.com 'a-strong-password'

Step 2c: source checkout (Node)

For modifying Autonnel itself, or running the Node build on a host you already own. Requires Node 22+ and a Postgres:

npm create autonnel@latest my-funnel
cd my-funnel
cp .env.example .env   # set DATABASE_URL and ADMIN_DOMAIN
pnpm install           # pnpm 10+; the repo pins overrides npm would ignore
npm run db:push
npm run dev            # or: npm run build && npm run start

This clones the repository and drops its git history. The schema lives at prisma/schema.prisma in the checkout; db:push syncs it. Admin CLI: npx autonnel admin:create you@example.com 'a-strong-password' from the project directory.

Step 3: configure only what the funnel needs

In the admin UI under Settings: